Leave whenever you want. Take everything.

Everything you put into apiblaze, and everything your users did through it, is yours to take. The export gives you a single zip containing:

• your proxy configuration — upstreams, routes, CORS, rate limits;
• your end users and their group memberships, in a standard format (SCIM 2.0);
• your API keys — as secure hashes, so consumers keep the keys they already have;
• your login setup and authorization rules;
• and a MIGRATION-REPORT.json that lists, item by item, exactly what translated perfectly, what's approximate, and what you'll need to finish by hand.

That last file is the point: we'd rather tell you the honest truth about a handful of things that don't map cleanly than pretend everything is perfect and let you find out later.

From the dashboard: open your project and click the Export button (it sits right next to Configure). Choose a format — Kong for a runnable gateway bundle, or Data only if you're going somewhere else — and click Export. It builds in the background and downloads a zip when it's ready.

From the CLI:

# install once
npm install -g apiblaze

# export a runnable Kong bundle
apiblaze export my-api --kong -o my-api-kong.zip

# or a target-neutral data export
apiblaze export my-api --data

The command queues the export, waits while it builds, and saves the zip locally — one step, no babysitting.

Options: --secrets includes your own decrypted provider secrets (needs member role, and it's audit-logged); --keys hashes|mint|none controls API-key handling (hashes is the default — see below).

my-api-kong.zip
├── MIGRATION-REPORT.json   ← read this first: what carried over, and how well
├── SCHEMA.md               ← plain-language guide to every file
├── project-config.json     ← your upstreams, routes, CORS, rate limits
├── openapi.json            ← your API spec
├── transforms.json         ← request/response rewrites
├── authz/                  ← authorization rules + live relationship data
├── tenants/<name>/         ← per tenant: login config, users, groups, keys
│   ├── auth/               ← app clients, login providers, JWT issuers
│   ├── users/  (+ scim/)   ← end users + SCIM 2.0 for easy import
│   └── keys/               ← API-key metadata + hashes
├── auth/keycloak-realm.json← a ready-to-import replacement login system
└── kong/                   ← everything to run it on Kong (next section)

Start with MIGRATION-REPORT.json. Every line says exact, approximate,lossy, or skipped, with a note explaining why. Nothing is hidden.

The kong/ folder is a complete, ready-to-run setup: one self-contained config file (kong.yaml holds your services, routes, consumers, and plugin wiring together), the plugin that keeps your keys and JWTs working, a Docker Compose file already pointed at everything, and a start.sh that does the whole thing for you.

The one-command way

All you need installed is Docker. Then:

unzip my-api-kong.zip -d my-api
cd my-api/kong
bash start.sh

start.sh checks Docker, boots the gateway, waits until it's healthy, prints what loaded (services, consumers), and smoke-tests that auth is enforced. Your API comes up athttp://localhost:8000/<version>/<env>/..., forwarding to the same upstream it always did. To also confirm a real credential works, hand it one:

bash start.sh --key <an existing API key>     # expects 200
bash start.sh --token <a JWT>                 # expects 200

Prefer to drive it yourself? It's just docker compose up — no merge, no edits; the compose file is already wired to the config and plugins.

Prove your consumers' keys still work

This is the part that matters — no one has to re-key. Send an existing key and watch it authenticate:

# with a real key → 200; without it → 401
curl -i http://localhost:8000/1.0.0/prod/ -H "X-API-Key: <an existing key>"

Behind that, the bundled apiblaze-auth plugin matches the SHA-256 of the incoming key against the exported hash table (and verifies JWTs the same way) — so the keys your users already have keep working, and no plaintext key was ever stored anywhere. The plugin lives in plugins/ as readable Lua and is wired in via KONG_PLUGINS — the standard OSS way to add a plugin, nothing exotic.

If something doesn't start

• docker compose logs kong prints the exact line Kong rejected.
• Port 8000 or 8001 already in use? Change the ports: mapping in docker-compose.yml.
• Getting 401 on everything? Send X-API-Key (not Authorization), and check the key existed on apiblaze.

The README.md in the folder has the same steps filled in with your project's exact versions, environments, and counts.

Here's the part most migrations get wrong. We never store your consumers' API keys in a form anyone can read — only secure one-way hashes. The bundle includes a tiny Kong plugin (apiblaze-auth) that checks an incoming key against those hashes, so every existing key keeps working on Kong — with zero plaintext ever leaving anywhere.

It's already wired up in the Docker setup. You don't issue new keys, and your users don't change a thing.

Prefer a clean break? Use --keys mint to generate fresh replacement keys plus a ready-made note to send your consumers.

The export includes auth/keycloak-realm.json — an importable realm for Keycloak, a free, open-source identity provider. It comes pre-filled with a client for each of your apps and a social/OIDC login for each provider you used.

# import the realm
kcadm.sh create realms -f auth/keycloak-realm.json

# then, in the Keycloak admin console:
#  1. set each identity provider's client secret (register your own OAuth app)
#  2. import your users from tenants/<name>/users/scim/users.json (SCIM 2.0)

Your users are portable in SCIM 2.0, the standard identity format — so they import cleanly into Keycloak, Okta, Entra, Auth0, or anything else.

1. Run both in parallel. Stand up Kong and test it while apiblaze still serves live traffic.
2. Shorten token lifetimes a day before, so old sessions expire quickly after the switch.
3. Point your DNS at Kong and issue a fresh TLS certificate (e.g. with certbot) — your old apiblaze certificate stays with us.
4. Watch, then retire. Once traffic looks healthy on Kong, disable the apiblaze proxy. Nothing is deleted until you say so.

Rolling back is just pointing DNS back — your apiblaze proxy keeps working until you delete it.

• Active login sessions. Tokens we issued only we can refresh — so users simply log in again when their current session expires (in-flight tokens keep working until then).
• Our shared GitHub login. If you used apiblaze's built-in GitHub sign-in, that app is shared across customers and can't be handed out — register your own GitHub OAuth app (a two-minute job).
• Relationship-based permissions. Simple “is in group X” rules become Kong ACLs automatically. Fine-grained “owns this specific object” rules need open-source OpenFGA plus a small plugin — your rules and live data are exported so you can.
• Usage analytics & billing credits. These are apiblaze-internal and don't mean anything on another gateway.