Lo que Dokku y Coolify hacen bien
Primero el crédito, porque es merecido. Dokku destiló el bucle central de Heroku — git push, mirar el build, la app está en producción — en una herramienta de servidor único que lleva una década siendo fiable. Coolify envolvió la misma idea en una UI genuinamente agradable con bases de datos de un clic y una biblioteca de plantillas creciente. Ambos gestionan TLS, ambos hablan Dockerfile, y ambos corren en hardware que controlas por completo, lo cual importa cuando los datos deben quedarse donde están o cuando un VPS de precio fijo es todo el presupuesto.
Si hoy usas uno de estos y estás contento, nada de lo que sigue argumenta que te equivocaste. La pregunta que responde esta guía es más estrecha y solo aparece con el tiempo: ¿quién opera la plataforma que hay debajo de tu plataforma — y sigue siendo ese el mejor uso de tus horas?
La partida que el README omite: tú eres el equipo de plataforma
Un PaaS autoalojado es software que ejecutas en un servidor que tú ejecutas. Dos capas, ambas tuyas. El servidor necesita parches de seguridad del SO, endurecer el SSH, y un disco que se llena silenciosamente de imágenes Docker y cachés de build hasta que los deploys de la mañana empiezan a fallar con "no space left on device" — el incidente clásico de Dokku, y siempre elige su momento. El propio PaaS necesita actualizaciones cuyo changelog lees con atención, porque se sienta entre tu código y producción, y un breaking change ahí ES un cambio en producción.
Luego vienen las preguntas más afiladas. Backups: las bases de datos que tu PaaS creó con un clic — ¿quién las vuelca, adónde van los volcados, y cuándo probó alguien por última vez una restauración? Alta disponibilidad: un solo servidor significa que un reinicio del host tumba todas las apps a la vez. Nada de esto es trabajo exótico. Es un empleo a tiempo parcial de ingeniería de plataforma que llegó en silencio con el script de instalación, facturado en tus tardes.
El mismo bucle, operado por otros
El flujo que de verdad te gusta es push-to-deploy, y eso no es lo que estarías cediendo. En cdn.com.tr, GitHub Deploy conecta un repositorio y convierte un push en un deploy: la plataforma trae la rama, construye tu Dockerfile en un builder aislado (sin necesidad de cuenta de registry), ejecuta los pasos que definas y despliega la release detrás de un healthcheck — el tráfico se mueve al contenedor nuevo solo cuando este reporta que está listo, así que un build roto nunca tumba el sitio. La caché del edge que hay delante se purga automáticamente en cada deploy.
Lo que cambia es a quién le suena el busca. Parchear el host, actualizar el builder, el disco y la disponibilidad de la propia plataforma dejan de ser tu lado de la mesa. Postgres y Redis gestionados sustituyen los contenedores de un clic por bases de datos operadas y respaldadas como servicio, y el object storage compatible con S3 sustituye el patrón de volumen-en-este-servidor para las subidas. El trueque honesto, el de siempre: sin root en el host, sin instalaciones a nivel de SO, el tráfico público es HTTP(S). Tu Dockerfile es el contrato — que es también lo que mantiene abierta la puerta de salida.
Cómo se ve el lado del panel
Los usuarios de Coolify en particular encontrarán la forma familiar: aplicaciones con dominios, variables de entorno y secretos, logs que puedes leer sin SSH, y bases de datos adjuntas a las apps — menos las páginas de configuración del servidor, porque debajo no hay ningún servidor tuyo. Las container apps llevan su healthcheck, su número de réplicas y su almacenamiento persistente como ajustes de primera clase, y todo lo que hay en pantalla también es scriptable desde la misma CLI, así que la UI es una vista de la plataforma y no la única puerta de entrada.
Todo lo que está en el panel también está a una CLI de distancia
# see your apps and read logs without SSH
cdnctl container apps list --account <uuid>
cdnctl container apps logs --account <uuid> --app <app_uuid> --tail 100
# scale, restart, roll back — the operations you actually reach for
cdnctl container apps scale --account <uuid> --app <app_uuid> --replicas 2
cdnctl container apps restart --account <uuid> --app <app_uuid>
cdnctl container apps rollback --account <uuid> --app <app_uuid> --revision <revision_uuid>Migrar: más pequeño de lo que crees
Tu app ya vive en Git, y bajo Dokku o Coolify ya se construye desde un Dockerfile o una estructura construible — lo que significa que la parte dura de la migración ocurrió hace mucho. Mudarse es reapuntar adónde va el push, más una pasada de datos.
Conecta el repositorio a GitHub Deploy (o, si la app está descrita por un docker-compose.yml, impórtalo: los servicios con sección `build:` se construyen desde sus Dockerfiles, y las bases de datos se convierten en complementos gestionados). Recrea las variables de entorno y los secretos. Mueve los datos: vuelca la base de datos y restáurala en la gestionada, y copia los ficheros subidos al object storage. Ejecuta ambas plataformas en paralelo unos días — el servidor viejo sigue sirviendo mientras verificas el deploy nuevo — y luego cambia el DNS y retira la máquina a tu propio ritmo.
Una app descrita con compose: previsualiza el plan y luego aplícalo
# see exactly what your compose file becomes — nothing is created yet
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# apply when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.yml
# data: dump on the old box, restore into the managed database
pg_dump -Fc appdb > appdb.dump
pg_restore -d "$MANAGED_DATABASE_URL" appdb.dump
# uploads: from the old server's volume into object storage
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./uploads s3://app-uploadsCuándo seguir autoalojado
La simetría exige esta sección. Quédate con Dokku o Coolify cuando el servidor te sale genuinamente gratis — un homelab, hardware que ya tienes y que disfrutas operando. Quédate cuando la localidad de los datos es una restricción dura y la máquina debe ser tuya. Quédate cuando el trabajo operativo es el objetivo: operar tu propia plataforma es una de las mejores maneras de aprender todo este campo. Y quédate cuando necesitas algo que el trueque gestionado excluye — root, puertos TCP en bruto, dependencias de sistema exóticas que no caben en una imagen de contenedor.
Si nada de eso te describe — si la plataforma bajo tus apps es una tarea pendiente y no un hobby o un requisito — entonces el flujo que te gusta es portable, y el busca es opcional.
Preguntas frecuentes
¿Pierdo el flujo de git push al dejar Dokku?
No — ese flujo es el producto aquí. GitHub Deploy convierte un push en un ciclo de pull-build-release con una puerta de healthcheck, y Docker Compose Instant Deploy cubre las apps multiservicio. Lo que dejas de hacer es operar la máquina que lo ejecuta.
Mi app de Dokku usa buildpacks, no un Dockerfile. ¿Puede moverse?
Sí, con un paso pequeño: añade un Dockerfile. Para la mayoría de apps con buildpacks es un puñado de líneas (imagen base, copiar, instalar, comando de arranque), y hace la app portable a cualquier plataforma de contenedores — esta incluida. Merece la pena hacerlo aunque te quedes en Dokku.
¿Qué sustituye a las bases de datos de un clic de Coolify?
Los complementos gestionados de Postgres y Redis — adjuntos a tus apps de la misma manera, pero operados y respaldados como servicio en lugar de correr como contenedores cuyo disco y volcados son tu responsabilidad.
¿Puedo migrar gradualmente en vez de en un solo corte?
Sí, y deberías: despliega en la plataforma gestionada mientras el servidor viejo sigue sirviendo producción, verifica contra el build real, presincroniza los datos, y mueve el DNS cuando estés satisfecho. La máquina vieja es un excelente plan de rollback hasta que la apagues.