Oracle Cloud Always Free ARM Instance: Setup Guide for 2026

Oracle Cloud gives away a server with 4 ARM CPUs, 24 GB of RAM, and 200 GB of storage. Permanently. No trial countdown, no credit balance to watch. As long as your account stays active, the instance stays free.

The specs sound too good to be real. They are real. I've been running one for over three months in the Tokyo region with six production services and zero infrastructure cost. But getting from "sign up" to "working server accessible from the internet" has a few steps that aren't obvious, and one particular gotcha that cost me an entire afternoon.

What You Get (and What You Don't)

The Always Free tier includes one Ampere ARM instance with up to 4 OCPUs and 24 GB of RAM. You can split this into multiple smaller instances or use it as one machine. I run everything on a single instance — simpler to manage, and 24 GB is more than enough.

What's included beyond compute:

# Oracle Cloud Always Free — what's actually free Compute: 4 ARM OCPUs, 24 GB RAM (Ampere A1) Storage: 200 GB block volume (boot + data) Egress: 10 TB/month outbound traffic OS: Ubuntu 22.04 or 24.04 (your choice) IPv4: 1 public IP address Availability: 24/7, no idle shutdown # What's NOT included in free tier Managed database (Autonomous DB requires paid tier) Load balancer (free tier exists but limited) Additional block volumes beyond 200 GB x86 instances (ARM only for Always Free)

The 10 TB monthly egress is generous. For comparison, AWS free tier gives you 100 GB. I've never used more than a fraction of Oracle's allowance.

Step 1: Sign Up (and What to Do If It Fails)

Go to cloud.oracle.com and create an account. You'll need a valid email and a credit card for identity verification. The card won't be charged on the Always Free tier.

Pick your home region carefully — you can't change it later. Choose the region closest to your primary user base. I picked Tokyo because most of my API users are in Asia-Pacific.

Here's the part that trips people up: Oracle sometimes rejects accounts without explanation. No error message, no reason given. Just a denial after you complete the signup form. This has happened to people I've talked to, and the consensus fix is to try again with a different email address and a different payment method. There's no official explanation for why some accounts get rejected.

Step 2: Launch the Instance

Once your account is active, navigate to Compute → Instances → Create Instance.

The settings that matter:

Image: Ubuntu 22.04 or 24.04. Both work. Canonical maintains official ARM builds for Oracle Cloud.

Shape: VM.Standard.A1.Flex (this is the ARM shape). Set OCPUs to 4 and memory to 24 GB to get the full Always Free allocation.

Networking: Create a new VCN if you don't have one. Accept the defaults for now — we'll fix the security settings in the next step.

SSH key: Upload your public key or let Oracle generate a key pair. You'll need this to connect. If you don't have an SSH key, generate one:

# Generate SSH key pair (Mac/Linux) ssh-keygen -t ed25519 -f ~/.ssh/oracle_key # Your public key (upload this to Oracle) cat ~/.ssh/oracle_key.pub # Connect after instance launches ssh -i ~/.ssh/oracle_key ubuntu@YOUR_PUBLIC_IP

The instance takes 2-5 minutes to provision. Sometimes longer during peak demand. If provisioning fails with "out of capacity," try a different availability domain within the same region, or try again in a few hours.

Step 3: The Security List Fix (The Part That Wastes Hours)

This is the gotcha. Your instance is running. You've SSH'd in. You've started your web server on port 8000. You open a browser, type in the public IP, and — nothing. Connection timeout. The service is running locally (you can verify with curl localhost:8000 from inside the server), but the outside world can't reach it.

The problem: Oracle's VCN security list blocks all incoming traffic by default. Not just unusual ports — everything. Ports 80 and 443, the standard web ports, are closed out of the box.

The fix (takes 2 minutes once you know where to look): In the Oracle dashboard, go to Networking → Virtual Cloud Networks → click your VCN → Security Lists → Default Security List → Add Ingress Rules. Add two rules: port 80 with source 0.0.0.0/0, and port 443 with source 0.0.0.0/0. If you're running services on custom ports (like 8000 or 3000), add those too. Save. Traffic starts flowing immediately.

I spent an entire afternoon rebuilding my deployment from scratch because I didn't realize this was a networking issue, not an application issue. The service worked fine locally. The firewall on the instance itself (iptables) wasn't blocking anything. It was the VCN security list — a layer of firewall that lives in Oracle's dashboard, outside the instance. Once I added the ingress rules, everything worked instantly.

There's a second firewall layer on the instance itself (iptables on Ubuntu). If traffic still doesn't reach your service after fixing the security list, check iptables rules on the instance. Most Ubuntu images on Oracle have iptables rules that also need port 80/443 opened:

# Check current iptables rules sudo iptables -L -n # If ports are blocked, add rules sudo iptables -I INPUT 6 -p tcp --dport 80 -j ACCEPT sudo iptables -I INPUT 6 -p tcp --dport 443 -j ACCEPT # Save so rules persist after reboot sudo netfilter-persistent save

Step 4: Basic Server Setup

With SSH access and networking sorted, the remaining setup is standard Linux administration:

# Update packages sudo apt update && sudo apt upgrade -y # Install common tools sudo apt install -y python3-pip nginx git # Install Node.js (if needed) curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs # Set up a project directory mkdir -p ~/my-project && cd ~/my-project git clone https://github.com/yourusername/your-repo.git

For Python projects, I install dependencies directly (pip install --break-system-packages on newer Ubuntu) rather than setting up virtual environments for each project. For larger setups, virtual environments are cleaner but add management overhead.

Step 5: Keep Services Running with systemd

SSH sessions end. Processes started in a terminal die when you disconnect. Systemd solves this — it manages your services, restarts them if they crash, and starts them automatically after a server reboot.

# Create a service file sudo nano /etc/systemd/system/myapp.service # Contents: [Unit] Description=My Application After=network.target [Service] User=ubuntu WorkingDirectory=/home/ubuntu/my-project ExecStart=/usr/bin/python3 main.py Restart=always RestartSec=5 [Install] WantedBy=multi-user.target # Enable and start sudo systemctl daemon-reload sudo systemctl enable myapp sudo systemctl start myapp # Check status sudo systemctl status myapp

Restart=always means if your app crashes, systemd brings it back up after 5 seconds. I have six services running this way. The longest has been up for three months straight without manual intervention.

Step 6: Point a Domain at Your Instance

If you're using Cloudflare (covered in another guide in this series), add an A record pointing your domain to the Oracle instance's public IP address. Set the proxy status to "Proxied" so Cloudflare handles SSL. Set your Cloudflare SSL mode to "Flexible" — this means Cloudflare handles HTTPS for users while talking to your Oracle server over plain HTTP.

After DNS propagates (usually under an hour), your domain serves content from the Oracle instance with full HTTPS, CDN caching, and WAF protection. No SSL certificate to manage on the server side.

Common Problems and Fixes

"Out of capacity" during instance creation. ARM instances are popular. If your region is full, try a different availability domain, or try again during off-peak hours. Some regions have more capacity than others.

Instance not reachable after creation. 95% of the time this is the VCN security list (Step 3). Check there first before debugging anything else.

ARM compatibility issues. Most modern software runs on ARM. Occasionally you'll find a package or Docker image that's x86-only. The fix is usually finding an ARM build of the same package. I've hit this twice in three months — both times the alternative was easy to find.

Account idle reclamation. Oracle may reclaim Always Free instances that have been idle for extended periods. Running active services prevents this. If you're running production workloads, this won't be an issue.

More guides in this series cover the rest of the free stack — Cloudflare configuration, auto-deployment pipelines, and Claude Code workflows. If you're setting up Oracle Cloud for the first time and hit something not covered here, drop it in the comments.

Related guides in this series:

Disclaimer: This blog documents practical workflows based on personal experience. Nothing here is financial, legal, or professional advice.

Comments

Post a Comment