There's been a notable change in the Oracle Cloud free tier recently. The A1 Ampere always-free compute allocation has been cut from 4 OCPU + 24GB RAM down to 2 OCPU + 12GB RAM, with enforcement beginning August 18. The A1 free tier itself hasn't been eliminated โ ARM cloud servers are still available at no cost โ but the quota reduction is meaningful and affects how you should be using it.
What the New Rules Actually Say
According to Oracle's official documentation (docs.oracle.com, last verified August 2026), the Ampere A1 Compute (VM.Standard.A1.Flex) Always Free allocation is now 1,500 OCPU hours + 9,000 GB hours per month โ which works out to 2 OCPU + 12GB RAM running continuously across the entire tenancy.
| Resource | Before | Now (Official Docs) |
|---|---|---|
| Ampere A1 OCPU | 4 | 2 |
| A1 Memory | 24GB | 12GB |
| A1 OCPU hours/month | 3,000 | 1,500 |
| A1 GB hours/month | 18,000 | 9,000 |
| E2.1.Micro (AMD) instances | Up to 2 | Unchanged, still up to 2 |
The two E2.1.Micro x86 instances are unaffected โ each still provides 1/8 OCPU and 1GB RAM, and that allocation is separate from the A1 quota.
This Is a Tenancy Total, Not a Per-Instance Limit
This is the most commonly misunderstood point. The 2 OCPU / 12GB is the total A1 budget for your entire Oracle Cloud account โ not what each individual instance can have.
Valid combinations under the new quota: one instance with 2 OCPU / 12GB; two instances each with 1 OCPU / 6GB; one instance at 1 OCPU / 4GB plus another at 1 OCPU / 8GB, as long as the combined total stays within 2 OCPU / 12GB.
What's now over quota: a single instance at 4 OCPU / 24GB (the old configuration); two instances each at 2 OCPU / 12GB, totaling 4 OCPU / 24GB.
If you provisioned under the old rules โ a single 4 OCPU / 24GB instance, or multiple instances that sum to more than 2 OCPU / 12GB โ those configurations are now non-compliant and need to be addressed.
The Most Unusual Part: No Public Announcement
According to reporting from InfoQ and several technical blogs in June and July 2026, Oracle made this quota change without publishing any official public announcement. Users discovered it by noticing the numbers had changed in the documentation. Multiple outlets described the adjustment as having been made "quietly."
The documentation change appeared around mid-June 2026 (some community posts reference June 15), but enforcement was inconsistent at first โ users reported that instances over the new limit continued running normally, the console still showed $0 in cost estimates, and the UI prompts during instance creation weren't updated to reflect the new limits. The hard cutoff came on August 18, 2026, when Oracle began terminating or disabling instances that exceeded the new quota.
What Happened on and After August 18
In the days following enforcement, Oracle's Cloud Customer Connect community forums filled with reports of A1 instances being administratively disabled. The situations break into two categories:
Users who were actually over quota. Those running a 4 OCPU / 24GB single instance or multiple instances summing above the new limit had their instances disabled as expected under the new rules.
Users whose instances were within the new quota but still got disabled. This is the more concerning pattern. Community posts report instances configured at exactly 2 OCPU / 12GB โ fully compliant with the new Always Free limit โ being administratively disabled during the August 18 enforcement sweep anyway. Affected users had to contact Oracle support to request reactivation.
To be clear: these are user-reported incidents on community forums, not confirmed evidence of systematic Oracle errors at scale. But they do indicate that being within the new quota did not guarantee smooth sailing on enforcement day. If you have A1 instances, even ones you believe are compliant, it's worth verifying their actual running status in the console right now.
PAYG Accounts: Even Oracle's Own Responses Contradict Each Other
This is another area of confusion. Based on user reports, some Oracle human support agents (not AI chat) confirmed in June 2026 email responses that the new quota applies only to free-tier accounts, and that Pay As You Go accounts can continue using up to 4 OCPU / 24GB under the Always Free terms. Other, more detailed support responses said the opposite.
Oracle's official documentation does not currently distinguish between free and PAYG accounts for A1 quota purposes. If you're on a PAYG account running more than 2 OCPU / 12GB of A1 compute, contact Oracle support directly to confirm your specific situation โ don't rely on secondhand community reports that contradict each other.
How to Check Your Account Right Now
In the Oracle Cloud console: navigate to Compute โ Instances, filter for all VM.Standard.A1.Flex instance types, record the OCPU count and memory for each, then add them up.
| Instance | OCPU | Memory |
|---|---|---|
| A1-1 | 1 | 6GB |
| A1-2 | 1 | 6GB |
| Total | 2 | 12GB |
If the total stays at or under 2 OCPU / 12GB, you're compliant. If it exceeds that, or if any instances show as Stopped or Disabled, act immediately.
How to Handle Being Over Quota
Option 1: Resize in place. Reduce a 4 OCPU / 24GB instance to 2 OCPU / 12GB directly. The most straightforward path.
Option 2: Split into smaller instances. Reconfigure as two instances at 1 OCPU / 6GB each for more flexibility.
Option 3: Delete excess instances. If you provisioned multiple A1 instances as placeholders, keep the one you actually use and remove the rest.
Option 4: Upgrade to PAYG. If 2 OCPU / 12GB genuinely isn't enough for your workload, the free tier no longer fits your needs. Upgrading to Pay As You Go means resources beyond the free allocation are billed normally, while the free portion remains at no cost.
One important caveat from community reports: instances that have already been disabled may not be resizable through the console. You may need to contact Oracle support to have the instance reactivated before you can make configuration changes. Back up any important data before touching anything โ don't wait until an instance is already disabled to start thinking about this.
What 2 OCPU / 12GB Can Still Handle
The reduced allocation still covers a meaningful range of lightweight use cases: WordPress, Docker containers, n8n automation, Nginx reverse proxy, small databases, home lab environments, lightweight APIs, and several concurrent low-overhead services running in parallel.
Scenarios that warrant more careful evaluation: large databases, multiple high-load services running simultaneously, and local LLM inference. Whether 12GB is sufficient for AI workloads depends entirely on the specific model size and quantization method โ having 12GB of RAM doesn't automatically mean it's suitable for running AI models. Check the actual memory requirements against your specific model before assuming it'll work.
There's also an ARM architecture consideration that's easy to overlook. A1 instances run on ARM processors, not x86. Some software has no ARM64 build, some Docker images are only published for x86_64, and certain closed-source or Windows applications won't run on ARM at all. Verify ARM support for your target software before committing to an A1 deployment โ this trips people up more often than the quota size itself.
E2.1.Micro Is Still Free โ and Still Useful in Combination
The two E2.1.Micro instances (AMD, 1/8 OCPU + 1GB RAM each) were not affected by this change. A practical free-tier configuration: use the Micro instances for lightweight background tasks โ monitoring, DNS, jump hosts, small proxy services โ and dedicate the A1's 2 OCPU / 12GB to primary workloads like Docker, WordPress, databases, or APIs. This combination makes better use of the total free allocation than putting everything on A1.
Is Oracle Free Tier Still Worth Getting?
Still yes โ but with eyes open. Even after the cut, 2 OCPU / 12GB ARM compute plus two x86 Micro instances remains one of the more generous always-free cloud offerings among major providers. Oracle's free tier also includes 200GB Block Volume storage, 20GB Object Storage, Autonomous Database, and other always-free resources that haven't changed.
That said, OCI Always Free shouldn't be the sole infrastructure for anything production-critical. This episode illustrates the risk clearly: free cloud resource terms can change without meaningful advance notice, enforcement can be inconsistent in the short term, and even compliant instances can get caught in the middle. If you're running anything important on a free cloud tier from any provider, have a backup plan ready.
The Broader Lesson
Cloud providers are entering a more tightly managed phase for free resource offerings. The allocations still exist, but the rules, enforcement, and โ most notably โ transparency around changes are all tightening. Oracle's handling of this particular adjustment โ no public announcement, inconsistent early enforcement, some compliant instances getting disabled anyway โ reflects the risk that comes with depending on free-tier infrastructure. The right habit is to periodically check the current quota in official documentation, rather than relying on what you remember from when you first signed up.
What to Do Right Now
If you have Oracle A1 free instances: open the console today, verify instance status, and confirm the combined resource total is within the new limits. Don't wait until something looks wrong. If you're over quota, resize or remove instances now. If your instances are within the new limits but show as disabled, contact Oracle support to request reactivation. If you're on a PAYG account and uncertain whether the new limits apply to you, ask Oracle support directly โ the community discussion on this point is contradictory and unreliable as a guide.