Aurabase Logo
aurabasedocs
docs›Guides›Déploiement

Déploiement

Migrations zero-downtime, rollback atomique, CI/CD via GitHub Actions / GitLab / CLI. Deux environnements de base aujourd'hui (dev, prod) ; les branch previews par PR sont en roadmap, pas encore livrées.

8 min de lecture·Niveau intermédiaire·Révisé le 15 avr. 2026
#
Vue d’ensemble

Trois surfaces de déploiement

Un projet Aurabase expose trois surfaces à déployer : schéma Postgres (migrations SQL versionnées), edge functions (WASM + cron + jobs), policies et secrets (RLS, env vars, OAuth apps). Chacune se pousse indépendamment via aura CLI.

Le CLI est self-contained (téléchargé une fois, pas de dépendance Node) et supporte dry-run, confirm prompts, diff prévisualisation. Compatible Linux / macOS / Windows.

#
Environnements

Dev, preview, prod

Par défaut, un projet a deux environnements : dev (local, Kubernetes) et prod (cloud). Les branch previews (un environnement éphémère par PR ouverte) sont en roadmap, pas encore livrées.

flux
TEXT
LOCAL DEV
    $ ./start.sh              → aura stack complet en local (k3d)
    $ aura dev                → watch mode + types gen
PREVIEW (par PR)
    git push origin feat/xyz  → GitHub Action crée branch Aurabase
    aurabase preview ready    → URL unique commentée sur la PR
    pr merged                 → cleanup automatique
PRODUCTION
    merge to main             → CI run: aura db push --env prod
                              → aura deploy functions
#
Migrations

SQL versionné, rollback atomique

Les migrations vivent dans supabase/migrations (compat Supabase) ou aurabase/migrations. Un fichier par changement, timestamp en préfixe. Le CLI applique les migrations manquantes et génère automatiquement les types TypeScript.

terminal
BASH
# Créer une nouvelle migration
aura migration new add_devices_table
# → aurabase/migrations/20260415120000_add_devices_table.sql
# Appliquer les migrations en prod (dry-run first)
aura db push --env prod --dry-run    # prévisualise le diff
aura db push --env prod --confirm    # applique vraiment
# Régénérer les types TypeScript
aura db generate > src/aurabase.types.ts
# Lister les migrations appliquées
aura migration list --env prod
Attention
Zero-downtime migrations. Suivez les règles : ajout de colonne nullable d'abord, backfill séparé, constraint NOT NULL en dernier. Le CLI refuse les migrations non rétrocompatibles sans --allow-breaking.
#
Branch previews

Une base éphémère par PR (roadmap)

Attention
Roadmap — non disponible. Les branch previews (clone Postgres copy-on-write par PR) sont une fonctionnalité prévue, pas encore livrée. Cette section décrit le modèle cible ; les commandes ci-dessous ne sont pas encore fonctionnelles.

À chaque PR, une GitHub Action créerait une nouvelle branche Aurabase — clone Postgres copy-on-write (provisioning ~10s), clés API uniques, fonctions déployées, URL commentée sur la PR.

cli
BASH
# Créer manuellement une branche
aura branch create feat/new-checkout
# → https://feat-new-checkout.projet.aurabase.cloud
# Avec données seed clonées de prod (Pro+)
aura branch create feat/new-checkout --from prod --seed 1000
# Lister les branches actives
aura branch list
# Nettoyer manuellement
aura branch delete feat/new-checkout
Info
TTL : 72h par défaut (Free), 14 jours (Pro), illimité (Enterprise). Les branches inactives sont suspendues (0 coût) avant suppression définitive.
#
CI / CD

Trois intégrations prêtes

Le CLI fonctionne avec n'importe quel CI. Voici les recettes pour les trois plus courants.

.github/workflows/deploy.ymlYAML
name: Deploy to Aurabase
on:
  push: { branches: [main] }
  pull_request: {}
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aurabase/setup-action@v1
        with: { token: ${{ secrets.AURA_TOKEN }} }
      - run: aura db push --env ${{ github.ref == 'refs/heads/main' && 'prod' || 'preview' }}
      - run: aura deploy functions
#
Rollback

Atomique, via down migration

Chaque migration 20260415_xxx.sql peut avoir un fichier 20260415_xxx.down.sql. Le rollback applique les .down.sql dans l'ordre inverse, atomiquement dans une transaction.

rollback
BASH
# ROADMAP — aura db rollback n’est pas encore disponible.
# Le seul rollback réel aujourd’hui est transactionnel (une migration ratée
# est annulée dans sa transaction). Le revert versionné multi-étapes est prévu.
# Rollback de la dernière migration
aura db rollback --env prod --steps 1
# Rollback à un timestamp précis
aura db rollback --env prod --to 20260410000000
# Point-in-time recovery (Pro+) — revient à un instant T
aura db restore --env prod --to "2026-04-14T10:30:00Z"
Attention
PITR : backups continus 14 jours (Pro), 90 jours (Enterprise). Le restore crée une nouvelle instance — à vous de basculer le traffic ensuite.
Dernière mise à jour · 15 avr. 2026