---
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-10-21"
---

# Your gateway is in your repo. Every push deploys.

> Click-ops gateways drift, resist review, and make rollback a fire drill. 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`.

Flow shown in the hero: `git push` on `feature/add-rate-limit` → pull request opened (PR #4821, checks running) → preview URL deployed (`feature-add-rate-limit.zuplo.app`, 14s) → merged to main → atomic deploy → production live (`api.acme.com`, 300+ POPs, 11s). Highlights: atomic deploys, preview per branch, `git revert` to rollback.

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

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

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

Capabilities: 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](https://zuplo.com/docs/articles/branch-based-deployments)
- [Unlimited environments](/features/unlimited-environments)

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

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

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

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

- [Start for Free](https://portal.zuplo.com/signup)
- [Talk to a Solutions Engineer](/schedule-call)
- [Read the Docs](https://zuplo.com/docs/concepts/source-control-and-deployment)