Sandbox
Le sandbox est un environnement jetable branché sur votre projet : testez une migration, laissez un agent itérer, puis promouvez vers la production uniquement ce qui a été validé.
Ce que contient le sandbox
Le sandbox reflète votre projet — même schéma, mêmes données au moment du rafraîchissement. Il est fait pour les essais : rien de ce que vous y écrivez n’atteint la production tant que vous ne promouvez pas.
Rafraîchir depuis la production
Le rafraîchissement remplace le contenu du sandbox par une copie de la production (schéma et données). Les migrations sandbox non promues bloquent l’opération, sauf si vous choisissez explicitement de les abandonner. Un délai minimum sépare deux rafraîchissements.
Promouvoir vers la production
La promotion applique les migrations SQL en attente et copie les Edge Functions validées vers la production. La production garde ses données réelles : seul le schéma est promu, jamais un dump de données sandbox.
- Lancez d’abord l’aperçu (dry-run) : il énumère ce qui sera appliqué sans rien modifier.
- Confirmez en saisissant la référence du projet — la promotion s’applique à la production.
- Un agent peut promouvoir avec un ticket court généré depuis la page Sandbox, au lieu de disposer d’un accès permanent.
Appeler le sandbox depuis votre code
Le sandbox répond sur l’URL publique de votre projet, avec la clé anonyme sandbox et l’en-tête X-Kuunda-Env: sandbox. REST, Storage et Edge Functions suivent ce routage ; GraphQL et Realtime ne sont pas disponibles en 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"Sans l’en-tête, la requête touche la production : gardez-le dans la configuration de vos outils de test, pas dans le code livré aux utilisateurs.