Viniendo de Netlify
Netlify está hecho para sitios estáticos y frontends JAMstack sobre la infraestructura propia de Netlify. Si tu app necesita un backend real, así se hace para correrlo en un servidor propio.
Por qué los equipos dejan Netlify
Netlify es excelente para un sitio estático o un frontend JAMstack con funciones edge. La fricción aparece en el momento en que tu app necesita un backend real: un worker, un job de larga duración, un servidor WebSocket, o cualquier cosa que no entre en una función de corta duración sobre la infraestructura de Netlify.
Railyard corre tu app como un proceso persistente en un servidor propio, junto con Postgres, MySQL o Redis administrados.
Qué se viene contigo
- Tu repositorio, construido desde un Dockerfile, buildpacks, o un Procfile.
- Tus variables de entorno y secretos.
- Los deploy previews de Netlify se mapean a los entornos de preview de Railyard por pull request.
- Un frontend estático puede quedarse en Netlify; el backend se muda a Railyard detrás del mismo dominio.
La migración
- Conecta un servidor: uno existente, o uno nuevo que Railyard provisiona en tu cuenta de nube.
- Agrega tu repositorio y deja que Railyard detecte tu framework, o apúntalo a tu Dockerfile.
- Trae tu configuración y conecta los datastores que tu app espera.
- Despliega a una URL temporal. Corre tu tarea de release y verifica.
- Mueve el DNS para la ruta o el subdominio del backend. No hay caída.
Qué es distinto
Un servidor real para las partes de tu app que lo necesitan, con HTTPS, releases sin downtime y bases de datos administradas, a un precio fijo por equipo en lugar de facturación por invocación.