Viniendo de Cloud 66
Cloud 66 fue pionero en el control plane sobre servidores propios. Railyard es la versión más ligera y económica del mismo modelo. Así se hace la migración.
Por qué los equipos dejan Cloud 66
Cloud 66 demostró el modelo hace años: un control plane sobre servidores propios, en cualquier nube. La fricción hoy está en el peso y el precio. La interfaz carga una década de funciones que la mayoría de los equipos pequeños nunca toca, el precio arranca muy por encima del presupuesto de alguien solo o de un equipo pequeño, y es un producto cerrado: tú lo configuras, no lo corres tú mismo.
Railyard es una versión deliberadamente pequeña de la misma idea: conecta un servidor, haz push de tu código, obtén lo esencial del día dos, a un precio que no escala con el tamaño de tu equipo.
Qué se viene contigo
- Tu repositorio, construido desde un Dockerfile, buildpacks, o un Procfile.
- Tus variables de entorno y secretos.
- Los releases sin downtime al estilo ActiveDeploy se trasladan como el cutover de verificar-y-luego-cambiar de Railyard.
- Los Postgres / MySQL / Redis administrados se mapean directo a complementos de Railyard.
- Tus servidores existentes: conéctalos por SSH en lugar de reconstruir la flota.
La migración
- Conecta un servidor: uno existente de Cloud 66, o uno nuevo que Railyard provisiona en tu cuenta de nube.
- Agrega tu repositorio y elige el método de build que coincida con cómo lo construye Cloud 66 hoy.
- Trae tu configuración y conecta los datastores que tu app espera.
- Despliega a una URL temporal. Corre tu tarea de release y verifica.
- Migra los datos con un dump y restore hacia el complemento administrado.
- Mueve el DNS. El stack de Cloud 66 sigue sirviendo hasta el cutover; no hay caída. Luego dalo de baja.
Qué es distinto
Menos superficie, menos costo, y un flujo de trabajo que te cabe en la cabeza: un panel, una acción clara por pantalla, y nada por lo que estés pagando sin usarlo.