Running in production

A deployed system needs durable data, protected secrets and enough logging to diagnose failures without exposing its users

Production differs from your machine: a different filesystem and environment, a proxy in front of the app, and nobody watching each request. The mechanics of your Fly access — your token, the deploy command and the resource limits — are on your hosting access. The same production concerns apply if you change hosting providers.

The deployment contract#

A repeatable deploy requires the complete recipe in the repository and the credential outside it.

A full-stack repo stores the recipe in three files:

• Dockerfile — how source becomes a running image. A Fly deploy is a Docker build, so this is the file your choice of stack lives in
• fly.toml — the machine, the volume, the port, the environment. This is where the app stops being a dev server: one machine, one volume at /data, PORT set, auto-stop when idle
• .github/workflows/checks.yml — the checks, then the deploy, then probes against the deployed URL

Changing stack means changing the Dockerfile. The workflow and hosting configuration stay as they are, because neither names a stack. The static half uses the same separation through pnpm build and the dist/ directory.

A deploy step that ends when the image boots has proved only that the image boots. The course’s CI then checks for a 200 response and valid internal links, and the lecture demo adds probes for its event stream, an accepted same-origin POST and a refused cross-site one. Each check covers a production failure that local checks have missed.

Data and secrets#

Two questions to be able to answer about a deployed app.

What survives a restart? On Fly, exactly one thing: the volume. The lecture demo’s SQLite file lives at /data/app.db on it, which is why a message posted before a redeploy is still there afterwards. Everything else — the container filesystem, anything held in a module-level variable, the set of open connections — is rebuilt from nothing every time the machine starts. Machines also stop when idle and start on the next request, so “every time” is more often than you think.

Check this explicitly. An app that writes outside the volume can work for an afternoon and lose the lot on the next deploy.

Where do secrets live? The dividing line in a server-rendered app is which side of the wire the code runs on. In an Astro page the frontmatter runs on the server and a <script> block is shipped to the browser, so a value read in one is private and the same value read in the other is public. Anything prefixed PUBLIC_ is in the client bundle by design.

Three rules cover the rest:

• an app secret is set on the platform (flyctl secrets set) and read as process.env.X on the server. It is never a literal in the repo
• a deploy credential belongs with the repo but outside git. In this course that’s FLY_API_TOKEN in a gitignored mise.local.toml, and in CI it’s a repository secret
• nothing secret goes in a log line. Logs are the thing you will read in front of other people

CI scans every commit in the history for committed credentials, so the cost of getting this wrong is a red run rather than a quiet leak — but only for secrets a scanner can recognise.

Useful instruments#

Choose each instrument for a question you need to answer:

• is it up, and is it serving what I think? flyctl status, and a request to the URL. The deploy probes above are this question asked automatically
• what did it do when that broke? flyctl logs, which streams the app’s stdout. Log the things you would want in that moment — the request path, the outcome, the identifier — and nothing that identifies a person unnecessarily
• has it stopped working for someone else? The hardest one, and the reason a live app is different from a demo. A form that 403s for every visitor looks identical, from your chair, to a form nobody used

A dashboard of every available number does not answer these questions. For an app this size, a few targeted log lines are enough.