OCI Always Free Tier, in depth: what is free, what gets reclaimed, and how to build within it

A free-tier application at a glance

Trial, Always Free and Pay As You Go

A new OCI account starts as a Free Trial: a limited period with credits you can spend on most services, alongside the Always Free resources. When the trial ends, an account that has not been upgraded becomes an Always Free tenancy. Paid resources created during the trial are stopped and eventually reclaimed, while Always Free resources keep running. Upgrading to Pay As You Go keeps the Always Free allowances and lets you create billed resources next to them.

Two consequences matter for design. First, during the trial it is easy to build on paid shapes without noticing, because the credits cover them, and that work disappears when the trial ends. Second, some allowances differ between tenancy types. Object storage, for example, is 20 GB combined for Always-Free-only accounts but 10 GB per tier for trial and paid accounts. Read the allowance for the account type you will have after the trial, not during it.

All Always Free resources must live in the tenancy's home region, which you choose at sign-up and cannot change. The same shape launched in another region is billed. Choose a home region close to your users, and expect popular regions to run short of free Arm capacity at times. When that happens, instance launches fail with a capacity error, and retrying later or in another availability domain of the same region is the only remedy.

What is free, with limits

Compute and storage arithmetic

The A1 allowance is measured in hours, not in a fixed machine. A 31-day month has 744 hours, so 1,500 OCPU hours covers 2 OCPUs running all month (1,488 hours) and 9,000 GB hours covers 12 GB (8,928 hours). You can spend that as one VM with 2 OCPUs and 12 GB or as two VMs with 1 OCPU and 6 GB each. On VM.Standard.A1.Flex each OCPU is one physical Arm core. The compute shapes article explains why that differs from the x86 OCPU, which is two hardware threads. Running more than the allowance is not blocked on a paid account; it is billed.

The two E2.1.Micro instances are small but useful for anything that mostly waits: a bastion, a scheduled job, a DNS updater or a small reverse proxy. Each comes with 1 GB of memory, so run a minimal operating system image and avoid JVM-heavy workloads on them.

Storage is the limit people hit first. Every instance needs a boot volume of at least 47 GB, and the 200 GB total includes boot volumes. Three instances with 50 GB boot volumes use 150 GB, leaving 50 GB for data. Plan the volume layout before you launch, because shrinking a boot volume later means rebuilding the instance.

# Launch the app VM on the Arm allowance (OCI CLI).
oci compute instance launch \
  --compartment-id "$COMPARTMENT" \
  --availability-domain "$AD" \
  --shape VM.Standard.A1.Flex \
  --shape-config '{"ocpus": 2, "memoryInGBs": 12}' \
  --image-id "$UBUNTU_ARM_IMAGE" \
  --subnet-id "$PUBLIC_SUBNET" \
  --boot-volume-size-in-gbs 50 \
  --assign-public-ip true \
  --ssh-authorized-keys-file ~/.ssh/id_ed25519.pub \
  --display-name app-a1

Autonomous Database, the free way

Each tenancy can run two Always Free Autonomous Databases, each with 1 OCPU and 20 GB of storage, for transaction processing, JSON, APEX or lakehouse workloads. They are real Oracle databases with automatic patching and mTLS connections through a downloaded wallet. However, the Always Free version has rules the paid service does not:

• It cannot be scaled, manually or automatically.
• It has no backups and no restore to a point in time. If you drop a table, it is gone.
• It is stopped after 7 days of inactivity. Inactivity is judged on connections and CPU use, and SQL*Net or HTTPS connections that run SQL reset the timer.
• It is permanently deleted after 90 days of cumulative inactivity while stopped or inactive.
• Concurrent sessions are capped low. Oracle's two pages disagree, giving 20 on one and 30 on the other, so design for 20.

Because there are no backups, you must provide your own. A nightly application-level export of the tables you care about, written as CSV or JSON to an Object Storage bucket, is cheap insurance. Keep exports small enough to fit the 20 GB bucket allowance with a few generations retained. You can upgrade an Always Free database to a paid one (online, for transaction processing) if the project outgrows it, which is the clean exit path.

Idle reclamation

Oracle may reclaim Always Free compute instances that are idle. An instance counts as idle if, over a 7-day period, its 95th-percentile CPU utilisation is under 20%, its network utilisation is under 20%, and, for A1 shapes only, its memory utilisation is under 20%. All the conditions must be true. A personal website that serves a few requests an hour can meet all three.

The honest fix is to give the instance real work or to accept that it is disposable. Run the service, its scheduled jobs and its build tasks on the same VM rather than spreading them thinly. Keep everything needed to rebuild the machine (Terraform, cloud-init, the application's container image) in version control, so a reclaim costs you minutes. Oracle's Monitoring service publishes the CPU and memory metrics that the rule uses, so you can see where you stand. Do not rely on unconfirmed claims that upgraded accounts are exempt. Check Oracle's current terms for your tenancy type.

Worked example: an internal app for 200 users

Consider a small team that wants to host an internal feedback application: a web front end, a REST API, a database and nightly reports, for about 200 users. Here is how it fits the tier.

• Network. One VCN with a public subnet for the load balancer and a private subnet for the application, following the patterns in OCI networking. Security lists allow only 443 from the internet to the load balancer, and only the application port from the load balancer subnet to the private subnet.
• Compute. One A1 VM with 2 OCPUs and 12 GB runs the API and web front end in containers. One E2.1.Micro runs nightly report jobs and the export script. The second micro is left spare for a staging copy.
• Entry. The flexible load balancer terminates TLS. At 10 Mbps it can serve roughly 1.25 MB per second, which is plenty for JSON and small pages. Large static files should come from Object Storage or a CDN rather than through the load balancer.
• Data. One Autonomous Database in transaction processing mode holds the application data. Daily traffic from 200 users keeps it well clear of the 7-day stop rule. The second database is used for testing.
• Storage budget. Two boot volumes of 50 GB and one of 47 GB use 147 GB, leaving 53 GB for a data volume on the A1 VM. Exports go to a bucket with a lifecycle rule that keeps seven days of history.
• Access. No public IP on the application VM; administrators use the Bastion service. Credentials live in Vault secrets, and IAM policies in a dedicated compartment follow OCI IAM least-privilege patterns.

Guarding against surprise charges

On a Pay As You Go account, the risk is not reclamation but surprise charges: a shape picked from a drop-down, a volume grown past the allowance, or a resource launched in the wrong region. Two controls catch these early. First, a budget on the compartment with an alert on actual spend above zero. Second, a habit of checking each resource's Always Free label in the console, and, for databases, setting the free-tier flag in code so a paid shape is never created by accident.

# Budget of 1 (account currency) on the project compartment, alerting on any actual spend.
oci budgets budget create --compartment-id "$TENANCY" \
  --amount 1 --reset-period MONTHLY \
  --target-type COMPARTMENT --targets "[\"$COMPARTMENT\"]" \
  --display-name free-tier-guard
oci budgets alert-rule create --budget-id "$BUDGET_ID" \
  --type ACTUAL --threshold 1 --threshold-type PERCENTAGE \
  --recipients "ops@example.com"

# Terraform: refuse to create a paid Autonomous Database by mistake.
resource "oci_database_autonomous_database" "app" {
  compartment_id = var.compartment_id
  db_name        = "feedback"
  display_name   = "feedback-free"
  db_workload    = "OLTP"
  is_free_tier   = true
  admin_password = var.adb_admin_password
}

Failure modes

Trade-offs

The tier is excellent for learning OCI, hosting personal and small internal tools, running Arm CI jobs and prototyping on Autonomous Database. It is a poor fit for anything that needs an availability promise. There is no redundancy in this design, no database backups unless you build them, a 10 Mbps entry point, and an operator who may reclaim idle capacity. For production, treat Always Free as the base of a paid account rather than its replacement: keep the free VM for supporting jobs, and pay for the components that need resilience. Compared with other clouds' free tiers, OCI's is unusually generous on Arm compute and egress, but tied more tightly to one region and to evidence of use.

What to do next

1. Before sign-up, choose the home region on purpose, near your users and with Arm capacity in mind.
2. Re-read Oracle's Always Free Resources page and write down the current A1, storage and object limits for the account type you will have after the trial.
3. Draw the volume plan (boot sizes plus data) so it totals 200 GB or less.
4. Describe the stack in Terraform with the region pinned and is_free_tier = true on databases.
5. Create a budget and an actual-spend alert on the project compartment on day one.
6. Schedule exports of every Always Free database to Object Storage and test a restore into the second database.
7. Watch CPU, network and memory in Monitoring for a week, and decide whether the VM does enough real work or should be rebuildable in minutes.