Deploy and Host Oracle Cloud ARM Catcher on Railway

Oracle Cloud's Always Free tier includes one of the best deals in cloud computing — a 4-OCPU, 24 GB RAM Ampere A1 ARM instance, free forever. The catch: in popular regions the console almost always returns "Out of host capacity", because demand outstrips the free pool. This template runs a patient retry worker that calls Oracle's official instance-launch API on a sensible interval and grabs a slot the moment one opens — so you don't sit clicking the console for days.

It does exactly what you'd do by hand, just patiently and on a timer. No exploit, no bypass.

What This Template Deploys

A single lightweight service. It holds no database — it reads your OCI credentials, attempts an instance launch on each cycle, and notifies you (optionally via Telegram) when it catches one.

About Hosting

The whole trick with Oracle's free ARM tier is persistence: capacity frees up unpredictably, so the answer is to keep asking, politely, until a slot appears. Running that from your laptop means leaving it on for days; running it on Railway means it works while your machine is off.

The interval matters — this is automation, not hammering. The worker retries on a sensible cadence (default every 5 minutes), not in a tight loop. That distinction is the whole difference between reasonable use of Oracle's API and abuse: a tight while true loop hammers Oracle's endpoint, risks rate-limit blocks, and is the kind of thing that gets a free-tier account flagged. This template retries on a timer and, critically, stops on hard errors — an authentication failure, a bad subnet OCID, a wrong image, or a TooManyRequests response means the worker halts and notifies you rather than retrying a broken request forever. Only "out of capacity" triggers a retry.

Delete the service once you've caught an instance. There's no reason to keep the worker running after success — tearing it down stops further API calls and removes your credentials from Railway. The notifications prompt this.

Your OCI credentials are sensitive. The worker needs your tenancy OCID, user OCID, key fingerprint, and API private key to call Oracle on your behalf — your own credentials on your own instance, but set them as Railway variables, never commit them, and remove the service when done.

Typical cost: ~$5/month or less on Railway while the catcher runs — usually just days until it succeeds. The instance it catches is free forever on Oracle's side.

How It Compares

Clicking the console by hand works but wastes days. Local and Cloud Shell scripts work but need your machine on or a session that expires. An always-on Railway worker on a polite interval is the hands-off version — deploy it, get notified when it lands a slot, then tear it down.

Deploy in Under 5 Minutes

1. In Oracle Cloud, create an API signing key and note your tenancy OCID, user OCID, fingerprint, and region
2. Click Deploy on Railway and set those as variables, plus the target availability domain and free-tier shape
3. Set REQUEST_WAIT_TIME_SECS (default 300 — five minutes; don't set it aggressively low)
4. Optionally add TELEGRAM_TOKEN and TELEGRAM_USER_ID for success and error notifications
5. Deploy — the worker starts trying, and pings you when it catches an instance

Once you get the success notification, delete the Railway service.

Common Use Cases

• Land a free 4-core / 24 GB ARM VM — catch the Always Free Ampere A1 instance that the console keeps refusing
• Hands-off capacity waiting — let a worker handle the retry loop while your computer is off, instead of babysitting the console
• AMD micro instances too — the same approach catches the smaller Always Free AMD shapes where those are contended
• Notified provisioning — get a Telegram ping the moment a slot is caught, so you can log in and configure it

Configuration

Keep REQUEST_WAIT_TIME_SECS sensible. A five-minute interval is patient and reasonable. Setting it very low hammers Oracle's API and risks rate-limit blocks — with no benefit, since capacity doesn't open faster because you asked more often.

Your OCI private key is a secret. Set it as a Railway variable, never commit it, and delete the service once you've caught an instance so the credentials don't linger.

Dependencies for Oracle Cloud ARM Catcher Hosting

• Railway account — a few dollars for the days the worker runs
• An Oracle Cloud Always Free account with an API signing key created
• An existing VCN and subnet in your target region
• Optional: a Telegram bot for notifications

Deployment Dependencies

• Oracle Cloud Free Tier
• OCI API Key Setup
• OCI Compute Instance Launch API
• Railway Variables Documentation

Implementation Details

The worker calls Oracle's official LaunchInstance API — the exact operation the console runs when you click "Create" — on a configurable interval, attempting the specified free-tier shape in the configured availability domain. An "out of capacity" response is expected and triggers wait-and-retry; any other error (auth failure, invalid subnet or image OCID, limit exceeded, too many requests) halts the worker and notifies you, so a misconfigured run fails fast instead of retrying a broken request indefinitely.

The default REQUEST_WAIT_TIME_SECS of 300 keeps request volume low and well within reasonable use of Oracle's API. Credentials are read from environment variables at runtime; nothing is persisted. On success the worker reports the new instance's OCID and stops, at which point the Railway service should be deleted.

This template automates a legitimate, tedious manual task. It does not bypass Oracle's limits or exceed your free-tier allowance — it asks the same question the console asks, patiently, until the answer is yes.

Frequently Asked Questions

Is this against Oracle's terms? It uses Oracle's official API to do exactly what the console does — request a free-tier instance you're entitled to. The key is doing it politely: a sensible retry interval, not a tight loop. Aggressive hammering is what risks trouble, which is why the default interval is five minutes and the worker stops on real errors.

How long until it catches an instance? Unpredictable — capacity frees up at random. It can be hours or days depending on region and demand. That's exactly why running it hands-off on Railway beats clicking the console yourself.

Why five minutes between tries? Capacity doesn't open faster because you ask more often, so a low interval only hammers Oracle's API for no benefit and risks rate-limit blocks. Five minutes is patient and reasonable.

What happens on a config error? The worker stops and notifies you rather than retrying forever. A wrong subnet OCID, bad image, or auth failure fails fast — which is how you find out something's misconfigured instead of "trying" broken requests for days.

Is my OCI private key safe? It's your own credential on your own instance, set as a Railway variable. Treat it as a secret — don't commit it, and remove the service when done.

Which shapes can it catch? Primarily the Always Free ARM Ampere A1 (4 OCPU / 24 GB), and the smaller Always Free AMD shapes where those are contended. Set OCI_COMPUTE_SHAPE accordingly.

Why Deploy Oracle Cloud ARM Catcher on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying the ARM Catcher on Railway you get a hands-off way to land Oracle's excellent free-tier instance — a patient worker on a sensible interval, optional notifications, and no need to keep your own machine running. Deploy it, wait for the ping, claim your free ARM server, and tear the worker down.