Category: DevOps / Business Owner / CMS User

Tale from the trenches: I used to work at a company which had their payment function at a 3rd party service where I literally hacked the page full of workarounds because the deployment procedure was so bad. We would have to email their DevOps our code and their deploy would come at an unspecified time. Take a deep breath, let it out. Release your anger :) Anyway, that hacked page earned the equivalent of €150.000/day. I would have looked very bad if my hacks went wrong... We did it properly after a year or so, when my name was embedded in code someone had copied for their scam site.

What staging actually is (for everyone who has to care about it)

A staging environment is simply a private copy of your live site. It runs the same code, the same database structure, the same web server configuration. The only difference is that nobody from the outside world can see it. You make your change there first. You look at it. Your client looks at it. If something is broken, it is broken in private, where it can be fixed before your real customers encounter it.

That is genuinely the whole concept. It sounds almost too simple to be worth writing about.

And yet, most small businesses and solo operators do not have one. Or they have a half-built one that nobody maintains. Or they set one up, used it twice, and then started deploying straight to production again because it felt like extra work.

There are three groups of people who should understand what staging is and why it matters: business owners, content editors, and developers. They each have a different relationship with the risk.

Business owners are the ones who absorb the financial hit. Downtime and broken deployments are not just embarrassing. Research from Atlassian (makers of Jira, Slack, Confluence) and others consistently puts the cost of downtime for well visited small to medium businesses somewhere between €125 and €390 per minute. That is before you account for lost trust or the customer who never comes back... Staging is cheap insurance.

Content editors are often the ones who are scared to touch anything. The "deploy fear" phenomenon is real and underappreciated. Teams that have been burned by a bad update start avoiding all updates. The site stagnates. Security patches get skipped. The whole system quietly rots while everyone tries not to trigger another incident. Staging gives editors a place to try things safely, which means they actually try things.

Developers, even solo ones, know the feeling of pushing something and immediately refreshing the live site with your stomach in your throat. A good staging setup makes that feeling go away. The anxiety is resolved upstream, before anything reaches production.

The "it's fine, I tested it locally" problem

Local development environments lie. They lie constantly and politely.

Your laptop does not have the same Nginx configuration as your Debian VPS. Your local Python environment may have a package version that differs from what is pinned in production. Your Svelte build might behave differently when served through the actual FastAPI backend under real network conditions. The database you are testing against locally is probably a stripped-down fixture set that does not reflect the edge cases sitting in your real data.

This is not a theoretical concern. It is why "works on my machine" became a cliché long before it became a meme. Local dev is irreplaceable for iteration speed, but it cannot substitute for a near-production test run. Staging closes that gap.

Green/blue deployments and what comes before them

If you have reached the point of running green/blue deployments with two parallel production environments, traffic flipping cleanly between them, you have already solved the hardest part of the problem. The infrastructure is there. Rollbacks are fast. Zero-downtime deploys are routine. It is, genuinely, an excellent place to be.

But green/blue is about how you deploy to production, not about what you deploy. It does not catch the broken checkout button before it reaches either environment. It just means you can roll it back in thirty seconds instead of three minutes. Which is valuable. But the failure still happened in front of real users.

Staging sits earlier in the pipeline, before anything green/blue ever comes into play. Think of it as the place where you verify that what you are about to deploy is actually correct, not just operationally safe.

The two practices are complementary. Staging catches the logic errors, layout regressions, and integration failures before the code leaves your internal network. Green/blue handles the operational safety of the handoff. You want both.

Now, what about the QA environment?

Here is where many teams get confused, because the terms get used interchangeably in the wild even though they describe meaningfully different things.

A QA/test environment (depending on your team's setup), is where you break things deliberately. It is connected to synthetic data or anonymized copies of production data. It is a playground for your automated test suite, your integration tests, your exploratory testing. QA is chaotic by design; that is the point. You deploy unfinished features there. You run destructive test scenarios. You check whether the new API endpoint survives a malformed payload.

Staging, by contrast, is supposed to be stable. It reflects what you are about to put into production, not what you are currently building. It is where you do a final sanity check, where a client does user acceptance testing, where you verify that the migration script actually ran. Staging should be boring. If staging is chaotic, it is not doing its job.

The practical pipeline for a solo operator or small team looks something like this:

Develop locally
Push to QA / test environment for automated checks and integration testing
If that passes, promote to staging for a final human review
Deploy to production via your green/blue pipeline

Small operations often collapse QA and staging into a single environment, which is fine as a starting point. The important thing is that something exists between your laptop and your live site.

What a minimal staging setup actually needs

For a self-hosted setup on a Debian VPS running FastAPI and Svelte behind Nginx, staging does not require a second physical server. A subdomain with access restriction is enough to start.

The non-negotiable parts:

A separate subdomain: staging.yourdomain.com, protected by HTTP basic auth or IP allowlist via Nginx. Do not let search engines index it, a noindex header or robots.txt entry usually handles this.
A separate database: not the production database, not even a live replica. A recent anonymized dump, refreshed on a schedule. Staging that shares a database with production is a trap waiting to close on you.
The same runtime configuration: same Python version, same Nginx config structure, same environment variables (with staging-safe values for payment providers and external APIs). Configuration drift between staging and production is how you get "it worked in staging" bugs.
A documented deploy process: even if it is just a shell script. Staging that requires manual steps to update will quietly fall out of sync with production.
Notification suppression: if your application sends emails or webhooks, make sure staging points at test endpoints or a dead-letter address. Nothing undermines client trust like a staging test triggering a real transactional email. I quietly sent about a million onboarding emails to already customers once by sloppy coding. Could have been many more millions but someone found out and stopped it. Got saluted by 40 devs the next AW... And somehow I didn't get fired.

The slightly more ambitious version adds: automated promotion from a passing CI run, regular database refreshes from production (anonymized), and uptime monitoring on staging itself so you notice when it goes stale.

The conversation nobody wants to have with a client

There is a version of this that is a business conversation, not a technical one. If you run a platform for clients, like e-commerce shops, content-heavy sites, booking systems. If a bad deploy breaks their checkout at 18.40 on a Friday, the conversation that follows is painful, regardless of how quickly you fix it.

Staging changes that conversation before it happens. When clients can preview changes, approve layouts, and sign off on new features in a private environment before anything goes live, you stop being the person who breaks things and start being the person who catches problems before they become problems. That is a different kind of relationship.

For small agencies and freelancers working with European SMBs, this is also increasingly a contractual expectation. Clients who have been burned once tend to ask, in the next brief, whether there is a staging environment. Having one and being able to explain it clearly, is a differentiator.

The deploy fear is real and staging cures it

The most underappreciated cost of not having a staging environment is not a broken page or a lost sale. It is the accumulated paralysis of a team that has learned to be afraid of their own codebase.

When deploying feels dangerous and things explode, people stop deploying. Then updates pile up. Technical debt compounds. The gap between what the site is running and what the code repository contains grows until deploying anything at all feels like defusing a bomb.

This is not a developer character flaw, although we have many :) It is a rational response to an environment without safety nets. Staging is the safety net. Once it exists, updates become routine. Routine things get done. The site stays current, secure, and maintainable.

Getting green/blue deploys right can be everything from easy to a significant piece of work. Hundreds of deploys with no errors is an excellent result. Staging is what completes the picture. Not because the current setup is broken, but because a stable deploy pipeline is only as good as what you put into it.

If you want to dig into the green/blue deployment approach that makes the production side of this equation work, that is probably covered in the Operations category.

Blog

No posts found