Oracle Cloud Always Free: what you actually get

Among the major cloud providers, Oracle’s permanently free offering is the outlier. Most free tiers give you enough to complete a tutorial. Oracle’s Always Free resources are substantial enough to run genuinely useful things indefinitely, and the Arm compute allowance in particular is larger than anything comparable elsewhere.

That generosity comes with conditions worth understanding before you build anything you would miss.

The shape of the offer

Always Free resources do not expire. They sit alongside a separate trial credit that does expire, and the two are frequently confused. When the trial credit runs out, the Always Free resources continue.

The headline components are compute, storage, a database allowance, and a modest amount of networking and outbound data transfer. The compute side is split between a small number of fixed micro instances on x86 and a pooled Arm allocation that you can divide as you like: one larger instance, or several smaller ones, up to the pooled limits.

That Arm pool is the interesting part. It is enough to run a small Kubernetes cluster, a personal application with a real database, a game server, a build agent, or a handful of independent services. This is not a token allowance.

The constraints that actually matter

Capacity is not guaranteed. The most common frustration is being unable to launch an Arm instance in a popular region because free capacity is exhausted. This is not a bug or a trick; free resources are allocated from spare capacity. The practical responses are to pick a less busy region, to retry at different times, or to use the automated retry available through the CLI rather than clicking the console repeatedly.

Idle instances can be reclaimed. Oracle reserves the right to reclaim Always Free compute that sits idle over an extended period. If you build something you care about, give it a real workload, or at minimum something that keeps it genuinely active. Do not treat a free instance as guaranteed permanent hosting for an unattended service.

Region is chosen once. Your account’s home region is selected at signup and is not casually changed. Always Free resources are tied to it. If your users are concentrated somewhere specific, choose accordingly at signup rather than discovering the constraint later.

Upgrading changes the rules, mostly for the better. Upgrading to a paid account does not remove the Always Free allowance; it continues alongside paid usage. It does generally improve capacity availability, which is the main practical reason people upgrade.

What it is genuinely good for

Given those constraints, the fit is clear.

It suits personal projects and portfolio sites, learning environments where you want to practise on real infrastructure rather than a simulator, small internal tools, self-hosted applications for a household or small team, development and staging environments, and build or automation agents that would otherwise cost money elsewhere.

It suits less well anything where an unavailable region at launch time is a blocker, anything you cannot afford to have reclaimed, and anything with a business dependency where you would want a support relationship.

Getting the most from the Arm allocation

The Arm instances run Ampere processors, which means the same architecture consideration that applies anywhere else. Interpreted and JIT-compiled languages generally work without changes. Compiled dependencies and container images need Arm builds, which are now widely available but not universal.

If you are dividing the pool, resist the temptation to create the maximum number of tiny instances. A smaller number of larger instances is usually easier to operate, and consolidating services onto one machine with containers gives you flexibility without multiplying the operating systems you have to patch.

Attach the block storage allowance deliberately rather than accepting defaults, and remember that storage counts toward the free limits as a total across volumes.

Practical setup notes

A few things save time.

• Enable multi-factor authentication immediately. A free account is still an account with compute attached, and compute attached to a compromised account gets used for things you would not choose.
• Set a budget alert even on a free account. It costs nothing and catches the moment you accidentally create something outside the free limits.
• Understand the difference between Always Free and trial resources in the console. Resources eligible for the free tier are marked. Creating something not so marked will bill once the trial credit is exhausted.
• Use the CLI or Terraform for instance creation if capacity is scarce. Automated retry is far less tedious than manual attempts, and it works.
• Take your own backups. The free tier is not a durability promise.

A fair summary

Oracle Cloud‘s Always Free tier is the most substantial permanently free compute offering among the major providers, and for a personal project or a learning environment it is difficult to beat on value. The trade-offs are capacity availability, the reclamation policy for idle resources, and the fixed home region.

Match those trade-offs against what you are building. For a side project, they are minor. For something with users who would notice an outage, they are the reason to run it somewhere with a commercial relationship behind it.

For the vendor’s own reference on the services involved here, see the Oracle Cloud Infrastructure documentation.

Questions people ask