Skip to content

Development Server

Jens Luebeck edited this page Sep 3, 2026 · 1 revision

Development Server

https://dev.ampliconrepository.org

The passphrase

amprepodev

Enter it on the landing page at the dev server's home page, then use the site normally.

It is not a secret. It is published here, in the repository's README.md and in AGENTS.md, and it is not a security boundary — the dev server holds no sensitive data. Its job is to stop someone who followed an old link, edited the production URL, or arrived from a search result from mistaking a server full of test data for the real repository.

A dev account is a different thing. The passphrase gets you into the site; it does not create a login. If you need an account on the dev server — to upload projects, test private-project behaviour, or exercise admin pages — contact Jens Luebeck (jluebeck@ucsd.edu).

What the dev server is for

Dev runs unreleased code against test data. It is where a change is exercised under something close to production conditions before it reaches ampliconrepository.org:

  • Reviewing a branch's UI against real page shapes rather than fixtures.
  • Testing upload and aggregation against tarballs too large or too slow for a laptop.
  • Exercising the Google and Globus login flows, which need a real HTTPS origin and registered callback URLs.
  • Rehearsing migrations and maintenance scripts against caper-dev before the same script is pointed at production.

What follows from that: anything on dev may be incomplete, wrong, or deleted without notice. Do not cite a dev URL in a paper, an issue, or an email to a user, and do not treat a project on dev as a copy of anything. Dev and production share one DocumentDB cluster (caper-dev and caper), so a script pointed at the wrong database is the mistake to watch for.

Deploying to dev is a separate topic: Deploying unreleased code to dev for testing a branch, and Updating the Dev & Prod servers for a tagged release. To get admin rights on a dev account you already have, see Becoming Admin on a development server.

How the gate behaves

  • The home page only. A direct link to a project, a sample, the REST API or an OAuth callback works without the passphrase. That is deliberate: it keeps API clients, the login flows and the weekly report script working without an exemption list. The gate is there for the person who arrives at the front door.
  • It does not log you in. Passing it sets one cookie, amprepo_dev_access, for seven days, and leaves you anonymous as far as the application is concerned — which is what lets us keep testing anonymous-visitor behaviour on dev. Logging out of AmpliconRepository does not clear it.
  • To clear it, delete the amprepo_dev_access cookie in your browser, or post leave=1 to the dev home page.
  • Crawlers. Every response from dev carries X-Robots-Tag: noindex, nofollow, noarchive. Dev should not appear in search results; if you find it there, say so on the issue tracker.

The implementation is caper/caper/dev_gate.py, and README.md covers the environment variables that turn it on.

Clone this wiki locally