A free 24/7 server on Oracle Cloud — what actually works

Oracle Cloud has a tier called Always Free. It gives you real virtual machines that cost nothing and don't expire. Not a 12-month trial like AWS — the resources stay free for as long as the account exists, provided you never upgrade to paid.

We run one. Signed up on June 29, spent a week fighting the famous "Out of capacity" error on the ARM machines, and on July 8 landed a small AMD instance that now runs a 24/7 service for us at $0. This note is everything I'd want someone to tell me before starting: what you actually get, where the traps are, and the retry-script trick that deals with the capacity problem.

What "Always Free" actually is

An Oracle Cloud account comes with two separate things. First, a 30-day trial with $300 of credits — that part expires. Second, the Always Free resources — that part doesn't. When the trial ends, anything you built on trial credits gets reclaimed, but Always Free resources keep running untouched. Oracle's docs state it plainly: "After your trial ends, your account remains active. There is no interruption to the availability of the Always Free Resources you have provisioned."

The Always Free allowance, verified against Oracle's own documentation in July 2026:

One correction to what most guides still say: the ARM allowance used to be 4 OCPUs and 24 GB of RAM. Oracle cut it to 2 OCPUs / 12 GB on June 15, 2026, quietly, through a documentation update — no blog post, no email. Any guide promising a free 4-core 24 GB machine is out of date. 2/12 is still a genuinely useful box.

Signing up — three things to know before you click

1. Your home region is permanent. Always Free compute and databases can only be created in the home region you pick at signup, and you cannot change it later. Pick the region closest to your users and stop there — don't overthink it, but don't pick casually either. We picked Hyderabad. There's no way to know in advance which region has spare ARM capacity, so optimize for latency, not for rumors about free slots.

2. A card is required, but it isn't billed. Oracle asks for a credit or debit card and a mobile number at signup to verify you're a person. They put a small temporary authorization hold on the card and release it. The docs are explicit: "Your credit card will not be charged unless you upgrade your account." As long as you never click upgrade, the account cannot bill you. Some Indian debit cards fail the verification step — if yours does, try a credit card.

3. Never upgrade. Ever. The only way this setup costs money is if you convert to Pay As You Go. Everything in this note works on the un-upgraded free account. Treat the upgrade button as radioactive.

The ARM problem: "Out of capacity"

The ARM machines are the prize, so everyone wants one, so in most regions there aren't any. When you try to launch an Ampere A1 instance on a free account, you will very likely get "Out of host capacity" — and you may keep getting it for days or weeks. This is normal. It's not your account, it's not a mistake in your setup. Free-tier requests get whatever capacity is left after paying customers, and in busy regions that's often nothing.

The strategy that works is a retry loop. Ours calls the Oracle API through the Python SDK every 12 minutes, around the clock, trying the smallest ARM shape first (1 OCPU / 6 GB), then stepping up. Small shapes fit into capacity gaps that a full 2/12 request won't. Once any ARM instance lands, you can resize it upward in place later — same machine, same IP. The skeleton:

while true:
    for shape in [(1, 6), (2, 12)]:          # smallest first
        try:
            launch_instance(ocpus=shape[0], ram_gb=shape[1])
            notify("got it"); exit()
        except (CapacityError, TooManyRequests):
            pass                              # 500/429 = no capacity, expected
    sleep(12 * 60)                            # ~12 min; don't hammer the API

Two rules for the loop. Keep the interval sane — around 10–15 minutes. Hammering every few seconds gets you rate-limited and helps nobody. And leave it running unattended; ours has logged every single attempt in Hyderabad as "no capacity" for over a week now, which is exactly the war of attrition everyone else reports. It lands when it lands.

The fallback nobody mentions: the AMD micro launches instantly

Here's the part that most guides skip. The two AMD micro instances are a separate allowance from the ARM one. While our ARM script was striking out attempt after attempt, we launched a VM.Standard.E2.1.Micro — and it came up on the first try, in about a minute. No capacity fight at all, at least in our region.

So the practical play for a founder who needs something running today: start the ARM retry script, and in parallel take an AMD micro now. It's a small machine — 1/8 of a CPU core, 1 GB of RAM — but it's a real public-IP Linux box that runs 24/7 for free, and it holds you over until the ARM box lands.

First 15 minutes on a 1 GB box

Three things before you deploy anything.

SSH in with the key you gave at launch. Ubuntu images log in as ubuntu, Oracle Linux as opc: ssh -i ~/.ssh/your_key ubuntu@<public-ip>.

Add swap immediately. 1 GB of RAM with no swap means the kernel kills your process the first time anything spikes. 2 GB of swap makes the box far more forgiving:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Open ports in two places. This one burns everyone. Oracle blocks inbound traffic at the network level (the VCN "security list") and the Ubuntu images ship with their own iptables rules. Opening port 80 in the cloud console does nothing until the OS firewall allows it too. Add an ingress rule in the security list for each port (22, 80, 443, whatever your app needs), then open the same port on the box itself — check sudo iptables -L INPUT if a port that should work doesn't.

What 1 GB can and can't run

• Runs fine: nginx or Caddy serving static sites, a reverse proxy, a Telegram or WhatsApp bot, cron workers, an uptime monitor, a small Flask/FastAPI or Node service, SQLite-backed apps.
• Struggles: heavy Node builds (build elsewhere, copy artifacts over), Docker Compose stacks with several containers, Postgres or MySQL under real load.
• Forget it: LLM inference, video processing, anything that wants gigabytes of RAM. That's what the ARM box — or someone else's GPU — is for.

The honest framing: the AMD micro is a free always-on utility box, and the ARM 2/12 machine — once your script catches one — is a legitimate small production server. For a founder pre-revenue, that pairing covers a surprising amount of ground before you owe anyone a rupee.

References

Oracle's own pages, so you can verify every number above:
· Oracle Cloud Free Tier — overview and signup
· Always Free Resources — the canonical allowance list
· Free Tier documentation — trial vs Always Free, home region rules
· InfoQ on the June 2026 ARM reduction — the 4/24 → 2/12 change