FR
live

Oracle Halves Always Free ARM Limits and Gives You Until August 18, 2026 to Act

Oracle is cutting the Always Free ARM quota from 4 OCPU / 24 GB to 2 OCPU / 12 GB starting August 18, 2026. If you self-host services on Oracle Cloud's free tier, you have nine days to resize or consolidate your instances before they are automatically terminated.

A large glass hourglass on a dark desk with sand nearly drained into the bottom bulb, one last amber grain suspended mid-fall catching a beam of technical LED light.

Early August 2026 — Oracle sent a terse email to users of its Always Free tier: ARM (Ampere A1) compute limits drop from 4 OCPU / 24 GB RAM to 2 OCPU / 12 GB. Enforcement begins August 18, 2026, and instances exceeding the new quota will be automatically terminated, with no recourse. The two x86 micro instances (1 OCPU / 1 GB) are unaffected.

For the self-hosting community — which widely adopted Oracle’s free tier to run Docker, WireGuard, Nextcloud, Vaultwarden, or K3s nodes — this announcement is not a technical surprise but a blunt reminder: free is never free for long.

What changed, in one sentence

The ARM Always Free pool — enforced at the tenancy level, not per instance — is cut in half. You now get a total of 2 OCPUs and 12 GB of RAM to split however you like (one 2/12 instance or two 1/6 instances), but the sum cannot exceed the new limit.

ResourceOld limitNew limit (enforced Aug 18, 2026)
ARM OCPUUp to 4Up to 2
ARM memoryUp to 24 GBUp to 12 GB
x86 micro instances2 × 1 OCPU / 1 GBUnchanged

The ARM quota is separate from the x86 quota — your two Intel/AMD micro instances do not count toward the 2 OCPU / 12 GB and continue running unchanged.

The three scenarios, and exactly what to do

Scenario A — One 4 OCPU / 24 GB instance

This is the straightforward case. You need to resize the instance to 2 OCPU / 12 GB before August 18. In the OCI Console: Compute → Instances, select your instance, More Actions → Edit, set OCPU to 2 and memory to 12 GB, then save.

bash
# Before resizing, create a safety snapshot
# From the OCI console or via CLI:
oci compute boot-volume-backup create \
  --boot-volume-id ocid1.bootvolume.oc1.xxxx \
  --display-name "backup-before-resize-$(date +%Y%m%d)"

Do it this week, not on August 17. The OCI console slows down near deadlines, and a failed resize the day before leaves you with no fallback.

Scenario B — Two 2 OCPU / 12 GB instances

Two 2/12 instances add up to 4 OCPUs and 24 GB — exactly double the new quota. You cannot keep both. Pick one, back it up (snapshot or image), copy critical data to the survivor or to object storage, then terminate it.

Once the instance is gone, your tenancy drops to 2 OCPU / 12 GB and Oracle leaves it alone. The remaining instance continues at 2/12 without modification.

bash
# Copy critical data to the surviving instance
rsync -avz --progress /opt/my-services/ user@survivor:/opt/my-services/
# Verify everything copied
ssh user@survivor "du -sh /opt/my-services/"
# Then from the OCI console: Compute → Instances → [instance to remove] → More Actions → Terminate

Scenario C — Two x86 micro instances

Do nothing. The Intel/AMD instances (VM.Standard.E2.1.Micro) have their own quota, separate from the ARM pool. They are not mentioned in the new limits and keep running. Do not touch them.

What will not save you

  • Ignoring the email. Enforcement is automatic on August 18, 2026. Oracle will not send a reminder.
  • Stopping the instance instead of terminating it. A stopped instance continues to consume its OCPU/memory allocation in most tenancies. Only termination frees the quota.
  • Waiting until August 17. The OCI console can slow down, snapshots can fail, and free support does not respond within hours.
  • Forgetting the backup. A terminated instance and its boot volume are gone forever. There is no trash bin, no undo.

Check your actual usage in the OCI → Limits, Quotas and Usage console — that is the source of truth, not your mental estimate.

Why Oracle is doing this now

Oracle provides no official reason. The likely cause is ARM capacity pressure, amplified by AI infrastructure demand that is siphoning memory and storage resources. The Always Free tier with 4 OCPU / 24 GB was, by general consensus, too generous — a marketing argument that outran its operational budget.

The lesson is not new but bears repeating: free is the most expensive. The cost is not in dollars but in unpredictability. Infrastructure you do not pay for is infrastructure over which you have no leverage.

Verdict: what to do after August 18

The good news is that 2 OCPU / 12 GB remain free and permanent. An ARM instance of that size comfortably runs a modest Docker stack — Traefik, Vaultwarden, Nginx, a WireGuard endpoint, and a few lightweight containers — with headroom to spare.

If your stack fits within 2 OCPU / 12 GB: resize and stay. Oracle’s free tier, even halved, remains the best no-cost ARM offering on the market.

If your stack exceeds these limits: you have nine days to migrate. The alternatives are well-known: a Hetzner ARM VPS (CAX11 at ~€4/month, 2 vCPU / 4 GB), a Raspberry Pi 5 at home (8 GB, ~$80 one-time), or a used x86 mini-PC. The budget constraint is real, but it beats waking up on August 19 to an instance that no longer exists.

Oracle warned you. The clock is ticking.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

← Back to the feed

Type at least two characters.

navigate open esc dismiss