One Environment, or Two?

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

A small team ships to production directly and feels vaguely guilty about it. Then somebody proposes staging, and six weeks later there are two environments, one of which nobody trusts.

Both outcomes come from the same mistake: treating environments as a maturity ladder rather than as an answer to a specific question. The question is what do you need to try before real users see it, and what does trying it require?

For a lot of small products the honest answer is: not much, and one environment plus a way to look at a change before publishing it is enough.

A second environment costs more than a second URL

Every environment is a second set of secrets, a second database with its own drift, a second place migrations must run, and a second thing that breaks in a way that teaches you nothing about production.

The cost is not the compute. It is that staging is only useful while it resembles production, and resemblance decays continuously — a config changed here, a manual fix applied there, data that is six months stale. A staging environment nobody maintains is worse than none, because it produces confidence rather than information.

So the question is not "should we have staging" but "what will we do with it that we cannot do otherwise, and who keeps it honest?"

What a second environment is actually for

Three jobs, and only the third really needs a permanent one.

• Seeing a change before users do. Usually solvable without a second environment: a deployment that is reachable by your team and nobody else until it is deliberately published.
• Testing a migration against real-shaped data. This one genuinely needs somewhere else to run, but it needs it occasionally — a restored copy for an afternoon, not a permanent installation.
• Integrating with a third party that has its own sandbox. Payments, a bank, anything with a certification step. Here a second environment is not optional; the other party's rules decide.

If none of those three describes your week, a second environment is a thing you will maintain rather than use — and the maintenance is paid in the same attention that would otherwise go to the product.

What to have instead, if you have one

• A deployment your team can open and nobody else can. Private by default, published as a deliberate act. That is most of what staging was for, without the drift — the same reasoning as deciding who can open an internal tool.
• Migrations that are safe to run forward. If a migration is only correct because you rehearsed it, the rehearsal is load-bearing and you should be doing it somewhere.
• A way back. Not a rollback button necessarily — a known-good version and the knowledge of how to get to it.
• Real data you can look at. Most "we should have caught that in staging" is really "we did not look at what production actually contains".

The version that goes wrong quietly

Two environments where one is a copy nobody updates. Config drifts, the schema diverges, and the first real difference shows up as a production incident that staging explicitly passed. At that point the second environment has cost you twice: once to run, once to mislead.

If you keep two, keep them the same on purpose, and be able to say when they last matched. If you cannot answer that, you have one environment and one distraction.

FAQ

Is deploying straight to production irresponsible? Not inherently. It is irresponsible without a way to see a change first and a way back. With both, it is just a short pipeline.

When does a second environment become worth it? When a third party requires one, when migrations are risky enough to rehearse, or when the team is large enough that changes queue behind each other.

What about a per-branch preview? Excellent for reviewing a change; a poor substitute for testing data migrations, which need real-shaped data rather than a fresh database.

How does this work on aidrop.it? A Project has one environment, production: its values and its backing services belong to it, and its address is public from its first deploy.

Does an AI agent change the calculation? It raises change volume, which makes "see it before users do" more valuable and a stale staging copy more dangerous — more changes flow past the same decayed check.

Cover: https://unsplash.com/photos/8B3d1ez-tRE by Johannes Plenio on Unsplash. Alt text: A single railway track receding into the distance, the rails blurred by shallow focus.