Zum Inhalt springen

Deployment

Ein Rebase-Deployment besteht aus zwei trennbaren Teilen: dem veröffentlichten Runtime-Image (rebasepro/server) und dem Bundle, das rebase build aus Ihrem Projekt erzeugt. Es gibt kein Anwendungs-Image zu bauen, und ein Upgrade von Rebase ist eine Tag-Änderung statt eines Rebuilds. Dasselbe Bundle läuft lokal unter Docker Compose, auf Rebase Cloud und auf jeder der unten genannten Plattformen.

Wenn dies Ihr erstes Deployment ist, lesen Sie zuerst den Deployment-Leitfaden: Er beschreibt, was der Server ausliefert, welche Umgebung er braucht und wie Sie den ersten Administrator vor dem ersten Start festlegen.

  • Rebase Cloud — dasselbe Rebase, von uns betrieben: rebase cloud deploy aus Ihrem Projekt, eine Datenbank pro Projekt, Backups und TLS inklusive.
  • Self-Hosting — das Runtime-Image plus eine Postgres-Datenbank, mit Docker Compose oder auf einem einfachen VPS. Beginnen Sie hier.
  • Kubernetes — das offizielle Helm-Chart, mit einem Migrations-Job, der das Schema besitzt.
  • Aufteilung in mehrere Prozesse — ein Bundle als API, Functions-Ebene und Worker, damit eine rechenintensive Function nicht mehr mit der Daten-API konkurriert.
  • Mehr als eine Instanz ausführen — der Zustand, den jeder Prozess für sich behält, und die Einstellung, die ihn teilt, bevor eine zweite Replik Traffic übernimmt.

Jede davon besteht aus denselben zwei Teilen, verbunden mit dem verwalteten Postgres und der Container-Laufzeit des jeweiligen Anbieters. Alle lassen sich vollständig innerhalb der EU betreiben.

  • Amazon Web Services — RDS und App Runner.
  • Google Cloud — Cloud SQL und Cloud Run.
  • Microsoft Azure — Azure Database for PostgreSQL und Container Apps.
  • Hetzner Cloud — Terraform oder Docker Compose, in Deutschland oder Finnland.
  • Scaleway — Serverless Containers, in Frankreich.
  • Railway — das Image und ein verwaltetes Postgres in einem Projekt.
  • Fly.io — global oder auf EU-Regionen festgelegt.