The short answer: shrink or consolidate before August 18, 2026
If you’re running any Ampere A1 ARM instance larger than 2 OCPUs or 12 GB of RAM — or more than one of them — you need to act before August 18, 2026, or Oracle will terminate the excess automatically. Your two free x86 instances are untouched.
You probably got the email this week. Oracle is quietly cutting its “Always Free” ARM allowance in half, and the deadline is real.
“Beginning on August 18, 2026, Oracle will begin enforcing the updated Always Free compute limits. Compute instances that exceed the Always Free entitlement will be automatically terminated.”
“Current Always Free compute limits: Up to 2 Ampere A1 OCPUs. Up to 12 GB of memory.”
Here’s what changed, what it means for your tenancy, and the exact move to make depending on what you’re running today.
What actually changed
The ARM side of Always Free used to be generous: 4 OCPUs and 24 GB of RAM, usable as one large instance or split into two. As of August 18, 2026, it’s exactly half.
| Resource | Old limit | New limit (enforced Aug 18, 2026) |
|---|---|---|
| ARM (Ampere A1) OCPU | Up to 4 OCPUs | Up to 2 OCPUs |
| ARM memory | Up to 24 GB | Up to 12 GB |
| x86 micro instances | 2 × 1 OCPU / 1 GB | 2 × 1 OCPU / 1 GB (unchanged) |
| Other Always Free services | Available | Remain available |
One thing that trips people up: the ARM limit is a tenancy-wide pool, not per instance. You get 2 OCPUs and 12 GB total to divide however you like — one 2/12 instance, or two 1/6 instances — but the sum can’t go over. And it’s separate from the two always-free x86 instances, which keep their own allowance.
Why this is happening
Oracle doesn’t say in the email, and we won’t pretend to know. The likely story is capacity and abuse management on a tier that was famously too good to last. What matters more than the motive is the math: if you’re over the new pool, something has to give by the deadline.
Your move, by what you’re running today
Scenario A — You have one 4 OCPU / 24 GB ARM instance
This is the easy one. Resize it down to 2 OCPUs / 12 GB. In the OCI Console, open Compute → Instances, select your instance, click More Actions → Edit, set OCPU to 2 and memory to 12 GB (on Ampere A1 the shape scales OCPU and memory together, and 12 GB is the max at 2 OCPU), then save. The instance resizes — back up first, because any shape change is a good moment to have a snapshot.
Do this now, not on August 17. The console gets busy near deadlines, and you don’t want a resize to fail the day before termination.
Scenario B — You have two 2 OCPU / 12 GB ARM instances (like I do)
Two 2/12 instances add up to 4 OCPUs and 24 GB — exactly double the new pool. You can’t keep both. Pick one, back up its data, and terminate it. Keep the other at 2/12, and you’re sitting right at the limit.
I’m in this boat myself: I opened two 2/12 ARM instances a while back and never consolidated them. The fix is to snapshot or image the one I’m retiring, copy anything I care about to the survivor (or to object storage), then terminate. Once it’s gone, the tenancy drops to 2/12 and Oracle leaves it alone.
Scenario C — You have two 1 OCPU / 1 GB x86 instances
Nothing to do. These are the Intel/AMD micro instances, and they’re a separate allowance from the ARM pool. They’re not mentioned in the new limits and they keep running. Leave them be.
What won’t save you (common mistakes)
- Ignoring the email and hoping it’s a mistake. It isn’t. Enforcement is dated August 18, 2026.
- Waiting until the last day. Resize or terminate this week. Console slowdowns and quota quirks near the deadline are the kind of thing that turns a 10-minute job into a missed deadline.
- Forgetting to back up before you terminate. A terminated instance and its boot volume are gone — there’s no undo.
- Assuming stopping an instance frees the allocation. It often doesn’t. To drop under the limit, you generally need to terminate, not just stop. Check your tenancy’s Limits, Quotas and Usage to see what’s actually counting.
- Counting your x86 instances against the ARM pool. They’re separate. Don’t consolidate the wrong things.
One honest caveat: the exact mechanics of what counts toward the pool can vary by tenancy and by how Oracle measures allocation. The email is the source of truth, and your OCI Console is the place to confirm your own usage before you act.
The bottom line
The free ARM tier is now half of what it was. If you’re over the new 2 OCPU / 12 GB pool, you have until August 18, 2026 to fix it.
- Running one big 4/24 instance? Resize it to 2/12.
- Running two 2/12 instances? Back up one, terminate it, keep the other.
- Running two x86 micro instances? Do nothing — they’re fine.
And if Oracle does terminate an instance for being over the limit, you can relaunch within the new limits anytime. So the worst case isn’t data loss (if you backed up) — it’s a few minutes of rebuild. Do it this week, and you’ll never think about it again.
If you are already running critical business on the free Oracle server and this change has caused you pain, then you can view it as a real lesson: Free is the most expensive.
If you have serious business to handle, it is recommended that you rent a server for a fee, for example: Hostgator.