Chalom Ellezam

Posted on Jun 15

Your indie SaaS has no staging environment. Here is the 30-minute setup (and the 4 production bugs it catches before your users do).

#devops #indiehackers #beginners #webdev

Disclosure: I am a senior backend tech lead in Paris and I run HostingGuru, a small European PaaS. This article mentions HostingGuru once near the end. Everything else works on any platform you ship on.

A founder I review code for shipped a "two-line fix" to her Lovable-built waitlist app at 21h on a Friday. The deploy went green, the homepage rendered. By Saturday morning, none of the new signups were being saved. A migration she had run against her local DB a week earlier had silently been included in the deploy. Production was on schema v3, the code was talking to schema v4.

She did not have a staging environment. Nobody on this kind of project ever does, and yet every solo founder I review eventually loses a weekend to a bug that staging would have caught at the cost of 30 minutes of setup.

This is the version of the setup I now recommend. It does not require Kubernetes, a DevOps hire, or doubling your hosting bill. It catches exactly the kind of bugs that bite when you ship fast and your "test environment" is your laptop with the dev server running.

Why most solo founders skip staging

The canonical advice for staging was written for teams of ten. It assumes a Terraform repo, a CI matrix, separate AWS sub-accounts, and a QA engineer who runs the test suite. Nobody building a solo SaaS in 2026 has any of those. So the founder reads the advice, decides it is not for them, and ships straight from main to production. They are not wrong about the canonical advice. They are wrong about the conclusion.

The 90% version of staging is much lighter. A separate branch, a separate web service running the code on that branch, a separate database, a separate set of secrets, and a separate URL. That is it.

The four bugs staging actually catches

I want to be specific about what staging buys you, because most of what people imagine staging does (catching logic bugs, validating UX) is better done elsewhere. Here is what staging uniquely catches.

One, schema drift. Your local dev DB has a column email_lower that your prod DB does not. You shipped a query that uses it. Production crashes. This happens constantly when a founder runs prisma migrate dev against the local DB and forgets to push the migration. Staging, which runs the same migration command on a real network DB at deploy time, catches it.

Two, environment-variable assumptions. Your code reads process.env.STRIPE_KEY. Locally it lives in .env.local. In production you set it in your platform's UI. In staging, you forgot. Catching this on staging is two minutes. Catching it on prod is a refund email and a tweet.

Three, cold-start and platform-specific failures. Your code works locally because Node never restarts. It breaks in production because the platform recycles containers and your in-memory session store is empty for the first request. Staging on the same platform as prod reproduces the cold-start the second you deploy.

Four, webhook and OAuth callback URL mismatches. Your Stripe webhook is pointed at prod.example.com/webhook. Your local .env has localhost:3000/webhook. Staging exposes whatever URL is hardcoded somewhere it should not be, because the staging app gets a different domain from prod.

If you have ever shipped a fix on Friday and woken up Saturday to one of these, you already paid the staging tax. You just paid it as a bug instead of as 30 minutes of setup.

The 30-minute setup

Five pieces. None of them require a YAML file longer than a haiku.

1. A separate branch (3 minutes)

Create a long-lived staging branch in your repo.

git checkout -b staging
git push -u origin staging

The rule from now on: feature branches merge into staging, you smoke-test on the staging URL, then staging merges into main which deploys to production. Most clients I migrate already think they have this workflow but actually do not, because they merge feature branches directly into main and skip the staging hop.

2. A separate web service (5 minutes)

In your platform of choice (Render, Fly, Railway, Vercel, or anything else that deploys from GitHub), create a second service that deploys from the staging branch. Same repo, same build command, different branch.

If you are on a platform that exposes a YAML config, the diff is one line:

services:
  - name: my-app-staging
    branch: staging
    plan: starter
  - name: my-app-prod
    branch: main
    plan: hobby

If you are on a UI-based platform, you click "New service," select the same repo, change the branch to staging, and you are done.

The cost is usually $0 or close to it. Most platforms have a free or near-free tier for the staging service because staging traffic is tiny. If prod runs on a $19 plan, staging usually runs on a $0 or $7 plan.

3. A separate database (8 minutes)

This is the part founders cut and later regret. The point of staging is to catch schema drift, and schema drift cannot be caught if staging and prod share the same database. They must be separate physical databases.

Spin up a new Postgres instance, same provider as prod, smallest plan. Give it a sensible name like myapp-staging-db. Copy the production schema once:

pg_dump --schema-only $PROD_URL > schema.sql
psql $STAGING_URL < schema.sql

Then seed it with fake data, never with a copy of production. You will be tempted to copy prod because then "it looks real." Do not. Copying prod into staging is how PII leaks happen. Use a seed script.

// scripts/seed-staging.js
import { PrismaClient } from '@prisma/client';
const db = new PrismaClient();

async function main() {
  await db.user.createMany({
    data: [
      { email: 'staging-1@example.test', plan: 'free' },
      { email: 'staging-2@example.test', plan: 'pro' },
    ],
  });
  await db.project.createMany({
    data: [
      { name: 'Test project A', ownerEmail: 'staging-1@example.test' },
    ],
  });
}

main().finally(() => db.$disconnect());

Run it once after creating the staging DB. Done.

4. Separate secrets (7 minutes)

This is where most "staging environments" leak into production. The founder sets up staging, copies the production env vars into the staging service, and now staging is talking to the live Stripe account, the live Resend account, and the live OpenAI key. A confused click on staging sends a real email to a real customer.

The rule is: every external service has a test or sandbox version. Use the sandbox version everywhere on staging.

# Production env vars
STRIPE_SECRET_KEY=sk_live_xxx
RESEND_API_KEY=re_prod_xxx
OPENAI_API_KEY=sk-prod-xxx
DATABASE_URL=postgres://prod...

# Staging env vars
STRIPE_SECRET_KEY=sk_test_xxx
RESEND_API_KEY=re_test_xxx
OPENAI_API_KEY=sk-staging-xxx (separate OpenAI project, $5 monthly cap)
DATABASE_URL=postgres://staging...

For OpenAI specifically, create a second project in your OpenAI dashboard with a $5 hard cap. That way a runaway loop on staging cannot eat your real budget. (See my earlier piece on AI apps silently burning money for what that looks like in production.)

For Stripe, switch the dashboard to test mode and you get a separate set of keys, a separate set of webhooks, and a separate set of customers. The webhooks are the part founders miss. You need to create a separate webhook endpoint in Stripe test mode pointed at your staging URL. Otherwise your staging app silently fails every payment flow and you assume it is your code.

For Resend, Postmark, or whatever transactional email provider you use, send staging mail to a sandbox inbox (Mailtrap, Ethereal Email). The risk is not the provider charge, it is that you accidentally send a "Welcome to MyApp Pro!" email to a real user from a staging test run.

5. A separate URL (2 minutes)

Default to whatever the platform gives you (myapp-staging.platform.app). If you care, add a subdomain like staging.myapp.com. The point is that the staging URL is different enough from prod that no human ever confuses the two. I have seen founders deploy prod from a staging branch by mistake because both URLs lived on adjacent subdomains. Do not be them.

That is it. Five steps, 25 to 35 minutes if you have not done it before, much less if you have.

What changes about your workflow

Before staging: git push origin main, hope for the best.

After staging: push to staging, open staging.myapp.com, click around for two minutes, check the route you changed, verify any new migration ran, then merge staging into main for production.

The extra step is the two-minute smoke test. That is the entire ongoing cost. Once you do this for a week, it becomes muscle memory and you stop noticing the overhead. The compounding return is that the 4 bugs above stop happening. The ratio of "Saturday morning bug-hunts" to "uneventful Saturdays" flips within a month.

A note on CI

I deliberately did not include "set up CI tests" in the 30-minute version. CI is good and you should add it eventually, but it is its own setup project and it is not the part that catches schema drift. The staging hop catches the bugs CI cannot (real-DB migrations, real-platform cold starts, real env-var presence). CI catches the bugs staging does not (logic regressions, type errors). Complementary, not substitutes. Get staging in first, add CI when you have a test suite worth running.

The trap nobody warns you about: stale staging

The most common way a staging environment dies is not deletion, it is decay. Six weeks in, staging stops matching prod. A different Node version. A different env var you only added to prod and forgot to mirror. A migration that ran on prod through a manual psql command but never on staging.

You only find out staging is stale the day a "tested on staging" deploy crashes prod. To prevent this, write a one-page STAGING.md in your repo listing every env var and external integration. Anytime you change one in prod, you change it in staging in the same commit. The README is the source of truth, the platform UI is a reflection.

What I built

I built HostingGuru, a managed PaaS aimed at solo founders and small teams, in part because I kept setting up the five pieces above manually for clients. On HostingGuru, a staging service is a checkbox during repo connect: pick which branch is staging, pick which one is prod, get two URLs and two databases. Sandbox env vars and per-environment secrets are first-class, so you do not accidentally copy prod keys into staging. We run from German and Oregon data centers, ISO 27001, GDPR-compliant. The free Starter tier never sleeps, which makes it usable as a staging environment without paying anything.

That is the one mention. The setup above works on Render, Fly, Railway, Vercel, Supabase compute, your own VPS, or anywhere else. Pick the platform you are happiest paying.

What to do tonight, regardless of platform

If you do not have a staging environment, do these in order, and stop whenever you run out of energy.

Create a staging branch in your repo and push it.
On your platform, create a second web service that deploys from the staging branch.
Provision a second database. Do not share it with prod.
Copy your prod env vars into staging, then go down the list and swap every *_live_* or *_prod_* for the corresponding test value. Anything that does not have a test mode (rare, but it happens) gets a separate account.
Write a small seed script. Run it once.
Push a small change (a footer copy edit) to staging first and confirm it deploys cleanly.
Add one sentence to your README: "We deploy via staging → main. Never push to main directly."

The whole loop should fit in an evening. If it does not, stop at step 4 and finish tomorrow. The first four steps already catch three of the four bugs above.

Closing question

The funny thing about staging is that the engineers who most often skip it are the ones who would benefit the most: solo founders shipping fast, vibe-coders launching their first SaaS, agencies running 20 client projects on shoestring infra.

If you have shipped a SaaS in the last 6 months without a staging environment, I am curious what your single worst production-only bug has been. Drop it in the comments. I will probably write the next post on the most common pattern.

DEV Community