Oracle divise par deux les limites ARM Always Free et donne jusqu’au 18 août 2026 pour agir

Oracle réduit le quota ARM Always Free de 4 OCPU / 24 Go à 2 OCPU / 12 Go à partir du 18 août 2026. Si vous auto-hébergez des services sur l’offre gratuite d’Oracle Cloud, vous avez neuf jours pour redimensionner ou consolider vos instances avant leur terminaison automatique.

Début août 2026 — Oracle a envoyé un email laconique aux utilisateurs de son offre Always Free : les limites de calcul ARM (Ampere A1) passent de 4 OCPU / 24 Go de RAM à 2 OCPU / 12 Go. La date d’application est le 18 août 2026, et les instances qui dépasseront le nouveau quota seront automatiquement terminées, sans recours. Les deux instances x86 micro (1 OCPU / 1 Go) ne sont pas concernées.

Pour la communauté self-hosting — qui a massivement adopté le tier gratuit d’Oracle pour héberger Docker, WireGuard, Nextcloud, Vaultwarden ou des nœuds K3s — cette annonce n’est pas une surprise technique mais un rappel brutal : le gratuit n’est jamais gratuit longtemps.

Ce qui change, en une phrase

Le pool ARM Always Free — qui s’applique au niveau du tenancy, pas par instance — est divisé par deux. Vous disposez désormais de 2 OCPU et 12 Go de RAM au total à répartir comme vous le souhaitez (une instance 2/12 ou deux instances 1/6), mais la somme ne peut pas dépasser la nouvelle limite.

Ressource	Ancienne limite	Nouvelle limite (18 août 2026)
ARM OCPU	Jusqu’à 4	Jusqu’à 2
ARM mémoire	Jusqu’à 24 Go	Jusqu’à 12 Go
Instances x86 micro	2 × 1 OCPU / 1 Go	Inchangé

Le quota ARM est séparé du quota x86 — vos deux micro-instances Intel/AMD ne comptent pas dans les 2 OCPU / 12 Go et continuent de fonctionner sans changement.

Les trois scénarios, et l’action exacte à prendre

Scénario A — Une seule instance 4 OCPU / 24 Go

C’est le cas le plus simple. Vous devez redimensionner l’instance à 2 OCPU / 12 Go avant le 18 août. Dans la console OCI : Compute → Instances, sélectionnez votre instance, More Actions → Edit, réglez OCPU sur 2 et mémoire sur 12 Go, puis sauvegardez.

bash

# Avant le redimensionnement, créez un snapshot de secours
# Depuis la console OCI ou via CLI :
oci compute boot-volume-backup create \
  --boot-volume-id ocid1.bootvolume.oc1.xxxx \
  --display-name "backup-avant-resize-$(date +%Y%m%d)"

Faites-le cette semaine, pas le 17 août. La console OCI ralentit près des deadlines, et un échec de redimensionnement la veille vous laisse sans recours.

Scénario B — Deux instances 2 OCPU / 12 Go

Deux instances 2/12 totalisent 4 OCPU et 24 Go — exactement le double du nouveau quota. Vous ne pouvez pas conserver les deux. Choisissez-en une, sauvegardez-la (snapshot ou image), copiez les données importantes vers l’instance survivante ou vers le stockage objet, puis terminez-la.

Une fois l’instance terminée, votre tenancy retombe à 2 OCPU / 12 Go et Oracle n’y touche plus. L’instance restante continue à 2/12 sans modification.

bash

# Copier les données critiques vers l'instance survivante
rsync -avz --progress /opt/mes-services/ user@survivant:/opt/mes-services/
# Vérifier que tout est copié
ssh user@survivant "du -sh /opt/mes-services/"
# Puis depuis la console OCI : Compute → Instances → [instance à supprimer] → More Actions → Terminate

Scénario C — Deux instances x86 micro

Rien à faire. Les instances Intel/AMD (VM.Standard.E2.1.Micro) ont leur propre quota, distinct du pool ARM. Elles ne sont pas mentionnées dans les nouvelles limites et continuent de tourner. Ne les touchez pas.

Ce qui ne vous sauvera pas

Ignorer l’email. L’application est automatique le 18 août 2026. Oracle n’enverra pas de rappel.
Stopper l’instance au lieu de la terminer. Une instance arrêtée continue de consommer son allocation OCPU/mémoire dans la plupart des tenancies. Seule la terminaison libère le quota.
Attendre le 17 août. La console OCI peut ralentir, les snapshots peuvent échouer, et le support gratuit ne répond pas en quelques heures.
Oublier le backup. Une instance terminée et son volume de boot sont irrécupérables. Il n’y a pas de corbeille, pas d’undo.

Vérifiez votre usage réel dans la console OCI → Limits, Quotas and Usage — c’est la source de vérité, pas votre estimation mentale.

Pourquoi Oracle fait ça maintenant

Oracle ne donne pas de raison officielle. La cause probable est la pression sur les capacités ARM, amplifiée par la demande en infrastructure IA qui siphonne les ressources mémoire et stockage. L’offre Always Free avec 4 OCPU / 24 Go était, de l’avis général, trop généreuse — un argument marketing qui a dépassé son budget opérationnel.

La leçon n’est pas nouvelle mais elle mérite d’être répétée : le gratuit est le plus cher. Le coût n’est pas en euros mais en imprévisibilité. Une infrastructure que vous ne payez pas est une infrastructure sur laquelle vous n’avez aucun levier.

Verdict : que faire après le 18 août

La bonne nouvelle est que 2 OCPU / 12 Go restent gratuits et permanents. Une instance ARM de cette taille fait tourner confortablement une stack Docker modeste — Traefik, Vaultwarden, Nginx, un WireGuard, et quelques conteneurs légers — avec de la marge.

Si votre stack tient dans 2 OCPU / 12 Go : redimensionnez et restez. Le tier gratuit d’Oracle, même réduit de moitié, reste la meilleure offre ARM sans frais du marché.

Si votre stack dépasse ces limites : vous avez neuf jours pour migrer. Les alternatives sont connues : un VPS ARM chez Hetzner (CAX11 à ~4 €/mois, 2 vCPU / 4 Go), un Raspberry Pi 5 à domicile (8 Go, ~80 € une fois), ou un mini-PC x86 d’occasion. La contrainte budgétaire est réelle, mais elle est préférable à un réveil le 19 août devant une instance qui n’existe plus.

Oracle vous a prévenu. Le compte à rebours tourne.

Références

Oracle Just Halved Its Always Free ARM Limits — CNELECAR, août 2026
Self-Host Weekly (7 August 2026) — selfh.st, 7 août 2026
Oracle Always Free Cloud Services, consulté le 9 août 2026