Viniendo de Render

Por qué los equipos dejan Render

Render clavó la experiencia de desarrollo. El truco es el mismo que tiene toda plataforma administrada: corre sobre infraestructura que no controlas. Los costos de instancia y ancho de banda suben a medida que tienes éxito, la lista de regiones es de ellos, tus datos están donde ellos los pusieron, y salir es una migración real, no un cambio de DNS.

Railyard mantiene la experiencia de push para desplegar y la traslada a un servidor Linux en tu propia cuenta de nube: mismo flujo de trabajo, tu metal, tu cuenta.

Qué se viene contigo

• Tu repositorio. Railyard construye desde un Dockerfile (el mismo que usa Render) o desde buildpacks.
• La intención de tu render.yaml: los servicios web y worker se convierten en tipos de proceso de Railyard; un preDeployCommand se convierte en una tarea de release.
• Tus variables de entorno y grupos de entorno.
• Render Postgres y Render Key Value / Redis se mapean a complementos administrados de Postgres y Redis con URLs inyectadas.
• Dominios personalizados con TLS automático.

La migración

1. Apunta Railyard a un servidor en tu cuenta de DigitalOcean / Hetzner / AWS, o conecta uno que ya tengas corriendo.
2. Agrega tu repositorio y elige el método de build que usa Render hoy, normalmente el Dockerfile.
3. Recrea tu configuración. Pega las variables de entorno; conecta Postgres y Redis para que las URLs queden conectadas.
4. Despliega a la URL temporal y pon a prueba la app, incluyendo los trabajos en segundo plano.
5. Mueve tus datos. Toma un pg_dump de Render y restáuralo en el complemento administrado.
6. Redirige el DNS. Render sigue sirviendo hasta que el registro cambia, sin downtime. Luego suspende los servicios de Render.

Qué es distinto

La máquina es tuya. Sin sorpresas de egress por GB, sin esperar a que agreguen una región, y si alguna vez dejas Railyard los contenedores siguen corriendo en la máquina que ya posees.