Downsizing a 30-Container Homelab to 2 OCPUs

Oracle Cloud's Always Free tier has been the best deal in hobbyist infrastructure for years: 4 Ampere A1 OCPUs, 24 GB of RAM, 200 GB of storage — free forever, generous enough to run a serious homelab or a fleet of side projects.

That deal just got cut in half, and Oracle didn't exactly send a press release.

In June 2026 the Always Free documentation was quietly updated: the A1 allowance dropped to 1,500 OCPU-hours and 9,000 GB-hours per month — the equivalent of 2 OCPUs and 12 GB of RAM running continuously. Then the enforcement emails started landing:

Beginning on August 18, 2026, Oracle will begin enforcing the updated Always Free compute limits. Compute instances that exceed the Always Free entitlement will be automatically terminated.

Not throttled. Not billed. Terminated.

Long before Oracle became one of the clouds we run production on, we used its free tier the way it's meant to be used: as a lab. Ours grew into a proper multi-service homelab VM — reverse proxy, blog, password manager, object storage, a handful of experimental backends — sitting exactly on the old 4 OCPU / 24 GB ceiling. This post is the playbook we used to get it under the new limits in one afternoon, with every byte of data accounted for. If you have an over-limit instance and an August 18 deadline, this is for you.

What actually changed

Two details that matter:

• Enforcement is on the provisioned shape, not your usage. A 4-OCPU instance idling at 3% CPU is still over the limit. You must resize the shape, not just run less.
• Storage survived the cut. If your boot volume is under 200 GB you don't need to touch it — and boot volumes can't shrink anyway, only grow, so this is genuinely good news.

Pay As You Go accounts are a gray zone: the docs say the free allowance applies to "all tenancies," and in our experience PAYG tenancies keep the free 2/12 allowance and simply bill for anything above it rather than terminating. Free-tier accounts get the axe.

Step 1: Find out if the axe is aimed at you

SSH in and look at the shape, not the vibes:

nproc                 # OCPU count (A1: 1 OCPU = 1 core)
free -h               # provisioned RAM
df -h /               # boot volume vs the 200 GB cap

4 cores / 24 GB? You're on the list. Now measure what you actually use, because the gap between provisioned and used is where your survival plan lives:

free -h                                          # look at "used", ignore cache
docker stats --no-stream --format \
  "{{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}" | sort -k2 -hr

Our "full" 24 GB box was using 5.2 GB. Yours is probably similar — RAM on a homelab is mostly page cache flexing into the empty space. If your true working set is under ~9 GB, you can fit in the new tier without abandoning anything important.

Step 2: Archive before you touch anything

The iron rule of infrastructure surgery: nothing gets deleted that isn't restorable from somewhere else first. Before any trimming:

# database dumps for every service you might retire
docker exec <pg-container> pg_dump -U <user> -d <db> -Fc -f /tmp/<db>.dump

# tar the stack configs and any bind-mounted data
tar czf stacks-config.tgz -C ~/stacks <dir1> <dir2> ...

Then get the archives off the machine that's about to be resized. We pushed ours to OCI Object Storage (the 20 GB free allowance is perfect for this) via rclone from a second box, and verified the upload before the first docker compose down. Object Storage lives outside the instance's failure domain — if the resize, or Oracle, eats the VM, the archives don't care.

Step 3: Triage every container into three buckets

Walk your docker stats output top-down and be ruthless:

Kill — things that already live somewhere else. Our biggest finds: a staging copy of a site whose production had long since moved to dedicated hosting (the local copy was serving exactly zero external requests, which we confirmed from the reverse-proxy logs before touching it), a legacy API whose traffic turned out to be nothing but its own TLS-renewal checks, and an abandoned alpha stack. That was 12 containers gone and nobody noticed.

Move — things that deserve a home of their own. Our social-media scheduler moved off the box entirely; its public domain never changed, because the reverse proxy now forwards to the scheduler's new home over a private WireGuard/Tailscale network. Users saw a 302 the whole time.

Keep — the actual load-bearing services. For us: the edge proxy, blog, password manager, object storage, database, and a handful of app backends. Eighteen containers, 2.9 GB working set.

The triage surprised us: more than a third of the machine was serving either nobody or a past version of ourselves. A forced downsize is a decent audit.

Step 4: Resize the shape

The resize itself is the easy part — flexible shapes resize in place:

1. OCI Console → Compute → Instances → your instance
2. Edit → Edit shape → keep VM.Standard.A1.Flex, set 2 OCPUs / 12 GB
3. Save. The instance reboots automatically (~2–5 minutes).

Two preparation notes:

• Make sure every service has restart: unless-stopped in its compose file so the reboot brings everything back without you.
• Downsizing rarely hits capacity problems, but upsizing an A1 later is a lottery — San Jose and other popular regions regularly run dry of free-tier A1 capacity for days. Treat 2/12 as the permanent budget, not a temporary squeeze.

Step 5: The gotchas that bite after the resize

Idle reclamation is the second axe. Free-tier instances that sit below 20% CPU, network, and memory utilization (95th percentile, over 7 days) can be reclaimed as idle — a policy that predates the halving and now matters more, because your freshly-trimmed box is lighter. The clean fix is upgrading the account to PAYG: the free allowance still applies, you pay $0 while inside it, and both the idle-reclaim and termination policies stop applying to you. The card-verification dance takes five minutes.

Half of "free tier" advice is now wrong. Every homelab tutorial written before June 2026 — including, in fairness, an older guide on our own personal blog — assumes the 4/24 allowance and cheerfully tells you to provision all of it. If a guide's shopping list starts at 4 OCPUs, date-check it.

Oracle-image firewall rules. If your trimmed setup involves any traffic forwarding (VPN exit nodes, WireGuard servers), note that Oracle's Ubuntu images ship an iptables REJECT rule in the FORWARD chain that silently blackholes forwarded traffic. iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited and netfilter-persistent save.

What 2 OCPUs and 12 GB actually runs

Post-trim, our lab box runs eighteen containers: Caddy terminating TLS for a half-dozen domains, a Ghost blog, Vaultwarden, MinIO with nightly off-site backup, PostgreSQL, a few experimental backends, a MIDI-sync toy, monitoring, and a remote-desktop relay — at 2.9 GB RAM and single-digit CPU. The new free tier is smaller, but it is still, honestly, a lot of computer for $0.

The lesson we're taking: free tiers are loans, not grants. The provider can call them in with a documentation edit. Keep everything reproducible — configs in git, data in dumps, archives off-box — and a halving becomes an afternoon of tidying instead of a disaster.

---

We're the team behind Remotype, Remotext, and Foldyni. Experiments like this homelab are how we vetted Oracle's cloud before trusting it with real workloads — the tinkering pays for itself. More engineering notes on the blog.