Migrar desde Coolify sin tocar el servidor viejo

En pocas palabras: Se puede migrar desde Coolify, Dokploy o CapRover sin tocar el servidor viejo con el importador de solo lectura de Levelrail: lee la API de la plataforma de origen, crea apps, variables, dominios y bases vacías, y el DNS se cambia recién cuando la app nueva funciona.

Levelrail publicó el 10 de octubre de 2026 una guía para migrar desde Coolify, Dokploy o CapRover con un importador de solo lectura: lee la API de la plataforma vieja, crea apps, variables, dominios y bases vacías, y no toca el servidor de origen.

Levelrail es una plataforma de despliegue open source (Apache 2.0), todavía en beta, que corre en tus propios servidores Linux: hacés push a git y obtenés una app con HTTPS, logs, métricas y rollback. Según su repositorio, apunta a quien maneja entre 3 y 50 servicios en 1 a 10 máquinas y no quiere aprender Kubernetes.

¿Cómo funciona el importador de solo lectura de Levelrail?

El importador lee una instancia viva de Coolify, Dokploy o CapRover a través de la API HTTP de cada plataforma y no detiene, edita ni borra nada en el origen, según la guía del propio autor en dev.to. Lo podés correr desde el dashboard (Settings, Import from another platform), desde la CLI o por API, y las tres vías usan las mismas dos rutas.

La promesa fuerte es esta: según el autor, un test verifica que el importador no envía más que pedidos GET, con la única excepción del POST de login de CapRover. ¿Hay una auditoría externa que lo confirme? En la fuente no aparece ninguna, así que es una afirmación del desarrollador y conviene tratarla como tal.

Coolify, Dokploy y CapRover son plataformas self-hosted para desplegar apps en tus propios servidores sin armar todo a mano, y Levelrail apunta al mismo público. El autor, GDS K S, cierra el post con una frase que resume el enfoque: «La migración más segura es aquella en la que el servidor viejo nunca se entera de que ocurrió» (traducción nuestra del original en inglés).

El enfoque me parece sensato. Eso sí: que el origen quede intacto protege tu servicio en producción, no tus datos. Y si lo tuyo es el frontend, tenemos otra nota sobre cómo desplegar una app React con Vite.

¿Cómo se hace para migrar desde Coolify, Dokploy o CapRover paso a paso?

Son cinco pasos: crear un token de lectura en la plataforma vieja, correr un dry run, aplicar la importación, mover los datos a mano y cambiar el DNS cuando la app nueva esté sana. Solo el cuarto paso exige trabajo pesado, porque la guía aclara que los datos no viajan solos.

¿Qué token necesito para importar desde Coolify, Dokploy o CapRover?

En Coolify necesitás un API token con el permiso read:sensitive si querés que traiga los valores reales de las variables de entorno; sin él, Coolify los redacta. Dokploy usa una API key y CapRover pide la contraseña de login.

Plataforma	Credencial	Nota
Coolify	API token	Con read:sensitive para traer valores reales de env
Dokploy	API key	Se envía en el header x-api-key
CapRover	Contraseña de login	Se intercambia por un token de sesión

El token viaja al control plane de Levelrail en el cuerpo del pedido. Según la guía, el control plane lo guarda solo en memoria, no lo registra en logs ni en auditoría y lo borra del texto de los errores. Cargalo en una variable de entorno para que no quede en el historial del shell:

export APP_IMPORT_SOURCE_TOKEN=your-token

¿Qué es un dry run y por qué hay que correrlo primero?

El dry run lee el origen e imprime una fila por ítem con un estado, sin crear nada. Se ejecuta con levelrail-cli import platform coolify --url YOUR_COOLIFY_URL --dry-run, y reemplazás coolify por dokploy o caprover según el caso.

• Ready: se mapea limpio y no hay nada que hacer.
• Needs attention: se crea, con una advertencia y un paso manual sugerido.
• Not supported: no se puede importar, y el reporte explica por qué y qué hacer en su lugar.

Leé cada fila de los dos últimos estados. Esa es la lista de tareas.

¿Cómo se aplica la importación y se puede repetir?

La aplicación es repetible: cada app importada lleva un label con el id de origen y una nueva corrida saltea las que ya creó. Si falla a mitad de camino, corrés el mismo comando y reintenta solo lo pendiente; el comando sale con código distinto de cero si algo falló, así que un script puede reintentar. Sobre el destino, tenemos una guía para publicar tu web gratis en Vercel.

Ejemplo hipotético: tenés en Coolify una app web, una api y un worker, y querés probar con las dos primeras. Corrés el dry run, revisás el reporte y aplicás con --only web,api. Si un nombre ya existe en el destino, por defecto se agrega un sufijo numérico; con --collision skip lo dejás como está.

Si el origen está en una red privada hacen falta dos opt-ins juntos: APP_IMPORT_ALLOW_PRIVATE_NETWORKS=true en el control plane y --allow-private en el pedido. Con uno solo, la respuesta es un 400, y las direcciones de metadata cloud y link-local siguen bloqueadas aunque actives ambos. El servidor de destino puede ser cualquier Linux propio, como un VPS de donweb.com.

¿Qué se migra y qué no se migra?

Se migra la estructura (apps, variables, dominios y la definición de volúmenes y bases) y no se migran los datos. Según la tabla de la guía, las bases admitidas son Postgres, MySQL, MariaDB, MongoDB y Redis, desde Coolify y Dokploy.

Elemento	Qué pasa	Qué hacés vos
Apps	Llegan con imagen o git, puerto y método de build	Las de build desde git llegan con imagen pendiente: conectá el repo y buildeá
Imágenes de CapRover	CapRover builda en local	Subí la imagen a un registry o conectá un repo
Variables	Env plano, o secretos si el nombre parece sensible	Confirmá que cada secreto llegó
Dominios	Se declaran en la app	Revisalos antes del DNS
Volúmenes	Se crean vacíos	Copiá los datos antes de arrancar la app
Bases de datos	Se crean vacías	Hacé dump del origen y restauralo
Compose y one-click	Se reportan como no soportados	Desplegá el compose por separado
Cron jobs	El reporte lista schedule y comando	Recrealos a mano
Certificados, DNS, historial, logs y métricas	No migran	Re-apuntá el DNS solo con la app sana

Los nombres que parecen sensibles (password, token, key, credential, DSN y similares) pasan por el secrets manager. Si Coolify devuelve un secreto vacío porque al token le falta read:sensitive, el importador lo saltea y lo marca.

Ahora la parte que casi nadie lee: corrés el dry run, aplicás la importación, ves que las apps aparecen con las variables que esperabas, arrancás la app contra una base que está vacía (spoiler: el login falla porque no hay usuarios), y recién ahí te acordás de que el restore era trabajo tuyo y de que el importador nunca dijo lo contrario.

Es una migración “automática” a medias. La estructura se automatiza; los datos, no.

¿Es seguro migrar con Levelrail hoy? Qué está confirmado y qué no

Es razonable para probar y arriesgado para mover producción sin red de contención, porque el propio autor describe Levelrail como beta. Su recomendación es tratar el dry run como un plan, ensayar un restore de base de datos y mantener la plataforma vieja viva durante un ciclo de negocio completo. Para más detalles técnicos, mirá migrar de Vercel a un servidor propio.

• Declarado por el autor: el importador solo envía GET (salvo el login de CapRover), el control plane no persiste el token y el origen no cambia.
• Confirmado en la fuente: el alcance de lo que migra y lo que no, los estados del dry run y que deshacer es sencillo: listás las apps y bases del reporte y las borrás con levelrail-cli apps delete, además de las bases y los proyectos vacíos.
• No existe todavía: la importación en vivo de Dokku por SSH. Hay código para mapear un Compose y un dump de entorno de Dokku, pero ni la API, ni la CLI ni el dashboard lo exponen.
• Sin verificar: pruebas de terceros, auditoría del código del importador o casos de migración en producción. La fuente no trae ninguno.

La guía tampoco cubre migraciones entre Coolify, Dokploy y CapRover: el importador tiene a Levelrail como destino.

Una propuesta editorial (no viene de la fuente y no la probamos nosotros) para decidir si confiás en la importación: antes de tocar el DNS, compará la cantidad de apps y variables del reporte contra lo que ves en el destino, restaurá un dump en una base de prueba y corré la misma consulta de conteo de filas en origen y destino.

¿Qué hay que hacer a mano antes de cambiar el DNS?

Hay que restaurar los datos, conectar repos, confirmar secretos y recién después cambiar el DNS, que va último. La regla de la guía es mantener el DNS en el servidor viejo hasta que la app importada esté healthy.

• Leer el reporte completo: cada fila Needs attention y Not supported.
• Mover los datos: restaurar los dumps de bases y copiar el contenido de los volúmenes.
• Conectar repositorios: disparar los builds de las apps que llegaron con imagen pendiente.
• Confirmar secretos y dominios: que los secretos estén en cada app y que los dominios sean los correctos.
• Recrear lo que no viaja: health checks y cron jobs.
• Cambiar el DNS: al final de todo.

¿Y el downtime? La fuente no promete cero corte. Lo que sí garantiza el diseño es que el origen sigue sirviendo mientras importás. La ventana delicada es otra, y es una inferencia nuestra que la guía no trata: si el origen sigue recibiendo escrituras mientras copiás el dump, esos datos quedan afuera del destino.

Ejemplo hipotético: una app de CapRover builda en el propio servidor, así que no tiene imagen en ningún registry. Antes de importarla, subís la imagen a un registry o conectás el repo; si no, el destino no tiene de dónde sacar nada. Te puede servir nuestra cobertura de programar desde el celular con Android.

Errores comunes al migrar desde Coolify, Dokploy o CapRover

• Usar un token de Coolify sin read:sensitive. Los secretos llegan vacíos, el importador los saltea y la app arranca sin credenciales. Generá el token con ese permiso y confirmá los secretos app por app.
• Suponer que las bases traen sus datos. Se crean vacías (sí, en serio). Hacé el dump del origen y ensayá el restore antes de la fecha de corte.
• Cambiar el DNS apenas termina el import. Que el comando salga sin error no significa que la app esté sana. Esperá a que esté healthy.
• Pasar el token por la línea de comandos. Queda en el historial del shell. Usá APP_IMPORT_SOURCE_TOKEN.
• Apagar el servidor viejo enseguida. La guía recomienda tenerlo vivo durante un ciclo de negocio completo (que no es poco, si tu facturación es mensual).

Preguntas Frecuentes

¿Qué es Levelrail y es una alternativa a Coolify?

Levelrail es una plataforma de despliegue self-hosted y open source (Apache 2.0), hoy en beta. Su repositorio la presenta como alternativa a Heroku, Vercel y Railway que corre en tus servidores, y su documentación incluye una comparación con Coolify, Dokploy y CapRover. No hay una comparación independiente en las fuentes.

¿Cómo migro mis apps de Coolify sin downtime?

La guía no promete cero downtime, pero el diseño ayuda: el importador solo lee, así que Coolify sigue sirviendo mientras se crean las apps en el destino. Dejá el DNS apuntando al servidor viejo hasta que la app nueva esté healthy y los datos estén restaurados.

¿Se pueden migrar las bases de datos de Dokploy o CapRover automáticamente?

No: el importador crea las bases vacías y el contenido hay que migrarlo con un dump y su restore. Además, la guía lista Postgres, MySQL, MariaDB, MongoDB y Redis solo para Coolify y Dokploy; para CapRover no menciona bases.

¿Qué token necesito para importar desde Coolify y traer las variables de entorno reales?

Necesitás un API token de Coolify con el permiso read:sensitive. Sin él, Coolify redacta los valores sensibles y el importador saltea los secretos que vuelven vacíos y los marca en el reporte.

¿Cuándo conviene cambiar el DNS al migrar un servidor?

Al final, cuando la app importada esté healthy, los datos estén restaurados y hayas revisado secretos, dominios, health checks y cron jobs. Hasta ese momento, el DNS sigue apuntando al servidor viejo.

Conclusión

Lo que cambia con esta guía es el orden de riesgos: como el importador de Levelrail solo lee, un mal import cuesta una limpieza y no una caída. Lo que no cambia es que el trabajo difícil (datos, builds, cron jobs, DNS) sigue siendo tuyo. Si querés migrar desde Coolify, Dokploy o CapRover, empezá por el dry run, ensayá un restore completo y dejá el servidor viejo encendido hasta cerrar un ciclo de negocio. Tomá la garantía de solo lectura con pinzas hasta que alguien ajeno al proyecto la verifique.

Fuentes

• Migrate from Coolify, Dokploy or CapRover Without Touching the Old Server – guía de GDS K S sobre el importador de Levelrail (dev.to, 10 de octubre de 2026)