I spent today building a backup-and-restore feature for a Laravel app that manages multiple API gateway connections — each connection being a separate gateway environment (think prod, staging, a client's cluster). Kong stores all its routing, plugins, consumers and credentials in its own datastore, and "just trust the gateway's own backup" stops being good enough the moment you're orchestrating several of them from one control plane. You want your snapshot, on your schedule, scoped to one connection, that you can diff and roll back.
Here's the shape of the thing and the decisions that mattered.
A backup is a row, not a file dump
The naive version is kong config db_export > backup.yml and call it a day. That works for one gateway you SSH into. It falls apart when you've got N connections managed remotely and you want history, status, and "restore this exact one" from a UI.
So a backup became a first-class model — KongConnectionBackup — with a UUID public id, an auto-increment internal id, a foreign key to the connection, the captured payload, and two enums carrying its state. The enums are where a lot of the clarity lives:
