Viniendo de Hatchbox.io
Hatchbox y Railyard apuestan por lo mismo, tus servidores, push para desplegar. Así se ve la migración, y dónde Railyard cubre más del día dos.
Por qué los equipos miran más allá de Hatchbox
Hatchbox hizo bien lo importante: desplegar en servidores que tú posees, sin markup de cómputo. Si eso te está funcionando, no hay una razón urgente para migrar.
Dónde la gente empieza a mirar: Hatchbox es una capa delgada sobre una configuración bastante manual, cerca de la configuración de Nginx y los internals del servidor, y la superficie administrada se queda corta pronto. No hay un release de verificar-y-luego-cambiar con un cutover verificado por salud, no hay un entorno de preview por pull request, no hay roles / 2FA / registro de auditoría, y las copias de seguridad las tienes que organizar tú. También es un producto de un solo mantenedor con un roadmap silencioso.
Railyard es la misma apuesta de “tus servidores” con más del día dos ya resuelto por ti.
Qué se viene contigo
- Tu repositorio y tu Dockerfile, o el camino de Nixpacks / buildpacks de Railyard si hoy despliegas sin uno.
- Tus tipos de proceso del Procfile.
- Tus variables de entorno.
- Tu base de datos. El Postgres / MySQL / Redis administrado de Hatchbox se mapea a complementos de Railyard con connection strings inyectados.
- Tus servidores, si quieres conservarlos: conecta una máquina existente por SSH en lugar de provisionar una nueva.
La migración
- Conecta un servidor. Apunta Railyard a uno de tus servidores actuales de Hatchbox, o a uno nuevo en tu cuenta de nube.
- Agrega tu repositorio y confirma el método de build. Un Dockerfile se despliega tal cual.
- Trae tus variables y conecta los datastores que necesites.
- Despliega a una URL temporal y revísala de punta a punta, incluyendo una tarea de release si corres migraciones.
- Mueve tus datos con un dump y restore estándar hacia el complemento administrado.
- Redirige el DNS. La app anterior sigue sirviendo hasta que el registro cambia; nada se apaga. Luego da de baja la app de Hatchbox.
Qué es distinto
Obtienes un cutover sin downtime y verificado por salud en cada despliegue, rollback de un clic con el commit y el autor registrados, un despliegue de preview por cada PR, roles reales y un registro de auditoría, y copias de seguridad que se prueban para restaurar, además de la propiedad que ya tenías.