How to back up Supabase Edge Functions
Supabase database backups do not contain deployed Edge Functions. Keep the function source and supabase/config.toml in version control, retain an independent copy of that repository, and keep production secret values in a separate secret manager. If the deployed project may contain Dashboard-only changes, download its current functions with the Supabase CLI before treating the repository as recoverable.
Record the recovery source for each artifact
| Artifact | Recovery copy | Check before relying on it |
|---|---|---|
| Function source | Private Git repository plus an independent repository backup | Every deployed function exists at the expected commit |
| Function configuration | supabase/config.toml | verify_jwt, entrypoint, import_map and static_files match production |
| Dependency files | Function-specific deno.json or import map in the repository | A clean checkout can bundle the function |
| Secret names | Supabase inventory and an empty example file | Every non-default name has an owner and recovery source |
| Secret values | Secret manager or controlled CI/CD secret store | Values can be read and rotated without the source project |
Git is the simplest source of truth when every deployment comes from CI. It is not enough when someone can edit or deploy a function in the Dashboard without committing the same source. Compare the deployed inventory with the repository and treat any unexplained function or version as drift to resolve, not as another informal source of truth.
Download what is currently deployed
The current Supabase CLI reference supports listing functions and downloading one or all functions from a project:
supabase functions list --project-ref "$PROJECT_REF"
supabase functions download --project-ref "$PROJECT_REF" --use-apiRun supabase functions download --help on the installed CLI before automating it. The command writes into the local Supabase project, so use a clean checkout and review the diff instead of overwriting uncommitted work.
Supabase documents an important limit in its backup and migration guide: a downloaded function does not include its import maps or deno.json files. A successful download can therefore be incomplete for rebuilding the deployment. Keep those files in the repository and test from a clean checkout.
Keep function configuration with the code
supabase/config.toml can change how a recovered function is exposed and bundled. In particular, verify_jwt controls whether the platform rejects unauthenticated calls before the handler runs. The same file can select a custom entrypoint, import map and static files. Losing it can turn a working webhook into a 401 response or deploy the wrong module.
Use the official function configuration reference as the inventory of settings to preserve. Do not infer the production value from the source code, because the platform check runs outside the handler.
Secret names are not secret-value backups
List the production secret names and compare them with the secret manager that owns their values:
supabase secrets list --project-ref "$PROJECT_REF"This is an inventory, not an export of plaintext values. For every non-default name, record where the value is stored, who can retrieve it and whether recovery should reuse or rotate it. Never commit a production .env file. An empty .env.example can document required names without creating another secret store.
The Supabase environment-variable guide documents restoring values with supabase secrets set. Default project variables such as SUPABASE_URL and project keys belong to the target project; do not copy old target-specific values into a new project.
Prove recovery on a clean project
- Create or select a non-production Supabase project and disable real external side effects.
- Deploy the backed-up functions from a clean checkout to the target project.
- Set required secret values from the controlled secret store, using target-project keys where applicable.
- Compare function names and security-relevant configuration with the capture-time inventory.
- Invoke each critical function with the same authentication mode used in production and check its database, queue or webhook result.
- Hash the recovered source tree or download the target source again and compare it with the captured version.
Put this function test after the database, Auth and Storage steps in the Supabase backup and restore checklist. The database must exist and secret-dependent integrations must be controlled before a function invocation is meaningful.
How we capture and verify functions
Every deployed function is downloaded as a source archive together with Supabase metadata for its entrypoint, import map, JWT setting and deployed version. A SHA-256 digest is calculated before upload, and the stored object is hashed again. Function metadata is captured before and after the downloads; if it changed during the run, the recovery point is rejected instead of combining different deployment states.
During recovery, the stored digest is verified before anything on the target changes, the source is deployed, and the target function is downloaded again to compare the recovered files. The implementation is in the Supabase manifest capture and Supabase recovery service. Secret names become explicit manual recovery actions; their values are deliberately never copied.
Edge Functions are one component of a recovery point. See the complete Supabase CLI backup guide for the database commands, or backup verification for the checks applied to database and non-database artifacts.