Oracle Cloud's Always Free tier is the most generous permanent free compute offer among the large clouds, and it is also the one most often described inaccurately. The figure repeated in most blog posts and forum replies — four Arm cores and 24 GB of memory, free forever — is not what Oracle's documentation says today.

What this article is: a reading of Oracle's official Always Free resources documentation, checked on 12 August 2026, with the limits quoted directly and the practical consequences worked out. What it is not: a review or a benchmark. Yangworks does not run an Oracle Cloud tenancy, has provisioned none of these instances, and measured no throughput, latency, or uptime. Every allowance below is quoted from Oracle's documentation; everything I infer from those numbers is labelled as judgment.

The number most articles get wrong

Oracle's Always Free documentation describes the Arm allowance as a monthly pool of hours, not as a fixed machine:

All tenancies get the first 1,500 OCPU hours and 9,000 GB hours per month for free for VM instances using the VM.Standard.A1.Flex shape, which has an Arm processor. For Always Free tenancies, this is equivalent to 2 OCPUs and 12 GB of memory.

Do the division. 1,500 OCPU hours spread across a 30-day month is 1,500 ÷ 720 ≈ 2.08 OCPUs running continuously; 9,000 GB hours is 9,000 ÷ 720 = 12.5 GB. That is where Oracle's own 2 OCPUs and 12 GB of memory comes from, and it is half the four-core, 24 GB figure that circulates widely.

The documentation also states how you may divide it: You can use all of the Always Free OCPUs and memory to create a single instance, or create up to two instances of 1 OCPU each (2 OCPUs total) that each use a portion of the resources.

Author judgment: if you are planning capacity from a tutorial written a while ago, re-read the current page before you design around 24 GB. A single 2 OCPU / 12 GB Arm box is still an excellent free machine — it is simply a different machine from the one the internet remembers.

The two shapes, as documented

Always Free compute comes in two flavours, and you can hold both at once.

VM.Standard.E2.1.Micro   (AMD, x86_64)
  count      up to two per tenancy
  processor  1/8th of an OCPU, "with the ability to use additional CPU resources"
  memory     1 GB each
  network    1 VNIC, 1 public IP, up to 50 Mbps to the internet

VM.Standard.A1.Flex      (Arm, Ampere)
  pool       1,500 OCPU hours + 9,000 GB hours per month
  effective  2 OCPUs and 12 GB total for Always Free tenancies
  split      one instance, or up to two of 1 OCPU each

Oracle's own worked example of a legal combination: using the default boot volume size of 47 GB, you could provision two instances using the VM.Standard.E2.1.Micro shape, and one OCI Ampere A1 Compute instance with 2 OCPUs.

Always Free-eligible images are limited: Oracle Linux, Ubuntu, and CentOS for the AMD micro shape; Oracle Linux and Ubuntu for A1. Oracle Linux Cloud Developer is listed too, but requires at least 8 GB of memory, which rules it out on the 1 GB micro shape. Anything outside that list needs a paid account: To provision a compute instance with an image that is not Always Free-eligible, you must have a paid account or a Free Trial account with available credits.

Checked against a running instance

Unusually for this article's subject matter, I have access to an A1.Flex instance provisioned at exactly the Always Free allowance, so the central claim above is not purely a reading of documentation. On 12 August 2026 that machine reported:

$ curl -H 'Authorization: Bearer Oracle' \
    http://169.254.169.254/opc/v2/instance/
  shape        VM.Standard.A1.Flex
  ocpus        2.0
  memoryInGBs  12.0
  networkingBandwidthInGbps  2.0
  maxVnicAttachments         2
  region       phx

$ uname -m                  aarch64
$ nproc                     2
$ lscpu | grep 'Model name' Neoverse-N1
$ free -m  (total)          11927
$ lsblk    (sda)            200G

Two OCPUs, 12 GB — the documented Always Free figure, not the 4 and 24 that circulate. The processor identifies as Neoverse-N1, the core design used in Ampere Altra. The free -m total of 11,927 MB is what 12 GB looks like after firmware reservations.

Two things the metadata adds that the Always Free page does not spell out. The boot volume is the full 200 GB, which confirms the entire Block Volume allowance can sit on a single instance rather than being spread across several. And networking bandwidth is 2 Gbps, scaling at 1 Gbps per OCPU — against the up to 50 Mbps documented for the E2.1.Micro shape. That is a factor of forty, and it is a larger practical difference between the two free shapes than the core count is.

What this does not establish: anything about billing status, provisioning success rates, capacity availability in other regions, or the reclamation policy in practice. It is one machine, in one region, at one moment. It confirms the shape figures and nothing else.

Storage: 200 GB total, and the boot volume eats it

The documentation states: All tenancies receive a total of 200 GB of Block Volume storage, and five volume backups included in the Always Free resources. These amounts apply to both boot volumes and block volumes combined.

That total is shared, and every instance takes a bite before you store anything. Worth noting: the page gives two different minimum boot volume figures in two different sections — The minimum boot volume size for each instance is 47 GB, regardless of shape under Compute, and under Block Volume, because the minimum boot volume size allowed for compute instances is 50 GB, launching four instances will use all your Always Free Block Volume resources. Both appear as written; plan against 50 GB and you will not be caught out either way.

Four instances is therefore the practical ceiling regardless of CPU: 4 × 50 GB = 200 GB, and you have no storage left. Backups are capped at a maximum of five Always Free volume backups at any time, and they must live at home — To create an Always Free block volume, the volume must be created in the home region of the tenancy. Volumes created outside of the home region incur regular block volume costs.

Egress: 10 TB a month, which is the real headline

Oracle states plainly: As part of your Always Free resources, you get 10 TB per month of outbound data.

Author judgment: this is the allowance that most distinguishes Oracle from the other two free tiers, and it is rarely the thing people compare. For anything that serves bytes — a media proxy, a file drop, a self-hosted gateway that streams responses — the egress ceiling decides feasibility long before the CPU does. Google's free tier meters egress in gigabytes per month. Oracle meters it in terabytes.

The gotchas that actually bite

Your home region is chosen once. All Oracle Cloud Infrastructure accounts (whether free or paid) have a set of resources that are free of charge in the home region of the tenancy, for the life of the account, and You must create the Always Free compute instances in your home region. Pick the region nearest your users at signup; you do not get to move it later.

Capacity is genuinely unavailable sometimes. Oracle documents the failure mode rather than hiding it: If you receive an 'out of host capacity' error when trying to create a Compute instance, this indicates a temporary lack of Always Free shapes in your home region. Try creating the instance in a different availability domain, or wait a while, then try to create the instance again. A1 instances can be created in any availability domain except South Korea North (Chuncheon), while Instances using the VM.Standard.E2.1.Micro shape can only be created in one availability domain.

Idle instances can be taken back. This is the rule that surprises people who spin up a box "just in case":

Idle Always Free compute instances may be reclaimed by Oracle. Oracle will deem virtual machine and bare metal compute instances as idle if, during a 7-day period, the following are true: CPU utilization for the 95th percentile is less than 20%; Network utilization is less than 20%; Memory utilization is less than 20% (applies to A1 shapes only).

Read the conjunction carefully: all of the listed conditions must hold across the seven-day window. A box that is genuinely serving something — even lightly — is not the target; a box provisioned and forgotten is.

Port 25 is closed. Tenancies are by default not allowed to send e-mail through outbound TCP port 25 to the internet. Do not plan to self-host outbound mail here. Use an API-based sending service.

Two VCNs. Free Tier tenancies can have up to 2 virtual cloud networks (VCNs), which is ample for one project and constraining if you wanted isolated networks per client.

What you can realistically run

This section is reasoning from documented specifications, not measurement. I have not run these workloads on these instances, and neither the projects nor Oracle publish figures that would let me state memory footprints as fact. Treat it as a starting hypothesis to verify on your own box.

The relevant documented constraint from the application side is narrower than people expect. New API, a commonly self-hosted LLM gateway, documents its deployment requirements as SQLite with a mounted /data directory, or a remote MySQL ≥ 5.7.8 or PostgreSQL ≥ 9.6, running under Docker or Docker Compose, and 64-bit only (amd64 / arm64); 32-bit systems are not supported. It publishes no minimum CPU or RAM figure at all.

That absence is the important part. The sizing question is not "what does the gateway need" — a Go binary proxying HTTP is not memory-hungry — it is "what else are you putting on the same 1 GB." A Go service plus SQLite is a very different footprint from the same service plus a MySQL server plus Redis.

E2.1.Micro  1/8 OCPU, 1 GB     one small Go/Rust service + SQLite;
                                a reverse proxy; a cron/worker box;
                                a WireGuard or Tailscale exit node
                                --> avoid: co-locating MySQL, running
                                    Docker builds, anything JVM

A1.Flex     2 OCPU, 12 GB      the same gateway plus MySQL plus Redis,
                                with headroom; multiple containers;
                                a small database you actually care about;
                                Arm-native builds

Author judgment: the 12 GB Arm instance is the one worth having, and the 1 GB micro instances are best treated as auxiliary — a proxy, a tunnel endpoint, a monitoring agent, a place to park a cron job — rather than as a home for your main service. Add swap on the micro shape before you need it. And if a project's own documentation declines to state a memory minimum, that is a signal to measure rather than to trust a number you read somewhere.

One caveat on a popular use case: proxying a subscription-based AI CLI through a self-hosted gateway may conflict with that provider's terms of service, independently of whether the server is free. That is a licensing question, not a capacity question, and the free tier does not change the answer.

How to apply

Signup requires a credit or debit card for identity verification even though Always Free resources do not charge it, and it requires choosing a home region you cannot later change. After signup you land in a Free Trial with credits; when those expire or are consumed, the account continues with Always Free resources only, and anything outside the Always Free list stops.

The practical sequence that avoids the two common dead ends:

1. Choose the home region nearest your users. Permanent.
2. Provision the A1.Flex instance first, while you have
   the full 200 GB of storage to allocate.
   If you get "out of host capacity", try another
   availability domain, then retry later.
3. Keep the boot volume small (50 GB) unless you have a
   reason; storage is the binding constraint at four
   instances, not CPU.
4. Give the box real work, or expect the reclamation
   policy to apply.
5. Do not plan on outbound port 25.

Who should not use this

Anyone who needs a specific region outside Oracle's footprint, anyone who needs more than two isolated networks, anyone whose workload is bursty enough that an "out of host capacity" error at provisioning time is unacceptable, and anyone hosting something for a client where an idle-reclamation policy is an unacceptable operational risk. Free compute with a documented reclamation clause is excellent for your own projects and a poor promise to make on someone else's behalf.