Déploiement

Ce que vous déployez

Un déploiement Rebase, ce sont deux pièces séparables : l’image de runtime publiée (rebasepro/server) et le bundle que rebase build produit à partir de votre projet. Il n’y a aucune image applicative à construire, et mettre Rebase à jour se résume à changer de tag plutôt qu’à reconstruire. Le même bundle tourne sur un portable avec Docker Compose, sur Rebase Cloud et sur chacune des plateformes ci-dessous.

S’il s’agit de votre premier déploiement, lisez d’abord le guide de déploiement : il décrit ce que le serveur sert, l’environnement dont il a besoin et comment désigner le premier administrateur avant le premier démarrage.

Le faire exploiter pour vous

• Rebase Cloud — le même Rebase, exploité pour vous : rebase cloud deploy depuis votre projet, une base de données par projet, sauvegardes et TLS inclus.

L’exploiter vous-même

• Auto-hébergement — l’image de runtime plus une base Postgres, avec Docker Compose ou sur un simple VPS. Commencez ici.
• Kubernetes — le chart Helm officiel, avec un Job de migration qui possède le schéma.
• Découpage en plusieurs processus — un bundle en API, couche de fonctions et worker, pour qu’une fonction lourde cesse de concurrencer l’API de données.
• Exécuter plus d’une instance — l’état que chaque processus garde pour lui, et le réglage qui le partage, avant qu’une seconde réplique ne prenne du trafic.

Guides par plateforme

Chacun reprend les deux mêmes pièces, reliées au Postgres managé et au runtime de conteneurs du fournisseur. Tous peuvent rester entièrement dans l’UE.

• Amazon Web Services — RDS et App Runner.
• Google Cloud — Cloud SQL et Cloud Run.
• Microsoft Azure — Azure Database for PostgreSQL et Container Apps.
• Hetzner Cloud — Terraform ou Docker Compose, en Allemagne ou en Finlande.
• Scaleway — Serverless Containers, en France.
• Railway — l’image et un Postgres managé, dans un même projet.
• Fly.io — mondial, ou limité aux régions de l’UE.