Oracle Free Tier ARM Cutoff: What to Do Before Aug 18

A huge slice of the self-hosting world runs on infrastructure that costs nothing: Oracle's Always Free tier, specifically its unusually generous Ampere A1 ARM allocation, has quietly become the backbone for a lot of people's Plex servers, Minecraft boxes, Pi-hole instances, and small VPN nodes. That allocation just got cut in half, and unlike most cloud pricing changes, Oracle didn't send an email, publish a blog post, or make any public statement about it at all.

What actually changed, in numbers

The Always Free Ampere A1 compute allowance dropped from 4 OCPUs and 24GB of RAM down to 2 OCPUs and 12GB. In the underlying billing terms Oracle's documentation now uses, that's a drop from 3,000 OCPU-hours and 18,000 GB-hours per month to 1,500 OCPU-hours and 9,000 GB-hours per month.

A few details that matter more than the headline number:

• It's a tenancy-wide pool, not per-instance. You can run one 2 OCPU / 12GB box, or split the allowance into two 1 OCPU / 6GB boxes — but the sum can't exceed the new total.
• Your other free resources are untouched. The two free AMD-based x86 micro instances and the 200GB of block storage that come with Always Free are unaffected — this change is specifically about the ARM compute pool.
• The change itself predates the enforcement date by two months. Multiple independent trackers place the actual documentation update around June 15, 2026, weeks before anyone noticed or Oracle said anything.

The enforcement timeline

Oracle has now sent account-level emails to Always Free users (not a public announcement, but a direct notice) warning that starting August 18, 2026, any Always Free compute instance still exceeding the new limit will be automatically terminated — not just stopped, terminated. If you're running a single 4 OCPU/24GB instance or two 2/12 instances today, you're already over the new allowance and need to act before that date.

The part Oracle hasn't clarified

Here's where independent reporting starts to diverge, and it's worth being upfront that this is genuinely murky rather than pretending there's a clean answer. Oracle's own documentation states the new limits apply to "all tenancies," but the direct emails going out to users reportedly say the change only affects free-tier accounts — and Oracle support agents have apparently given conflicting answers when asked directly whether Pay-As-You-Go (PAYG) accounts, which give Oracle a credit card but still carry the same nominal free allotment, are affected. As of now, PAYG users report still seeing the full 4 OCPU/24GB allowance priced at $0 in their cost estimator — but several independent trackers following the story expect that to be a lag in Oracle's billing tooling rather than a permanent exemption, not a confirmed policy.

If you want to keep running the full old 4 OCPU/24GB configuration and are willing to pay for the difference above the new 2/12 free allowance, that overage works out to roughly $25–28/month at Oracle's standard Ampere A1 rates — though you should check Oracle's own OCI cost estimator for your specific region rather than treating that as exact.

What to actually do before August 18

• Single 4 OCPU/24GB instance: resize the shape down to 2 OCPU/12GB. This is a config change plus a reboot, not a migration — your data and the instance itself aren't destroyed by resizing.
• Two 2 OCPU/12GB instances (or similar combos exceeding the pool): consolidate onto one instance at the new limit, or terminate one of them, before enforcement kicks in.
• Only running the two free x86 micro instances: you're not affected by this change at all.
• On PAYG and want to keep 4/24: budget for roughly $25–28/month in overage billing, and set a cost alert given the ambiguity in Oracle's own messaging about whether this will actually be charged consistently.
  The safer move across the board is resizing down proactively rather than waiting for Oracle's termination process to do it for you — a controlled resize is a two-minute config change; a forced termination is not something you get to schedule.

While you're in there resizing anyway, it's a reasonable moment to audit what's actually running on the box. If a password manager isn't part of your stack yet and you're looking for something worth the remaining 12GB, our complete guide to self-hosting Vaultwarden covers the full setup — it's a genuinely light service, easy to justify even on the smaller allocation.

Five years of actually running on this tier

A bit of personal history, since I've got a genuine stake in how good this free tier has actually been: I've been running SudoSecurity itself on Oracle's Always Free ARM tier since 2021, when I first found out it existed. Five years on the same free instance is a real answer to "is ARM actually viable for hosting a production web server," and the answer's been an unambiguous yes. If you're only now hearing that this is even an option, our full walkthrough on setting up Oracle's free tier from scratch covers the actual setup end to end — this piece is about what changed, that one's about how to get running on it in the first place.

The early days weren't entirely friction-free, to be fair to how this actually went. ARM compatibility across the self-hosted ecosystem was noticeably spottier in 2021 than it is now — a fair number of prebuilt Docker images simply didn't ship an arm64 tag yet, which meant either building from source or waiting for upstream to catch up. That's almost entirely a non-issue today; multi-arch images are close to the default assumption across the self-hosted software world at this point, which is its own quiet signal of how mainstream ARM hosting has become since Oracle helped normalize it by giving so many people free hardware to build on top of.

I'm not the only one who's put it through its paces. A few friends signed up after seeing how well it worked for me, and the results have mostly held up — starting with the one that actually taught me something new about why ARM performance on Oracle's free tier behaves the way it does.

The Minecraft server: why chunk generation is where ARM actually shows its seams

A friend running a Minecraft server for around 20 players on the free ARM tier saw genuinely stable TPS during normal play — right up until someone flew off in a new direction and the server had to generate a wave of fresh terrain all at once. That's not a coincidence, and it's not really an Oracle-specific problem either; it's about what chunk generation actually demands from a CPU.

Chunk generation is the single most CPU-intensive operation a Minecraft server performs, and critically, it runs on the main thread and is heavily dependent on single-core clock speed rather than core count — even a fast CPU takes somewhere in the neighborhood of 20-80ms to generate one chunk, and that cost is paid serially. This is exactly why dedicated Minecraft hosting providers specifically advertise high-clock-speed chips like the Ryzen 9 7950X3D for pre-generation work, rather than just piling on more cores.

Here's where Oracle's specific hardware choice matters: the free-tier Ampere A1 shape runs on the Ampere Altra Q80-30, which holds a genuinely consistent 3.0GHz across every core — no thermal throttling, no boost-clock lottery, which is exactly why it's such a good value for steady multi-tenant workloads like a web server or a handful of light containers. But 3.0GHz sustained is meaningfully behind the 5+GHz boost clocks of the desktop-class chips that specialized Minecraft hosts deliberately pick for exactly this reason. That mismatch is the actual mechanism behind what my friend saw: rock-solid TPS during ordinary play, because that workload spreads reasonably well and Ampere's consistency shines there — and a real, noticeable dip specifically during chunk-generation bursts, because that workload doesn't care how many cores you have, only how fast one of them runs.

The fix isn't "get better hardware," it's the same one server admins reach for regardless of what chip they're running: pre-generating the world ahead of time with a plugin like Chunky, so the CPU-expensive terrain generation happens once during a quiet off-peak window instead of live, on-demand, in front of impatient players. We've actually covered this exact problem in more depth before — our guide on debugging Minecraft server lag with the Spark profiler walks through identifying exactly this kind of main-thread bottleneck, and our complete guide to running a Minecraft server without the lag covers pre-generation and the rest of the standard toolkit end to end. Worth a read regardless of what you're hosting on — the underlying physics of chunk generation doesn't change based on your cloud provider.

Another friend runs a VPN, a simple landing page, and a handful of internal homelab projects, all on one instance — no complaints of any kind, which is honestly the most boring and most convincing kind of endorsement a piece of infrastructure can get. If a password manager is part of your own homelab stack the way it is for a lot of self-hosters, it's worth knowing we recently covered the Bitwarden client update that broke Vaultwarden compatibility — worth a read if your vault has been acting strange lately, on Oracle's free tier or anywhere else.

Not everything held up to expectations, though, and it's worth being honest about where friends actually hit limits — because it wasn't where they expected to. A few assumed they could throw everything onto a single 4 OCPU / 24GB / 200GB NVMe instance and never think about it again. The CPU and RAM held up fine. Storage was the actual bottleneck — 200GB doesn't stretch nearly as far in 2026 as it did when the tier launched, and the same friends who ran into it were also too stubborn to pay for more, despite Oracle's block storage pricing being genuinely reasonable for the overage. That's a self-inflicted problem, not really Oracle's fault, but it's the one that actually bit people, not the CPU allocation this whole article is about.

The other skepticism I heard early on was that Oracle would never actually let 24GB of free RAM last — that it was a launch promotion bound to get clawed back within a year or two. Five years of it holding steady is a genuinely good run for a "free forever" cloud offering, and it makes the current ARM cutback feel less like a betrayal and more like a company finally reining in something that was arguably too generous for this long.

None of this is a complaint piece dressed up as one, to be clear. I got five years of a real production site, a friend got a stable 20-player Minecraft server, another got a VPN and a homelab with zero issues — all on hardware that cost nothing. Whatever changes on August 18, that's still a genuinely good run, and OCI has been a smooth, reliable host the entire time.

Everything Else

This piece is specifically about the Ampere A1 (ARM) compute allocation. It doesn't touch Oracle's Autonomous Database free tier, the 10TB/month outbound data allowance, or the two free x86 micro instances — none of those have been reported as changed. It's also worth being clear that Oracle has made no public statement confirming why this happened; every explanation floating around (capacity constraints, abuse prevention, cost management) is informed speculation from the community, not something Oracle has confirmed.