Depuis Supabase
Supabase regroupe Postgres, l'authentification, le stockage et les edge functions sur sa propre infrastructure. Railyard fait tourner le code de votre application sur un serveur que vous possédez, avec un module Postgres géré à côté.
Pourquoi les équipes quittent Supabase
Supabase est un solide backend-as-a-service Postgres-plus-auth-plus-storage. La friction apparaît quand votre application a sa propre logique côté serveur au-delà des edge functions : un worker, une tâche planifiée, ou un framework comme Rails, Django ou Laravel qui s’attend à tourner comme un processus persistant.
Railyard déploie ce code applicatif sur un serveur que vous possédez, avec Postgres géré comme un module complémentaire plutôt que comme la plateforme entière.
Ce qui vous suit
- Votre dépôt, construit à partir d’un Dockerfile, de buildpacks, ou d’un Procfile.
- Vos variables d’environnement et vos secrets.
- Votre schéma Postgres et vos données, extraits de Supabase et restaurés dans le module Postgres géré de Railyard.
- La logique d’authentification et de stockage, que vous réimplémenterez dans votre propre application ou avec une bibliothèque, car Railyard ne les regroupe pas comme service géré.
La migration
- Rattachez un serveur : un serveur existant, ou un nouveau serveur que Railyard provisionne dans votre compte cloud.
- Ajoutez votre dépôt et ajoutez un module Postgres géré.
- Migrez vos données avec une sauvegarde et une restauration depuis le Postgres de Supabase.
- Déployez vers une URL temporaire. Exécutez votre tâche de release et vérifiez.
- Basculez le DNS. Votre projet Supabase continue de répondre jusqu’à la bascule ; il n’y a aucune interruption.
Ce qui change
Un vrai serveur pour le code de votre application, avec la base de données comme module Railyard dans votre propre compte cloud plutôt qu’une plateforme partagée et facturée à l’usage.