Migrer d'Oracle Always Free ARM vers un VPS : guide complet

Oracle a annoncé la réduction de son offre Always Free ARM pour le 18 août 2026 : les 4 vCPU et 24 Go de RAM cèdent la place à 2 vCPU et 12 Go. Outre cette coupe, l'offre gratuite Oracle a toujours comporté des risques structurels que ses utilisateurs connaissent bien : redémarrages non planifiés des instances, interruptions lors des phases de maintenance de la région, et absence de SLA sur les ressources allouées. Oracle peut récupérer les capacités sous-utilisées sans préavis. Pour un service de production — qu'il s'agisse d'un tableau de bord n8n, d'une instance Nextcloud partagée en famille ou d'un panneau Coolify qui pilote vos déploiements — cette incertitude est un risque opérationnel réel. Un VPS facturé mensuellement propose un forfait prévisible, une IPv4 dédiée, un accès root complet et des ressources qui ne sont pas redistribuées à un autre locataire. Le coût n'est pas nul, mais il est connu à l'avance et ne dépend pas d'une politique qu'un fournisseur peut réviser unilatéralement.

Avec 2 vCPU et 12 Go de RAM après le 18 août 2026, les nouvelles limites Oracle semblent confortables sur le papier. En pratique, les applications auto-hébergées les plus courantes ont des exigences minimales qui s'accumulent dès que vous en combinez plusieurs. Coolify nécessite au minimum 2 vCPU et 2 Go de RAM pour son propre processus de build et de déploiement — il consomme lui-même des ressources en plus des services qu'il gère. n8n recommande 2 vCPU et 2 Go pour fonctionner de façon stable sous charge. Nextcloud s'en sort avec 2 Go pour moins de 50 utilisateurs, mais ses processus de synchronisation de fichiers sont gourmands en I/O et en CPU dès que le nombre de clients actifs augmente. Immich, le gestionnaire de photos, recommande 4 Go de RAM uniquement pour son pipeline de reconnaissance d'image par machine learning — en dessous, les workers ML s'arrêtent ou crashent silencieusement. Si vous faites tourner deux ou trois de ces services sur la même instance Oracle, la marge devient nulle, et le moindre pic de charge (indexation nocturne Nextcloud, flux n8n déclenché, build Coolify) provoque des kills OOM ou des freezes. Le moment est donc opportun pour migrer vers une infrastructure dimensionnée.

Une migration réussie se prépare en amont, avant de toucher à la configuration DNS ou d'éteindre quoi que ce soit. Commencez par dresser la liste exacte des services qui tournent sur votre instance Oracle : nom du service, port d'écoute, volume Docker associé, domaine ou sous-domaine utilisé. Prenez un snapshot complet de l'instance via la console Oracle Cloud — c'est votre filet de sécurité en cas de problème inattendu. Exportez également tous vos volumes Docker vers des archives tar, que vous pouvez transférer indépendamment. Réduisez les TTL DNS de vos enregistrements A à 300 secondes au moins 24 heures avant la migration : cela limite la durée de propagation lors de la bascule finale. Identifiez les cron jobs, webhooks entrants et services tiers qui utilisent l'IP Oracle actuelle — certains outils comme Stripe, GitHub ou Slack envoient des événements vers une URL fixe que vous devrez mettre à jour. Enfin, vérifiez que vos certificats TLS sont gérés via Let's Encrypt avec renouvellement automatique, car ils devront être régénérés sur la nouvelle IP.

Une fois les services opérationnels sur le VPS, la bascule DNS est l'étape la plus visible. Modifiez les enregistrements A (et AAAA si vous avez de l'IPv6) pour chaque sous-domaine dans votre zone DNS, en pointant vers la nouvelle IP du VPS. Grâce au TTL réduit à 300 secondes préparé en amont, la propagation est généralement effective en moins de dix minutes chez la majorité des résolveurs. Surveillez les logs Traefik ou Caddy pendant les premières heures pour détecter d'éventuelles requêtes qui arrivent encore sur l'ancienne IP Oracle. Les certificats Let's Encrypt doivent être re-générés sur la nouvelle IP : Coolify le fait automatiquement au premier démarrage avec le bon domaine ; pour les services gérés manuellement avec Caddy ou Certbot, vérifiez que le défi HTTP-01 répond bien depuis le VPS avant de supprimer l'ancienne instance. Les cron jobs internes à n8n ou Nextcloud survivent à la migration (ils sont dans la base de données ou la configuration), mais les cron système de l'instance Oracle (dans /etc/cron.d ou la crontab root) doivent être recréés manuellement sur le VPS. Enfin, notifiez les services tiers qui utilisaient votre ancienne IP Oracle dans leurs listes d'IPs autorisées (webhooks Stripe, listes blanches de pare-feu clients).

Lors d'une migration Docker, quelques erreurs reviennent systématiquement. La première est un problème de permissions sur les volumes restaurés : si votre conteneur démarre avec un UID différent de celui qui a créé les fichiers sur Oracle, vous obtenez des erreurs permission denied dans les logs. Corrigez avec docker run --rm -v volume:/data alpine chown -R uid:gid /data en remplaçant uid:gid par celui attendu par l'image (lisible dans le Dockerfile officiel ou la documentation). La deuxième erreur fréquente est un conteneur qui démarre puis s'arrête immédiatement avec le code 137 : c'est un kill OOM (Out Of Memory). Vérifiez dmesg | grep -i oom et augmentez la RAM allouée au service ou réduisez le nombre de workers. La troisième erreur concerne Let's Encrypt : si le certificat ne se génère pas, vérifiez que le port 80 est bien ouvert (ufw allow 80) et que le DNS pointe déjà vers la nouvelle IP avec dig +short votre-domaine.com. Un enregistrement A qui pointe encore vers Oracle empêche la validation HTTP-01. Enfin, si Coolify affiche les services comme « offline » malgré des conteneurs Docker qui tournent, vérifiez que le réseau Docker coolify est bien attaché à chaque conteneur avec docker network inspect coolify.