Migrar de Oracle Always Free ARM a un VPS: guía completa

Oracle ha anunciado la reducción de su oferta Always Free ARM para el 18 de agosto de 2026: los 4 vCPU y 24 GB de RAM dejan paso a 2 vCPU y 12 GB. Además de este recorte, la oferta gratuita de Oracle siempre ha tenido riesgos estructurales que sus usuarios conocen bien: reinicios no planificados de las instancias, interrupciones durante las fases de mantenimiento de la región y ausencia de SLA sobre los recursos asignados. Oracle puede recuperar la capacidad infrautilizada sin previo aviso. Para un servicio en producción — ya sea un panel n8n, una instancia Nextcloud compartida en familia o un panel Coolify que dirige sus despliegues — esta incertidumbre es un riesgo operativo real. Un VPS facturado mensualmente ofrece una tarifa previsible, una IPv4 dedicada, un acceso root completo y unos recursos que no se redistribuyen a otro inquilino. El coste no es nulo, pero se conoce de antemano y no depende de una política que un proveedor pueda revisar unilateralmente.

Con 2 vCPU y 12 GB de RAM a partir del 18 de agosto de 2026, los nuevos límites de Oracle parecen cómodos sobre el papel. En la práctica, las aplicaciones auto-alojadas más habituales tienen requisitos mínimos que se acumulan en cuanto se combinan varias. Coolify necesita como mínimo 2 vCPU y 2 GB de RAM para su propio proceso de build y de despliegue — consume recursos por sí mismo, además de los servicios que gestiona. n8n recomienda 2 vCPU y 2 GB para funcionar de forma estable bajo carga. Nextcloud se defiende con 2 GB para menos de 50 usuarios, pero sus procesos de sincronización de archivos son exigentes en I/O y en CPU en cuanto aumenta el número de clientes activos. Immich, el gestor de fotos, recomienda 4 GB de RAM solo para su pipeline de reconocimiento de imágenes por machine learning — por debajo, los workers de ML se detienen o fallan en silencio. Si ejecuta dos o tres de estos servicios en la misma instancia Oracle, el margen desaparece y el menor pico de carga (indexación nocturna de Nextcloud, flujo n8n disparado, build de Coolify) provoca kills OOM o bloqueos. Es, por tanto, el momento oportuno para migrar a una infraestructura bien dimensionada.

Una migración exitosa se prepara con antelación, antes de tocar la configuración DNS o de apagar nada. Empiece por elaborar la lista exacta de los servicios que se ejecutan en su instancia Oracle: nombre del servicio, puerto de escucha, volumen Docker asociado, dominio o subdominio utilizado. Tome un snapshot completo de la instancia desde la consola de Oracle Cloud — es su red de seguridad ante cualquier imprevisto. Exporte también todos sus volúmenes Docker a archivos tar, que podrá transferir de forma independiente. Reduzca el TTL DNS de sus registros A a 300 segundos al menos 24 horas antes de la migración: así limita la duración de la propagación durante el cambio final. Identifique los cron jobs, webhooks entrantes y servicios de terceros que utilizan la IP actual de Oracle — algunas herramientas como Stripe, GitHub o Slack envían eventos a una URL fija que tendrá que actualizar. Por último, compruebe que sus certificados TLS se gestionan con Let's Encrypt con renovación automática, ya que tendrán que regenerarse en la nueva IP.

Una vez que los servicios funcionan en el VPS, el cambio de DNS es la etapa más visible. Modifique los registros A (y AAAA si tiene IPv6) de cada subdominio en su zona DNS, apuntando a la nueva IP del VPS. Gracias al TTL reducido a 300 segundos preparado de antemano, la propagación suele ser efectiva en menos de diez minutos en la mayoría de los resolvers. Vigile los logs de Traefik o Caddy durante las primeras horas para detectar posibles peticiones que sigan llegando a la antigua IP de Oracle. Los certificados Let's Encrypt deben regenerarse en la nueva IP: Coolify lo hace automáticamente en el primer arranque con el dominio correcto; para los servicios gestionados manualmente con Caddy o Certbot, compruebe que el reto HTTP-01 responde correctamente desde el VPS antes de eliminar la antigua instancia. Los cron jobs internos de n8n o Nextcloud sobreviven a la migración (están en la base de datos o en la configuración), pero los cron del sistema de la instancia Oracle (en /etc/cron.d o en la crontab de root) deben recrearse manualmente en el VPS. Por último, avise a los servicios de terceros que utilizaban su antigua IP de Oracle en sus listas de IP autorizadas (webhooks de Stripe, listas blancas de cortafuegos de clientes).

Durante una migración Docker, algunos errores se repiten sistemáticamente. El primero es un problema de permisos en los volúmenes restaurados: si su contenedor arranca con un UID distinto del que creó los archivos en Oracle, obtendrá errores permission denied en los logs. Corríjalo con docker run --rm -v volume:/data alpine chown -R uid:gid /data, sustituyendo uid:gid por el que espera la imagen (indicado en el Dockerfile oficial o en la documentación). El segundo error frecuente es un contenedor que arranca y se detiene de inmediato con el código 137: es un kill OOM (Out Of Memory). Revise dmesg | grep -i oom y aumente la RAM asignada al servicio o reduzca el número de workers. El tercer error tiene que ver con Let's Encrypt: si el certificado no se genera, compruebe que el puerto 80 está abierto (ufw allow 80) y que el DNS ya apunta a la nueva IP con dig +short su-dominio.com. Un registro A que sigue apuntando a Oracle impide la validación HTTP-01. Por último, si Coolify muestra los servicios como «offline» a pesar de que los contenedores Docker están en marcha, compruebe que la red Docker coolify está asociada a cada contenedor con docker network inspect coolify.