---
title: "GitOps for API Gateways"
description:
  "Your gateway is files in your Git repo. Every push deploys atomically. Every
  PR gets a preview URL on the global edge. Every revert is a git revert. No
  state files, no portals overriding your repo."
canonicalUrl: "https://zuplo.com/features/gitops"
sourceUrl: "https://zuplo.com/features/gitops"
pageType: "feature"
generatedAt: "2026-08-03"
---

# GitOps for API Gateways

> Your gateway is in your repo. Every push deploys. Manage your whole gateway as
> files in Git — every change reviewed in a PR, tested on a real preview URL,
> and undone with one `git revert`.

## Why this matters

Your gateway is the only thing in your stack that isn't in Git. App code is
reviewed. Infra is reviewed. Database migrations are reviewed. Gateway config
gets clicked into a portal at 4pm Friday. The gap is where outages and audit
findings live.

Common pain points with click-ops gateways:

- **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 change ships 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

- **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.

## 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.

**GitHub · zero-config auto-deploy**

```bash
# 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.
```

**GitLab / Bitbucket / Azure DevOps · CI step**

```yaml
# .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
```

Key properties of every deploy:

- Branch = Environment
- Atomic · all-or-nothing
- Preview URL on every PR
- GitHub deploy status comments
- CODEOWNERS for sensitive policies
- Same edge runtime as production

See also: [Unlimited environments](/features/unlimited-environments)

## What makes Zuplo different

- **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.

## 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.

## FAQ

**What is GitOps for an API gateway?** GitOps means your gateway configuration —
routes, policies, custom code, environment variables — lives in your Git repo as
the single source of truth. Every change goes through a PR, every deploy is a
git push, every rollback is a git revert. With Zuplo, the default branch is
production and every other branch is a real edge environment with its own URL.
No portal that can override your repo, no separate state file to drift.

**Can I deploy API changes through GitHub or GitLab?** Yes. GitHub gets fully
automatic deployments through Zuplo's GitHub App — every push to any branch
triggers a deploy with no CI step to write. GitLab, Bitbucket, and Azure DevOps
integrate via source-sync plus a single CLI command in your existing CI
pipeline. Pick the experience that matches your tooling — Zuplo doesn't force
you off the Git provider you already use.

**How do I get preview environments for API changes before merge?** With Zuplo,
every Git branch is automatically a real edge environment with its own
.zuplo.app URL. Push a feature branch and reviewers can hit the live preview
gateway, run integration tests against it, or share the URL with QA. No staging
slot to fight for, no preview shim — the preview runs on the same 300+ POPs as
production.

**How do I roll back a bad API gateway deploy?** `git revert`. Because the
gateway config is in your repo, reverting a commit and pushing reverts the
deploy. The on-call rolls back the same way they'd roll back any other code
change — no portal panel to navigate, no state file to reconcile, no separate
change-control workflow. Combine with GitHub status checks and you get
production safety nets without inventing new ones.

**How do I require code review on API policy changes?** Use the same GitHub
branch protection and CODEOWNERS rules you use for application code. Put auth
and rate-limit policies under code-owners review; require two approvals on
`policies/**`; block merges when CI fails. Zuplo doesn't override your Git
permissions — your existing review process is the gate for production gateway
changes.

**Does Zuplo replace Terraform for API gateway management?** For daily
operations, yes — Zuplo's gateway is already declarative config in Git, and
deploys are atomic with no state file to reconcile. You don't need Terraform to
manage routes and policies. Terraform still makes sense at the org level for
provisioning Zuplo accounts and integrations alongside your other cloud
resources. Different scopes, different tools.

**How fast does a gateway deploy go live with GitOps?** 10–30 seconds end-to-end
for both preview and production environments, depending on bundle size. Deploys
are atomic — every push either fully ships or fully fails, no half-applied
states. Combined with PR-preview environments, you can land a gateway change in
less time than it takes to write the commit message.

**What's the best GitOps API gateway?** Look for: config as files in your Git
repo (not a hosted DSL), automatic preview environments per branch, PR comments
with deploy status, support for GitHub / GitLab / Bitbucket / Azure DevOps, and
atomic deploys. Zuplo combines all of these and runs every preview on the same
edge that powers production. The same workflow that ships your app code ships
your gateway.

## Next steps

- Start a free account: https://portal.zuplo.com/signup
- Read the docs: https://zuplo.com/docs/concepts/source-control-and-deployment
- Read the branch deployments docs:
  https://zuplo.com/docs/articles/branch-based-deployments
- Talk to a Solutions Engineer: /schedule-call