How to run an always-on agent in the cloud: free tiers, a cheap VPS or a hosted runtime

The options side by side

Which one I would pick for which job

I sort by one question: what happens if the machine disappears at 3am? For an experiment, nothing happens, I shrug and rebuild. For the thing that posts to my channel or reads my inbox, I want it on a box nobody can take away for being quiet. That rules the free tiers out for anything I rely on, because both Oracle and Google reserve the right to treat an idle agent as waste, and an always-on agent is idle almost all the time by design.

• Learning and experiments: a free tier. Oracle's Arm VM is the most capable free machine on the internet when you can get one. Google's e2-micro is smaller but I have never heard of it being reclaimed.
• Anything you rely on: a four-to-six-dollar VPS. Boring, yours, and the Linux core guide in this series applies to it line for line.
• Code-shaped jobs (review pull requests, groom a backlog, open a nightly PR): a hosted runtime. You never patch a machine, and the vendor keeps it on for you.
• Something that already lives in a repository: GitHub Actions on a cron, as long as you can live with a run starting late at the top of the hour.

The free tiers, read from the providers' own pages

Oracle Cloud

Oracle's documentation says every tenancy gets the first 1,500 OCPU hours and 9,000 GB hours per month free on the VM.Standard.A1.Flex Arm shape, which for an Always Free tenancy is equivalent to 2 OCPUs and 12 GB of memory. Older guides still quote 4 OCPUs and 24 GB; the page I read on 20 October says 2 and 12, and I would plan on that. You also get up to two VM.Standard.E2.1.Micro AMD instances, 200 GB of block storage across boot and block volumes, and 10 TB of outbound data a month.

The clause I would read twice is reclamation. Oracle may reclaim an Always Free compute instance it deems idle, and it deems one idle when, over a seven-day period, CPU utilisation at the 95th percentile is under 20 percent, network utilisation is under 20 percent, and, on the Arm shapes, memory utilisation is under 20 percent. A well-behaved agent that wakes hourly, does a minute of work and sleeps fits that description perfectly. I have not run an agent on Oracle's free tier myself; I have read the terms, and that is the one that would bite me.

Google Cloud

Google's Free Tier page lists one non-preemptible e2-micro VM instance per month in one of three US regions, Oregon (us-west1), Iowa (us-central1) or South Carolina (us-east1), with 30 GB-months of standard persistent disk and 1 GB of outbound data from North America. The allowance is counted in hours, so one machine running all month is free and two for half a month is the same thing. GPUs and TPUs are excluded. The page does not list an external IP address in the free allowance, so I would budget for one rather than assume it is included.

The e2-micro is a shared-core machine. It will run a Python agent that calls an API. It will not run a local model of any size you would want to talk to.

AWS

AWS no longer offers twelve free months of a small instance to a new account. Its Free Tier page now describes credits: $100 when you sign up, and up to $100 more for using key services, to a maximum of $200. The account closes on its own six months after you open it or when the credits run out, whichever comes first, unless you move to a paid plan. Thirty-odd services remain always free within monthly limits on both plans. For a learning project that is generous; for an agent I want running in a year, it is a countdown.

A four-dollar server is the honest default

DigitalOcean's cheapest Droplet, as listed on its pricing page when I read it, is one vCPU, 512 MiB of memory, 10 GiB of SSD and 500 GiB of transfer for $4 a month. Hetzner's cheapest shared plans start from about six euros a month before VAT, with the lowest line showing as temporarily unavailable when I looked. Either is enough for an agent that talks to an API, keeps a small SQLite memory and sends you messages. Neither is enough for a local model; for that you want the Arm free tier, a bigger VPS, or your own hardware, and the local-models post later in this series goes into what actually fits.

What you are buying for the four dollars is not compute. It is the absence of a reclaim clause, a public IP that does not change, and the right to be idle. That is the whole product.

Hosted runtimes: when you do not want a machine at all

Three options keep the machine on for you. I use the first one for code chores and I find the mental model of all three worth knowing even if you run your own box.

Claude Code scheduled tasks, until recently called routines, are a saved Claude Code configuration (a prompt, one or more repositories, a set of connectors) that runs in Anthropic's cloud, or in your organisation's self-hosted environment. A task can have three kinds of trigger: a schedule, an API endpoint you POST to with a bearer token, and GitHub events such as a pull request opening. The documentation marks the feature a research preview, lists it on Pro, Max, Team and Enterprise plans, and sets the minimum interval at one hour, with on-the-hour runs liable to start several minutes late. Repositories are cloned from GitHub on every run, and if your GitHub connection lapses the task skips runs for up to 72 hours before turning itself off. Runs draw on your subscription usage like an interactive session.

Claude Managed Agents gained scheduled deployments on 9 June 2026: an agent that starts a new session on a cron schedule, with no scheduler for you to build or host, that can be paused, resumed or archived, and the examples Anthropic gives are nightly data syncs, weekly compliance scans and daily digests. This is the API-side product, for teams building agents into their own systems rather than for a personal assistant.

GitHub Actions has run on a schedule for years. The docs say the shortest interval is once every five minutes, scheduled workflows run only on the default branch, the event can be delayed during periods of high load, which includes the start of every hour, and in a public repository scheduled workflows are automatically disabled after 60 days without repository activity. I would pick an odd minute, keep the repository private or active, and treat a run as something that happens roughly on time rather than exactly.

Set it up, step by step

These are the steps for the VPS and free-tier routes, which end on a Linux box. I keep them deliberately short, because the Linux core guide in this series, which goes up on 28 October, takes over at the point where you have a shell and an agent user.

1. Pick from the table, then pick Arm if it is offered. Oracle's free machines are Arm, Hetzner's cheapest line is Arm, and every open-source agent I cover in this series runs on Arm. Pick a current Ubuntu LTS or Debian image unless a later distro guide gives you a reason not to.
2. Create the machine with an SSH key, never a password. Every provider's console will take a public key at creation time. Make one with ssh-keygen -t ed25519 if you do not have one, and paste the .pub.
3. Log in once as root or the default user and update everything. On Ubuntu and Debian that is sudo apt update && sudo apt upgrade -y. Reboot if the kernel changed. Do this before the agent exists so you know the box is quiet when idle.
4. Create the agent's own user. The agent never runs as root and never runs as you. sudo adduser --disabled-password --gecos '' agent gives it a home and no login password.
5. Close the firewall to everything but SSH. An always-on agent should make outbound calls and accept nothing inbound unless you have a reason. On Ubuntu: sudo ufw allow OpenSSH && sudo ufw enable. Cloud consoles have their own firewall too; close that one as well.
6. Give the agent an identity that is not yours. An API key with a spending cap, or a cloud service account with the narrowest role that works, stored in a root-owned file the service reads. Every job I run unattended does this, and the reason is below.
7. Install the agent and hand off to the Linux guide. Whichever project you chose, the pattern is the same from here: a dedicated user, a systemd service that restarts on failure, a timer for scheduled work, secrets outside the unit file, and a heartbeat somebody watches. The series page lists the Linux guides as they go live.
8. Set a billing alert before you walk away. Even on a free tier. The reason free tiers have asterisks is that something adjacent to the free thing is not free, and you want an email, not a surprise.

First login on a fresh Ubuntu or Debian boxsudo apt update && sudo apt upgrade -y
sudo adduser --disabled-password --gecos '' agent
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

What our own cloud taught me

Leo's backend runs on Google Cloud Run with a minimum of two instances in front of a Postgres database, and the website you are reading is a Cloud Storage bucket behind Cloud CDN. Neither of those is a VM, and I chose them so that I would never have to patch a machine. Two lessons from running that carry straight over to a cloud agent.

First, identity. The login I use on my own laptop expires, and a token that expires cannot refresh itself at 3am without a human. I learned that the hard way when an unattended job failed with an authentication error nobody was awake to see. Now every job that runs without me, on the Mac and in the cloud, pins a service account with exactly the permissions it needs: write to one bucket, flush one cache, read one secret. If you take one setup step seriously, take that one. The post on permissions in this series is the longer version.

Second, what a health check actually measures. A Cloud Run deploy of ours once failed with startup probes timed out after 4m, and I spent an evening convinced the code was broken. It was not. Two instances were starting at once, both tried to run the same database migration, one waited on the other's lock, and the probe's failure threshold was set to one, so a single slow answer was treated as death and the instance was restarted into the same contention. The fix was a more patient probe and a migration that takes its lock honestly. The lesson for an agent host is the same: a restart policy that fires too eagerly turns a slow start into a loop. Give your service a RestartSec and a start-up grace period before you call it dead.

The cloud is a fine place for an always-on agent. Just remember that the machine is the least of it. The identity, the restart policy and the thing that tells you when it is silent are what you are really setting up, and those are the same on a free Arm VM, a four-dollar droplet, or the laptop under my desk. If you would rather see the agent I run for social video than build one, it is here, and the rest of this series is on one page.

Sources

1. Oracle Cloud Infrastructure documentation, Always Free resources (accessed October 20, 2026)
2. Google Cloud documentation, Free cloud features and trial offer (accessed October 20, 2026)
3. Amazon Web Services, AWS Free Tier (accessed October 20, 2026)
4. Claude Code documentation, Automate work with scheduled tasks (accessed October 20, 2026)
5. Anthropic, New in Claude Managed Agents: run agents on a schedule and store environment variables in vaults (accessed October 20, 2026)
6. GitHub Docs, Events that trigger workflows: schedule (accessed October 20, 2026)
7. DigitalOcean, Droplet pricing (accessed October 20, 2026)
8. Hetzner, Cloud pricing (accessed October 20, 2026)

Written by Lera Leonteva. Prices and allowances are as published on the access date; providers change them without notice.