Do you need a staging environment with previews?

TL;DR: If every pull request already gets its own preview environment, most solo developers and small teams don't need a permanent staging environment. Staging is a full second copy of production, and for a small app with a web service, worker, Postgres and Redis it costs about $24 to $46 a month on Render, Railway or Heroku.

• Skip permanent staging if none of the four jobs below apply to you. Previews catch "does this branch work when deployed?" and don't drift.
• Keep staging for third-party integrations with one sandbox or callback URL, and for a client who signs off on a fixed URL.
• Create it for an hour to rehearse a migration on production-sized data or run a load test, then delete it.
• On a platform, staging costs $24 to $1,203 a month depending on your stack. On its own Hetzner server it's $7 to $36.
• Pick Ployz, which I build, if you want previews for every pull request and a staging environment whose changes save back to production, on your own servers, so you can check what your coding agent built before users see it.

A staging environment is a copy of your production setup where you run a release before real users see it: same code, same services, same kind of database, but separate data and secrets.

What's the difference between dev, preview, staging and production?

Dev is your laptop. A preview is a short-lived copy of the app for one pull request. Staging is one long-lived copy that every change passes through before release. Production is what users hit. The difference that matters is lifetime and data.

Staging's job is to catch the problems that only show up when everything runs together: a migration against real-sized data, a payment webhook, a broken env var. PlanetHoster's glossary says staging is for testing "under conditions as close to reality as possible" (PlanetHoster). Microsoft's Azure docs use the word for something narrower, a second deployment you swap into production, which is blue-green deployment (Microsoft Learn). Here, staging means a long-lived copy of the whole stack.

Some teams add a separate test or QA environment between preview and staging. For a team of one to five people I think that's one environment too many.

Heroku built the whole ladder into its product. A Heroku pipeline has four stages, "Development, Review, Staging, Production", and each stage is a separate app. Pipelines are free, but "you still incur costs for any dynos or add-ons used by your apps in the pipeline" (Heroku pipelines).

Do you still need staging if every PR gets a preview?

For most small teams, no. A preview gives each change its own URL, build and deploy, and someone can click through it before merge. That covers what staging was mostly used for. Previews also do three things better:

• No queue. On a shared staging server, two branches fight over one environment. Five open pull requests means five previews, each with its own URL.
• No drift. A staging server that has run for a year collects manual fixes, stale data and env vars nobody remembers setting. A preview is built fresh every time.
• It shuts itself off. Render previews can expire after a set number of days (Render docs). Railway deletes PR environments "as soon as the PR is merged or closed" (Railway docs). Heroku review apps exist "only for the life of their associated pull request" (Heroku review apps).

I covered how per-PR environments work, and what each costs, in ephemeral environments without Kubernetes.

When does a staging environment still earn its keep?

When the risky part of a release isn't the code in one branch. Four jobs qualify:

1. Shared integrations. Some third parties give you one sandbox and one webhook URL: a payment provider's test webhooks, an OAuth app with fixed callback URLs, an email provider's sending domain. You can't register a new callback for every preview, so one stable staging URL is the practical answer.
2. Data migrations. A migration that adds a column runs in milliseconds on a preview with 50 seeded rows. On a 40 GB production table it can lock writes for minutes. The only honest rehearsal is a restore of production data, cleaned of personal data, with the migration run against it. Previews almost never get a full copy of the database, and you wouldn't want twenty of them.
3. Load tests. You need something production-sized to point a load test at, and it can't be production. It doesn't need to run all month, though. Hetzner bills by the hour up to a monthly cap and says "if you delete your cloud server before the end of the billing month, we will only bill you for the hour" (Hetzner). An afternoon costs cents.
4. Client sign-off. Agencies and freelancers often need one URL the client can bookmark and approve before launch day. A preview URL changes with every pull request.

Only the first and fourth need staging running all the time. Migrations and load tests need it for an hour.

What does a staging environment cost on Render, Railway and Heroku?

About what production costs, because it's the same services on the same plans. I priced three stacks, all with Redis, with the staging copy matching production's sizes:

• Small: web plus worker at 512 MB each, Postgres with 1 GB RAM and 10 GB storage.
• Medium: three app services at 1 GB, Postgres with 2 GB RAM and 50 GB.
• Large: four app services at 2 GB, Postgres with 8 GB RAM and 256 GB.

Price your own stack below. The calculator prices one always-on copy at the same sizes on each platform.

The Railway row is the softest number, because Railway bills what a service actually uses, not the size you picked, so an idle staging copy could cost less. The other rows are list prices for plans that run all month.

The rates behind it:

Platform details that change the picture:

• Render: the free Hobby workspace allows 2 environments per project, so staging fits without a plan change. Full-stack previews need Pro at $25 a month; Hobby gets "single-service previews" (Render pricing). Previews "are billed the same as other Render services and are prorated by the second" (Render docs). Render has no 1 GB web plan, so a 1 GB service pays for 2 GB.
• Railway: duplicating an environment "creates a copy of the selected environment, including services, variables, and configuration" (Railway docs). There's no fee per environment; you pay for what the copy uses. The docs don't say whether a duplicate copies database data, so plan on loading staging data yourself.
• Heroku: staging is a separate app in a pipeline, billed like any other app. Review apps are "charged in exactly the same way as for normal apps," prorated to the second (Heroku review apps). Past 1 GB, the next dyno is Performance-M at $250, which is why the large Heroku column jumps.

You can shrink staging by giving it smaller plans than production. Then it stops being a copy, and the bugs that only show at production size slip through. If you're going to run it smaller, a preview probably already does that job.

The database is the expensive half. When I was on Railway, most of my $500+ bill came from one busy database, and a staging copy loaded with real-sized data would have added a big share of that again. Full breakdowns are in Render pricing, Railway pricing and Heroku pricing.

How much does staging cost on your own server?

Whatever extra RAM and disk it needs. A separate small server costs about $7 a month for the small stack and $36 for the large one. If your production server has spare room, staging can run there for $0 extra, as long as you never load-test it there.

For a long-lived staging box I'd look at Netcup first, because the term price is low, traffic is included and it has a US datacenter in Manassas.

Where staging should live:

• On the production server, if it has headroom. It's the cheapest option and fine for a small app. The risk is shared resources: a runaway staging job slows production down.
• On its own small server, once real users depend on production. A CX23 holds the small stack.
• On a server you create for the day, for migration rehearsals and load tests. Restore a cleaned production dump, run the test, delete the server.

If you haven't rented a server before, how to set up a VPS covers the parts that matter, and Hetzner pricing has the full price list.

How do you keep staging close to production?

Promote the same build, keep the same services and versions, and use data that looks like production without the personal details. A staging environment that drifts from production gives you false confidence, which is worse than having none.

• Same artifact. Heroku's promotion copies the build "without making any changes", so "production contains the exact same code that you tested in staging" (Heroku pipelines). With Docker, promote the same image tag.
• Same versions. Postgres 16 in staging and 17 in production will bite you.
• Separate secrets. Staging gets its own API keys, sandbox payment keys and session secret, never production keys.
• Clean data. Restore production on a schedule and scrub emails, names and payment details before anyone else sees it.
• Guard rails. Send all staging email to a catch-all inbox, turn off real payments, and put staging behind a login so search engines don't index it.

Which should you pick?

Keep a staging environment if you integrate with third parties that allow only one sandbox or callback URL, you run migrations against big tables, you need a fixed URL for client sign-off, or someone outside the team runs a QA step. Size it like production, or it won't catch what you need it to catch.

Use previews and your own server if you're a solo developer or a small team and those don't apply. A preview per pull request catches the "works on my machine" bugs, costs almost nothing while it runs, and doesn't drift. Rehearse the scary migration on a server you create for an hour. On a platform, skipping permanent staging saves $24 to $1,200 a month; on your own server, keeping it costs $7 to $36.

Staging doubles every number in what PaaS hosting costs, so decide on purpose.

Where Ployz fits

I build Ployz, and it covers both halves of this article, previews and staging, on servers you rent.

Previews. Every pull request, including the ones your coding agent opens, gets a preview environment at its own HTTPS address, like web-pr-142.acme-x7q2.ployz.app, on your servers. You pick which services get their own copy. A copied database starts empty, and a setup command like pnpm db:seed can seed it. Each push redeploys the preview, and it's deleted when the pull request merges or closes. If you change a preview's settings and save them, they go live with the merge.

Staging. You can branch production into staging with its own services, variables and empty volumes, then save changes back to production when they're right. That's the "promote what you tested" habit built in. Branches you don't keep close after 7 days without a deploy, so a forgotten staging copy doesn't run up a bill.

Both run on the servers you already pay for, with monitoring and searchable logs for every service, so you can watch a staging deploy before it saves back to production. Previews need the Ployz GitHub App. Previews and environments are unlimited on every plan, and the Free plan covers one server. Staging on its own second server needs Pro, which is coming at $19 a month with 3 servers included.

FAQ

What is the difference between staging and UAT?

UAT (user acceptance testing) is a step where users or a client approve a release. Staging is the environment it usually happens on; for a fixed sign-off URL, staging beats previews.

Is a preview environment the same as staging?

No. A preview lives for one pull request and starts with throwaway data. Staging is one long-lived copy that every change passes through, ideally with production-shaped data.

Should staging run on the same server as production?

For a small app with spare room, it's fine and costs nothing extra. Once real users depend on production, move staging to its own small server so a runaway job or load test can't slow production down.

How do I get production data into staging safely?

Restore a production dump on a schedule and scrub emails, names and payment details before anyone else sees it. Give staging its own secrets and send its email to a catch-all inbox.

How I checked

I checked every price on 1 October 2026 on each provider's own pricing page, linked next to the numbers. The three stacks are my own examples, and the Railway column is an estimate because Railway bills actual usage. Hetzner prices are after its 15 June 2026 adjustment. I build Ployz, so weigh my view on previews versus staging with that in mind.

Get a preview for every pull request and a staging environment on your own server with Ployz: get started.