Zuplo
Unlimited Environments

Every branch is a full gateway environment

Push a branch, get an edge-deployed API in seconds — same 300+ POPs as production, with isolated env vars per stage. Three stages — Prod, Preview, Working Copy. Included on every plan, including the free tier.

Branches → Environments
UNLIMITED · ALL TIERS

Branches

PRODenv: main
api.acme.comLive

Env vars

18

Key bucket

prod-keys

Edge POPs

300+

ZUPLO_ENVIRONMENT_STAGE = production
3 stages · Production / Preview / Working Copy
Same edge · 300+ POPs everywhere
Free tier · unlimited environments
Why this matters

Your team has one staging environment and seven branches fighting for it

When testing a change is harder than shipping it, teams ship without testing. Real per-PR environments are the cheapest reliability investment — but only if they're free to spin up.

×

One staging environment, ten teams

Whoever pushed last owns staging. Everyone else's testing is broken. The Slack channel for the booking system has been unreadable for months.

×

“Just test in prod”

The infrastructure cost of a real per-feature environment makes "test it after the release" the default plan. Bugs ship. Customers find them.

×

Per-environment licensing math

Some gateways charge per environment. Engineering managers who'd love a preview-per-PR can't justify the line item, so the experience tier sees "only main and staging" as the budget.

×

Helm-chart staging that takes 20 minutes

A real "preview environment" elsewhere in the stack is a Terraform apply, a Helm chart, and a new DNS record. So you stop bothering. The gateway is the only thing left without preview.

What you get

Vercel-style preview, applied to your gateway

Every branch is a real, edge-deployed gateway

Push a branch, get a URL. Same 300+ POPs as production. No cost, no provisioning, no waiting. Reviewers click the URL, run their suite, leave a comment.

Three stages, one model

Production, Preview, Working Copy. Each has its own env-var scope. ZUPLO_ENVIRONMENT_STAGE tells your code which stage it's running in, so you can branch behavior cleanly without conditionals scattered across the repo.

Free, every plan

Unlimited environments isn't a paid add-on. It's the default behavior on every Zuplo plan including the free tier. Every team's preview-per-PR ambitions stop hitting the budget conversation.

Three stages · scoped env vars

One variable name, three scoped values

Define DATABASE_URL once with three values — Production points at your prod cluster, Preview at staging, Working Copy at localhost. ZUPLO_ENVIRONMENT_STAGE is populated automatically so your handler code can branch behavior cleanly per environment.

TypeScriptStage-aware handler logic
import { environment } from "@zuplo/runtime";

export default async function handler(
  request: ZuploRequest,
  context: ZuploContext,
) {
  // Same code, different behavior per environment
  if (environment.ZUPLO_ENVIRONMENT_STAGE === "production") {
    return forwardTo(environment.PROD_BACKEND);
  }
  if (environment.ZUPLO_ENVIRONMENT_STAGE === "preview") {
    return forwardTo(environment.STAGING_BACKEND);
  }
  // working-copy → local dev backend
  return forwardTo(environment.LOCAL_BACKEND);
}
TerminalEnv vars · scoped per stage
# Variables defined once with stage-specific values:

DATABASE_URL  Prod postgres://prod.acme.co:5432
DATABASE_URL  Preview postgres://staging.acme.co:5432
DATABASE_URL  Working postgres://localhost:5432

STRIPE_KEY    Prod sk_live_…    (write-only secret)
STRIPE_KEY    Preview sk_test_…    (write-only secret)

# System variables populated automatically:
ZUPLO_ENVIRONMENT_STAGE  production | preview | working-copy
ZUPLO_ENVIRONMENT_NAME  acme-main-1235.zuplo.app
Branch = Environment
Working Copy on .zuplo.dev
Per-stage env-var scope
Different backends per env
Same 300+ edge POPs
Free tier · unlimited envs
What makes Zuplo different

Real environments, not paid environments

Branches IS environments

Most gateways have an "environments" feature you have to manage separately from your code. Zuplo's environments come from your Git branches — they exist the moment you push, they share runtime with production, and they vanish when the branch is deleted.

Per-developer Working Copy

Each developer has a personal cloud-hosted environment on a `.zuplo.dev` URL. Save in the portal, see the change live in seconds. No "who's using staging" question, no laptop-hostfile workaround.

Three env-var scopes, one variable name

DATABASE_URL = production cluster in Prod, staging cluster in Preview, localhost in Working Copy. One variable, three values, scope-aware substitution. No `if (env === 'prod')` scattered throughout the codebase.

Edge runtime, not staging shims

Preview environments run on the same 300+ edge POPs as production. Latency, geography, and policy enforcement are identical to production — what works in preview works in prod, with no "oh that's staging behavior" surprises.

Real questions, real answers

What teams use this for

“My PR touches the auth policy. How do I test it without breaking staging?”

Push your branch. Hit the preview URL. The auth change runs on a real edge environment with isolated env vars. Production is untouched, staging is untouched, your reviewer has a real URL to test against.

“We have 60 engineers and one staging slot.”

Now you have 60 staging slots — one per branch, each with its own URL. Each environment has its own preview env-var scope, so secrets and config don't bleed across.

“Our QA team needs an environment that lasts a sprint.”

Create a long-lived branch like `qa-sprint-42`. Merge feature branches into it instead of main. QA hits a stable URL while features land. Merge `qa-sprint-42` into main when the sprint ships.

“The customer needs to validate v2 endpoints before we ship.”

Send them the `release/v2` branch URL. They get a real, edge-deployed v2 gateway scoped to their access. No staging contention, no second cluster to maintain.

Frequently Asked Questions

Common questions about unlimited environments.

Stop fighting for one staging slot

Free Zuplo project, push a branch, watch a real edge-deployed gateway appear at its own URL.