The free ARM instance of Oracle had been the people’s server for six years for everything: proxy node, Pi-hole, panel, Vaultwarden, home VPN, small Docker stack. The generosity was incredibly large — 4 OCPU and 24 GB of memory for free. Now it’s exactly cut in half, and some users have a deadline.
We’re figuring out what’s factual and what’s a retelling of letters on the internet, because Oracle did not make a public announcement at all.
What is confirmed by the documentation
The current Always Free Resources page in the OCI documentation formulates the limit as: 1,500 OCPU-hours and 9,000 GB-hours per month for the shape VM.Standard.A1.Flex, which “for Always Free tenants is equivalent to 2 OCPU and 12 GB of memory.” Previously, the same page showed 3,000 OCPU-hours and 18,000 GB-hours — i.e., 4 OCPU and 24 GB.
The change was noticed in mid-June: reported by InfoQ, Linuxiac, and heise. There was no official announcement, blog post, or email saying “we’re changing the terms” — the correction was found in the documentation.
Other Always Free offerings in the documentation did not change: two micro-instances VM.Standard.E2.1.Micro, 200 GB of block storage in total, 10 GB of object storage.
Separate old trap that hasn’t gone away and now becomes more dangerous: Oracle reserves the right to take away an idle Always Free instance if, for 7 days, the 95th percentile of CPU, network and memory usage is below 20%. If your ARM server is idle and you recreate it after shutoff — you won’t be able to return to the previous 4 OCPU.
What is known only from user reports
Date August 18, 2026 and automatic disabling of extra instances — from letters received by users. This is simultaneously noted in discussions on Hacker News (August 5, ~200 votes), in a thread on V2EX, and in the selfh.st newsletter. The wording from summaries: instances that exceed the Always Free limit will be automatically terminated; you need to bring consumption back to normal by that date.
Official confirmation of this date from Oracle could not be found — neither in a blog nor in the documentation. Treat this as a community message, not a vendor fact. At the same time, three independent sources report the same letter, and the limits in the documentation have already been changed — so it’s prudent to plan for the worst case.
A second murky point: according to summaries of conversations with support, Pay-As-You-Go accounts allegedly may keep the old limits, but there is no written confirmation, and different support agents respond differently. For PAYG accounts, the risk is not being turned off but a sudden charge for going over.
What to do before August 18
Check how much you are consuming now. In the console: Compute → Instances, look at the shape of each A1 machine. Via CLI:
oci compute instance list --compartment-id <OCID> \\
--query "data[?\"shape\"=='VM.Standard.A1.Flex'].{name:\"display-name\",ocpus:\"shape-config\".ocpus,mem:\"shape-config\".\"memory-in-gbs\",state:\"lifecycle-state\"}" \\
--output table
Add up the OCPUs and memory for all A1 instances. If the total exceeds 2 and 12, you’re at risk.
Actions ordered by increasing pain:
- Reduce the shape. A1.Flex changes OCPU and memory on a stopped instance: stop → Edit → Edit shape → set 2 OCPU / 12 GB → start. Data and boot disk remain in place. This is the safest path: you choose what to trim, not Oracle deciding what to remove.
- Consolidate two instances into one. If you have two machines of 2 OCPU / 12 GB — together this already exceeds the new limit. Move services to Docker Compose on one and delete the second yourself.
- Back up before the deadline. Don’t rely on data surviving “automatic shutdown”: take a snapshot of the boot volume (Boot Volume → Create Backup) or, more safely, export configurations and data volumes to your side:
rsync -avz oracle:/opt/stack/ ./oracle-stack/. - Migrate. 2 OCPU / 12 GB on ARM is still more than what anyone offers for free, and for a proxy node, Pi-hole, or Vaultwarden this is more than enough. Heavy workloads (media server with transcoding, builds, local LLMs) should be moved to a paid VPS immediately — that’s how it used to run before too.
A useful perspective for the future: “always free” in cloud marketing means “you don’t pay for this,” not “terms will never change.” Do not keep infrastructure on a free tier if losing it would really upset you — not due to Oracle’s greed, but because unilateral term changes are a normal event that they aren’t obliged to warn about in a letter.
Sources
- OCI Documentation, Always Free Resources: Always Free Resources
- InfoQ, “Oracle Quietly Halves Free Tier Ampere A1 Compute Limits with No Public Announcement”: Oracle Quietly Halves Free Tier Ampere A1 Compute Limits with No Public Announcement - InfoQ
- Linuxiac (June 14, 2026): Oracle Quietly Cuts Free Tier Ampere A1 Resources in Half
- Hacker News discussion (August 5, 2026): Oracle cut its Always Free ARM limits to 2 OCPU / 12GB, enforced Aug 18 | Hacker News
Has anyone received a letter from Oracle — and what does it say verbatim about the date and termination? And, since there’s a reason: what is running on your free A1 and will it survive the reduction by half?
