Viniendo de Fly.io

Por qué los equipos dejan Fly

Fly hace fácil correr contenedores cerca de los usuarios. Pero la facturación basada en uso es difícil de pronosticar, la plataforma decide qué regiones y tamaños de machine te tocan, y “Fly Postgres” es un Postgres que administras tú mismo sobre machines de Fly.

Railyard te da el mismo flujo de trabajo centrado en contenedores sobre un servidor Linux en tu propia cuenta de nube (como DigitalOcean, Hetzner, Vultr o AWS), o en cualquier máquina con Ubuntu a la que puedas entrar por SSH. Tu proveedor te factura directamente, a su precio, y Railyard administra Postgres, Redis y las copias de seguridad por ti.

La forma rápida: el importador (beta)

Applications → New app → Import from Heroku / Render / Fly. Elige Fly.io, pega un token de fly tokens create org e ingresa tu organización de Fly (por defecto es personal). Elige una app, revisa qué se copiará, y luego importa y despliega. Railyard conserva tu token solo durante esta importación y lo olvida después de 30 minutos.

Qué trae el importador desde la Machines API de Fly:

• La imagen exacta que corre Fly, descargada con tu token como contraseña del registro, así que no se reconstruye nada.
• Variables de entorno desde la configuración de la machine, y el puerto interno.
• Nombres de secretos. Fly nunca revela los valores de los secretos, así que la página de revisión los lista para que los vuelvas a ingresar.

Lo que solo te señala:

• Otros process groups (un worker, por ejemplo) no se copian. Agrégalos como workers.
• Los volumes empiezan vacíos. Copia sus archivos tú mismo (ver abajo).
• Los datos de Postgres no los copia el importador de Fly. Muévelos con un dump (ver abajo).
• Los dominios se listan, no se conectan. Agrégalos una vez que la nueva app esté en vivo.

Beta: el importador se probó contra las respuestas documentadas de la API de Fly, y en prod llega a la API de Fly. Todavía no se ha corrido de punta a punta contra una cuenta real de Fly. Si algo no se copia bien, usa los pasos manuales de abajo y cuéntanos.

La forma manual

1. Agrega un servidor. Railyard puede crear uno en tu cuenta de nube, o puedes conectar uno que ya tengas. Consulta Add a server.
2. Crea la app. Si tu repositorio tiene un Dockerfile, como la mayoría de las apps de Fly, apunta Railyard al repositorio y construirá desde ahí. O despliega la imagen que ya subes a un registro. Consulta Deploy a Docker image.
3. Define el puerto. Usa el internal_port de la sección [http_service] o [[services]] de tu fly.toml.
4. Trae tu configuración. Copia el bloque [env] de fly.toml a Variables. fly secrets list muestra los nombres de los secretos; pega los valores desde donde los guardes.
5. Agrega una base de datos. Conecta Postgres (y Redis si lo usas). Railyard crea la base de datos y define DATABASE_URL / REDIS_URL.
6. Despliega y revisa la app en su dirección temporal de sslip.io.
7. Mueve los datos. Abre un túnel con fly proxy 15432:5432 -a <your-postgres-app>, corre pg_dump -Fc contra localhost:15432, y luego sube el dump con Resources → Import data en la app de Railyard. La subida muestra progreso, y puedes cancelarla. Para archivos en un volume de Fly, usa fly ssh sftp get (o tar sobre fly ssh console) y restáuralos en el volumen o bucket de la app.
8. Cambia el DNS. Agrega tu dominio en Railyard, y luego apunta el registro a tu servidor. Fly sigue sirviendo hasta que el registro cambia, así que nada se cae. Luego escala la app de Fly a cero y elimínala.

Cómo se mapean los conceptos de Fly

Fly	Railyard
Machines en varias regiones	Uno o más servidores propios. El proceso web de una app puede correr en varios servidores detrás del primario
Process groups ([processes])	Tipos de proceso: web más workers, desde un Procfile o definidos a mano
release_command	Comando de release, se corre una vez antes de que la nueva versión reciba tráfico
Health checks	Una ruta de salud. La nueva versión debe pasarla antes de que se mueva el tráfico
Volumes	Volumes en el servidor, con copias de seguridad
Fly Postgres / Managed Postgres	Postgres administrado en tu servidor o en un servidor de base de datos, con copias de seguridad verificadas y restauración a un punto en el tiempo
fly deploy	git push, railyard deploy, o un push a GitHub
fly logs / fly ssh console	railyard logs --follow / railyard run y la pestaña Console
Auto-stop machines	Suspensión de app: los stagings inactivos se suspenden y despiertan con la siguiente solicitud

Qué es distinto

Railyard no corre un edge anycast. Tu app se sirve desde la región de tu servidor, y todavía no hay enrutamiento automático multi-región. A cambio, la cuenta es un precio plano de servidor que puedes predecir, las machines son tuyas, y si dejas de usar Railyard tu app sigue corriendo.