Deployment

Che cosa si distribuisce

Un deployment di Rebase è fatto di due pezzi separabili: l’immagine di runtime pubblicata (rebasepro/server) e il bundle che rebase build produce dal tuo progetto. Non c’è nessuna immagine applicativa da costruire, e aggiornare Rebase è un cambio di tag anziché una ricompilazione. Lo stesso bundle gira in locale con Docker Compose, su Rebase Cloud e su tutte le piattaforme elencate sotto.

Se è il tuo primo deployment, leggi prima la guida al deployment: spiega che cosa serve il server, di quale ambiente ha bisogno e come nominare il primo amministratore prima del primo avvio.

Fallo gestire a noi

• Rebase Cloud — lo stesso Rebase, gestito per te: rebase cloud deploy dal tuo progetto, un database per progetto, backup e TLS inclusi.

Gestiscilo tu

• Self-hosting — l’immagine di runtime più un database Postgres, con Docker Compose o su un semplice VPS. Parti da qui.
• Kubernetes — il chart Helm ufficiale, con un Job di migrazione che possiede lo schema.
• Suddivisione in più processi — un bundle come API, livello functions e worker, così una function pesante smette di competere con l’API dei dati.

Guide per piattaforma

Ognuna usa gli stessi due pezzi, collegati al Postgres gestito e al runtime di container di quel provider. Tutte possono restare interamente nell’UE.

• Amazon Web Services — RDS e App Runner.
• Google Cloud — Cloud SQL e Cloud Run.
• Microsoft Azure — Azure Database for PostgreSQL e Container Apps.
• Hetzner Cloud — Terraform o Docker Compose, in Germania o in Finlandia.
• Scaleway — Serverless Containers, in Francia.
• Railway — l’immagine e un Postgres gestito, in un unico progetto.
• Fly.io — globale, o limitato alle regioni UE.