Oracle cuts its free ARM offering: urgent reaction

Were you trusting Oracle to host your small ARM project for free? It's time to check your console. For the past few days, Oracle has quietly modified its conditions for the "Always Free" offering — and the change is brutal: available ARM resources have been halved. No email, no blog post, no alert whatsoever. As if your contract of trust had evaporated overnight.

This silent decision raises a fundamental question in the cloud ecosystem: how far can we really rely on free offerings from tech giants? At Studio Dahu, we regularly monitor these developments to advise our clients on the sustainability of their infrastructures. Here's what you need to understand, and above all how to react before your services go down.

Oracle halves its free ARM offering without warning: what exactly happened?

Oracle Cloud Infrastructure's (OCI) "Always Free Tier" offering was exceptional since its launch. Four ARM processors, 24 GB of RAM, two block storage instances of 200 GB each — all this without mandatory credit card and without expiration. For developers, bootstrapping startups, or self-hosting enthusiasts, it was almost too good to be true.

And indeed, it was too good. Oracle has just drastically reduced this allocation: we now go down to two ARM processors and a maximum of 12 GB of RAM. Worse still, this change was made through a simple documentation update, without explicit notification to affected users. Imagine a tenant discovering their lease has been halved upon returning home, simply because the landlord changed the terms displayed in the building's basement.

The technical mechanism is particularly vicious. Users who provisioned instances within the old limit can theoretically keep them — but any attempt to modify, restart, or recreate following an incident exposes them to immediate failure. Your infrastructure becomes a house of cards: stable as long as no one breathes on it, but doomed at the first gust.

Studio Dahu pro tip: always monitor the official documentation pages of your cloud providers, even those you consider "frozen". At Agence Web Genève, we automate this monitoring for our clients via page change monitoring tools.

Why Oracle is making this brutal reduction of its ARM resources

The economic pressure behind free offerings

Cloud "free tier" offerings are never truly free. They constitute massive marketing investments, designed to create a user base that will eventually convert to paid offerings. Oracle, historically lagging behind AWS and Azure, particularly needed this lever to gain market share. But the cost of this customer acquisition is probably prohibitive compared to measured returns.

ARM Ampere Altra processors, even efficient, consume electricity, datacenter space, and above all human support capital. When a population of free users intensively exploits these resources without ever migrating to paid instances, the economic calculation becomes unsustainable. Oracle hasn't announced official figures, but we can assume the conversion/free ratio was disappointing compared to initial expectations.

A deliberately opaque communication strategy

The choice not to directly notify users reveals a conflict minimization strategy. An official announcement would have generated press articles, viral threads on social media, and potentially a leak of the user base to competitors. By proceeding through simple documentation update, Oracle no doubt hopes the noise remains contained to the already engaged technical community — the one that devotes time to reading release notes.

This approach contrasts sharply with certain industry practices. Let's Encrypt: when US sanctions disrupt SSL shows how an organization can proactively communicate on constrained changes. Oracle, in this case, had more leeway and chose opacity.

Transparency is not a marketing luxury: it's a trust asset. A company that hides its setbacks imposes on its users a permanent cognitive cost of surveillance.

Concrete impact: who is affected and which services are at risk of falling

The affected population is larger than it appears. Beyond individual developers, numerous organizations exploit these ARM instances for real production uses. Think of associations managing their associative infrastructure, micro-startups in market validation phase, homelab enthusiasts who have centralized their domestic services, or companies that chose OCI for isolated development environments.

Failure scenarios vary according to deployed architecture. A monolithic instance with four cores and 24 GB can comfortably host a complete stack: database, application, cache, reverse proxy. Halved, it immediately enters overload situation. Services begin to slow down, then fail under memory pressure, triggering destructive swapping cycles for the cloud's shared SSD performance.

• Homemade Kubernetes clusters losing half their scheduling capacity
• In-memory databases (Redis, PostgreSQL with elevated work_mem) suffering repeated OOM kills
• Self-hosted CI/CD pipelines no longer able to process builds in parallel
• Monitoring and backup services themselves becoming victims of the shortage

The snowball effect is particularly dangerous. A system designed to function within given limits, then brutally compressed, does not degrade gracefully: it collapses. And if you had set up redundancy between multiple free accounts to circumvent limits, this strategy is now obsolete too.

How to react immediately: audit and emergency migration

First step: assess your actual exposure

Log in immediately to your OCI console and check three critical elements. First, the "Limits" page to ascertain your current allocation. Then, the status of your running instances: are they still working? Can they be restarted? Finally, your attached storage volumes, because Oracle has in the past modified implicit billing rules on block storage.

Document this configuration scrupulously before any modification. A screenshot of your dashboard, an export of your terraform state if you use Infrastructure-as-Code: these traces will be valuable if you need to subsequently contest a behavior or if you plan to faithfully replicate on a new platform.

Short-term mitigation strategies

If your instances are still running in the old configuration, resist the temptation to modify them. The status quo is your best ally for the moment. In parallel, activate a resource consumption reduction plan: optimization of your applications' memory parameters, disabling of non-critical services, activation of compressed swap (zram) to gain memory resilience.

In the medium term, diversify your hosting. No free provider guarantees immunity against this kind of reversal. Explore existing alternatives — certain offerings from major universities for research, startup credits from Google Cloud or AWS, or even custom development solutions allowing precise optimization of your resource needs.

Infrastructure heterogeneity is a cost, but it is also insurance. We always advise our clients to never concentrate more than 60% of their critical services on a single free offering.

Lessons for the future: rethinking the reliability of low-cost infrastructures

This Oracle episode illustrates a structural tension of modern cloud. The promise of ubiquity and eternity of digital services masks a reality of revocable contracts, unilaterally modifiable conditions, and total information asymmetry between provider and user. When you click "accept terms", you are not signing a treaty: you are adhering to a policy you will never control.

For technical decision-makers and entrepreneurs, the lesson is clear. Free offerings are exploration tools, never production foundations. They allow validating a hypothesis, rapidly prototyping, learning a technology. But as soon as a service acquires value — whether in revenue, reputation, or operational dependency — it deserves sustainable hosting with contractual guarantees.

This is precisely why at Studio Dahu, we guide our clients toward architectures whose costs are predictable and providers substitutable. Custom solution development allows precisely adapting infrastructure to real need, without costly over-provisioning nor excessive dependency on a particular ecosystem. In a world where Oracle can halve its free ARM offering without warning, this architectural agility becomes a strategic competency.

Ultimately, cloud is not a substitute for continuity planning. It is an accelerator that amplifies your good and your bad decisions. Oracle's silent resource reduction reminds us that technical vigilance is not delegated: it is exercised every day, in active tracking of one's dependencies, in resilient design of one's systems, and in pragmatic diversification of one's options.