Level 03 · Leaving the hangar
It has to run somewhere other than your laptop, and that sentence has been on the list for a month.
Deployment is the level where the most projects stall, because it is the first one where the model cannot see the thing it is configuring. It has no view of your host, your DNS, or the value in that environment variable, and it will confidently describe a setup you do not have.
You are here if
- The only copy of the data is on your machine.
- You have deployed it once and are afraid to do it again.
- The word “environment variable” appears in four places and you are not sure which one is real.
- You cannot say what happens if your laptop dies tonight.
What deploying actually means
Four things, and it helps to name them separately. A machine that stays on and runs your code. A build step that turns your source into what that machine runs. A domain pointed at it. And configuration that differs between your laptop and the live one, which is what environment variables are for.
Most deployment confusion is these four collapsed into one word. When something fails, ask which of the four it was: the build, the boot, the DNS, or the config. It is almost always the config.
The database question
Use a managed database. Not because self-hosting is beyond you, but because at this level your time is better spent on the product than on backups, upgrades and disk space. The exception is a project that will never have a second user.
Two things matter more than which one you pick. Migrations: schema changes belong in files, applied in order, so the live database can be brought to the same shape as yours without you clicking through a console at midnight. And separation: your development data and your real data must not be the same database. The day they are, a test will delete something real.
Secrets, and the ones that already leaked
Keys belong in the host’s configuration, never in the repository, and never in anything the browser downloads. A key that is in your front-end bundle is public even if the page is behind a login, because the bundle is served to whoever asks.
If a key has ever been committed, it is compromised. Deleting the line does not help: version control keeps history, and public repositories are scanned continuously by people who do this for a living. Rotate it, then remove it. In that order.
Backups you have actually restored
A backup you have never restored is a belief, not a backup. Set them up, then once, deliberately, restore into a scratch environment and look at the data. That hour is the cheapest insurance in this entire climb.
Same for rollback. Deploy something harmless, roll it back, and time it. Knowing that recovery takes four minutes changes how you work, because the fear of shipping is mostly the fear of being stuck with what you shipped.
Run it yourself
The checklist we would run.
There is nothing held back in it. If you work through this list and nothing on it is open, you have left this level, and you did not need us to do it.
- 01
Configuration lives in the host, not the repo
And the repo has an example file listing which variables exist, with no values in it.
- 02
The database is managed, and is not your development database
Two separate databases, and ideally a third for a preview environment.
- 03
Schema changes are files, applied in order
Whatever your stack calls them. The test is whether a fresh database can be brought to the current shape by running them.
- 04
You have restored a backup on purpose
Into a scratch environment, once, while nothing was wrong.
- 05
You have rolled a deploy back on purpose
And you know how long it took.
- 06
Something tells you when it is down
Even a free uptime check on the home page. Finding out from a user is a bad way to find out.
- 07
No key that has ever been committed is still in use
Rotate first, then delete the line.
What done looks like
- You can deploy on a Friday afternoon without a knot in your stomach.
- Losing your laptop tonight would be annoying, not fatal.
- You know which of the four things broke when something breaks.
Where it usually goes wrong
A file-based database on an ephemeral disk
It works, right up until the host restarts the container and the file is gone. Check whether your storage survives a restart before you rely on it.
“It works locally”
Almost always missing configuration, a different database, or a path that only exists on your machine. Start with the environment variables.
One environment
If the only place to try something is the one users are on, you will stop trying things.
If you want company
A real deployment: environments, a database that survives a migration, secrets that are not in the repo, a domain, backups you have restored once on purpose, and a deploy you can do on a Friday.
Getting the first real deployment right takes a few hours with someone who has done it before, and saves the fortnight where it half-works.
It starts with a conversation and innovate@isyncso.com, subject Hangar. Tell us the level you landed on and what is in front of you. If the answer is on this page, we will say so.