Viniendo de Supabase
Supabase agrupa Postgres, auth, storage y edge functions sobre su propia infraestructura. Railyard corre el código real de tu app en un servidor propio, con un complemento de Postgres administrado al lado.
Por qué los equipos dejan Supabase
Supabase es un backend-as-a-service sólido de Postgres-más-auth-más-storage. La fricción aparece cuando tu app tiene su propia lógica del lado del servidor más allá de las edge functions: un worker, un job programado, o un framework como Rails, Django o Laravel que espera correr como un proceso persistente.
Railyard despliega ese código de aplicación en un servidor propio, con Postgres administrado como un complemento en lugar de ser toda la plataforma.
Qué se viene contigo
- Tu repositorio, construido desde un Dockerfile, buildpacks, o un Procfile.
- Tus variables de entorno y secretos.
- Tu esquema y datos de Postgres, extraídos de Supabase y restaurados en el complemento de Postgres administrado de Railyard.
- La lógica de auth y storage que reimplementarás en tu propia app o con una librería, ya que Railyard no los incluye como servicio administrado.
La migración
- Conecta un servidor: uno existente, o uno nuevo que Railyard provisiona en tu cuenta de nube.
- Agrega tu repositorio y conecta un complemento de Postgres administrado.
- Migra tus datos con un dump y restore desde el Postgres de Supabase.
- Despliega a una URL temporal. Corre tu tarea de release y verifica.
- Mueve el DNS. Tu proyecto de Supabase sigue sirviendo hasta el cutover; no hay caída.
Qué es distinto
Un servidor real para el código de tu aplicación, con la base de datos como un complemento de Railyard en tu propia cuenta de nube en lugar de una plataforma compartida y facturada por uso.