Aurabase Logo
aurabasedocs
docs›Guides›Déploiement

Déploiement

Branches Postgres éphémères par PR, migrations zero-downtime, rollback atomique, CI/CD via GitHub Actions / GitLab / CLI. Trois environnements de base : dev, preview, prod.

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

Trois surfaces de déploiement

§ 01

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

§ 02

Par défaut, un projet a deux environnements : dev (local, Docker) et prod(cloud). Les branch previews ajoutent autant d'environnements éphémères que vous avez de PRs ouvertes.

flux
TEXT
LOCAL DEV
    $ docker compose up       → aura stack complet en local
    $ 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

§ 03

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 types gen > 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

§ 04

À chaque PR, GitHub Action crée 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.dev
# 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

§ 05

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

§ 06

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

rollback
BASH
# 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