Sandbox
The sandbox is a disposable environment wired to your project: try a migration, let an agent iterate, then promote only what you validated to production.
What the sandbox holds
The sandbox mirrors your project — same schema, same data as of the last refresh. It is meant for experiments: nothing you write there reaches production until you promote.
Refresh from production
A refresh replaces the sandbox contents with a copy of production (schema and data). Unpromoted sandbox migrations block the operation, unless you explicitly choose to abandon them. A minimum delay separates two refreshes.
Promote to production
Promotion applies the pending SQL migrations and copies validated Edge Functions to production. Production keeps its real data: only the schema is promoted, never a sandbox data dump.
- Run the preview (dry-run) first: it lists what will be applied without changing anything.
- Confirm by typing the project reference — promotion targets production.
- An agent can promote with a short-lived ticket generated from the Sandbox page instead of holding a permanent credential.
Call the sandbox from your code
The sandbox answers on your project’s public URL, with the sandbox anonymous key and the X-Kuunda-Env: sandbox header. REST, Storage and Edge Functions follow that routing; GraphQL and Realtime are not available in the sandbox.
curl
# $ANON_SANDBOX_KEY : la clé anonyme du sandbox, copiée depuis la console
curl "https://<ref8>.kuunda-cloud.com/rest/v1/ma_table?select=*&limit=5" \
-H "apikey: $ANON_SANDBOX_KEY" \
-H "X-Kuunda-Env: sandbox"Without the header the request hits production: keep it in your test tooling configuration, not in the code shipped to users.