Zuplo
GitOps

Your gateway is in your repo. Every push deploys.

Routes, policies, TypeScript handlers, env vars — all files in Git. Every PR gets a preview URL on the same 300+ edge POPs as production. Every revert is a `git revert`. No state files, no portals overriding your repo.

Start for Free Read the Docs
GitOps deploy
GitHub · zuplo/api-gateway

git push

feature/add-rate-limit

running

Pull request opened

PR #4821 · checks running

Preview URL deployed

feature-add-rate-limit.zuplo.app · 14s

Merged to main

Atomic deploy starting

Production live

api.acme.com · 300+ POPs · 11s

Atomic deploys
Preview per branch
git revert to rollback
Why this matters

Your gateway is the only thing in your stack that isn't in Git

App code reviewed. Infra reviewed. Database migrations reviewed. Gateway config — clicked into a portal at 4pm Friday. The gap is where outages and audit findings live.

×

Click-ops drift on the gateway

Someone tweaks a route in a portal UI, no one knows, three weeks later production breaks because the "fixed" config never made it into your IaC. The gateway is the only thing in your stack that isn't reviewable.

×

No PR review for security policies

An auth policy changes ship through a portal without a second pair of eyes. The blast radius is your whole API surface. The next penetration test finds it.

×

Rollback is a help-desk ticket

When the deploy goes sideways at 2am, the answer is "let me reach out to the gateway vendor" instead of `git revert HEAD`.

×

Two pipelines, two source-of-truth fights

App code ships through GitHub Actions. Gateway config ships through a portal. They drift. Nobody notices until an outage.

What you get

PR review, atomic deploys, real preview URLs

Ship gateway changes the way you ship code

PRs, reviews, branch protections, status checks — all the GitHub primitives your team already trusts. The gateway becomes another piece of code, not a parallel workflow.

Preview environment per PR — free

Every branch is a live, edge-deployed gateway in seconds. Reviewers click the URL, run their Postman collection, leave a comment. No staging cluster to share, no Helm chart to apply, no per-environment cost.

Zero state, zero drift

Git is the single source of truth. There's no Terraform state to reconcile, no portal that can override your repo, no `kubectl edit` footgun. What's in main is what's in production.

GitHub auto-deploy + CLI for everyone else

Same final result, two paths in

GitHub gets fully automatic deployment — connect the repo and every push deploys to the matching environment. GitLab, Bitbucket, and Azure DevOps work via source-control sync plus running the Zuplo CLI from your existing pipeline. Same atomic deploy on the other end, just one extra step.

TerminalGitHub · zero-config auto-deploy
# 1. Connect the repo in Zuplo Project Settings → Git
# 2. Push to any branch:
git push origin feature/add-rate-limit

# Zuplo auto-deploys to:
#   feature-add-rate-limit.zuplo.app  (preview)
# in ~14 seconds, and posts the URL on the PR.
YAMLGitLab / Bitbucket / Azure DevOps · CI step
# .github/workflows/deploy.yml
# Or .gitlab-ci.yml, bitbucket-pipelines.yml, azure-pipelines.yml
deploy:
  steps:
    - run: npx zuplo deploy
      env:
        ZUPLO_API_KEY: ${{ secrets.ZUPLO_API_KEY }}
      # --environment optional; defaults to current branch name
Branch = Environment
Atomic · all-or-nothing
Preview URL on every PR
GitHub deploy status comments
CODEOWNERS for sensitive policies
Same edge runtime as production
Branch deployments docs Unlimited environments
What makes Zuplo different

GitOps as a starting point, not a feature add-on

GitOps-native, not bolted on

Most legacy gateways added GitOps later via decK or Terraform shims. Zuplo started as Git-first — config IS files, deploys ARE pushes, environments ARE branches. There's no "sync to Git" step because there's nothing to sync from.

Atomic deploys, end to end

Every push either fully ships or fully fails. No partially-applied state. No "the new policy deployed but the old one didn't get removed." Edge propagation is part of the atomic transaction.

Preview = production runtime

Preview branches deploy to the same 300+ edge POPs as production, with the same isolation, the same observability, and the same performance. They're not staging shims with a fake cluster — they're real edge deployments.

GitHub status integration

Deployment status posts directly on commits. PR comments surface success, failure, and key notices. Reviewers never leave GitHub. The deploy is part of the PR experience, not a separate dashboard.

Real questions, real answers

What teams use this for

“Someone changed the auth policy and didn't tell anyone.”

Not possible — every config change is a PR with a reviewer and a CI check. Add CODEOWNERS on `policies/**` to require two approvals on auth changes. The audit trail for configuration is your `git log`.

“We need a hotfix at 3am.”

Branch off main, push the fix, get a preview URL, run smoke tests against it, merge. 90 seconds end to end. The on-call rolls back with `git revert` if anything looks wrong.

“Our gateway team is a bottleneck for every product team.”

It doesn't have to be. Each product team owns their own routes/ folder; CODEOWNERS routes their PRs to the gateway team for review on shared concerns; the rest merges on the team's own pace. Same repo, same workflow, much higher throughput.

“We're not on GitHub. Can we still use this?”

Yes. GitLab, Bitbucket, and Azure DevOps connect via source-control sync; deploy runs from your existing CI pipeline as `npx zuplo deploy --api-key $KEY`. The auto-deploy-on-push convenience is GitHub-only; everything else works the same.

Frequently Asked Questions

Common questions about GitOps with Zuplo.

Ship gateway changes the way you ship code

Free Zuplo project, point it at your GitHub repo, and your next push is your first deploy.

Start for Free Talk to a Solutions Engineer