Dev.to AI 🤖 Ai 👁 0 📖 3 min read

Oracle Cloud free tier: the always-free ARM instance

Yes, Oracle Cloud's always-free tier really does include a permanently free ARM instance — I run a meaningful part of my agent infrastructure on one. The catch people miss is not the price, it is the availability and the

Yes, Oracle Cloud's always-free tier really does include a permanently free ARM instance — I run a meaningful part of my agent infrastructure on one. The catch people miss is not the price, it is the availability and the mindset. The free-tier ARM instance hosts agent services and a long-running site in my stack, and it has been genuinely useful. But I treat it as a nearly-free compute resource with a recall clause, not as a permanent home for anything I cannot afford to lose.

What the always-free tier gives you

Oracle Cloud's free tier covers a small set of always-free resources, distinct from the temporary trial credit you start with. The part that stands out for people running agents is the ARM instance: it is always-free rather than a time-boxed trial, which means you can leave a service running on it indefinitely without it expiring. For an always-on workload — an agent service that needs to answer around the clock, or a site that is expected to stay up — that long-running nature is the whole point. A time-limited free trial that vanishes after a month is useless for a service; an always-free instance is a different category of thing entirely.

I deliberately keep the platform's monitoring agents on it as well. Some installations strip those out to save resources or reduce noise, but I leave them in place. They are the console's eyes — the signal I rely on to notice when something on the instance stops behaving. On a free resource with no support contract to call, that visibility matters more than the modest overhead it costs.

Where I use it, and where I do not

Generic terms here, because the specifics matter less than the lesson. The ARM instance runs agent services and a long-running site in my infrastructure. It handles sustained, always-on work that does not need the headroom of my paid hardware. That split is deliberate: free-tier compute is excellent for workloads that are steady and predictable, and awkward for anything that suddenly needs a burst of cycles.

What I do not do is treat it as my only copy of anything. If a service on the free tier dies, I want the recovery to be a re-provision and a restore, not a reconstruction. That is the discipline the free-tier stack post lays out, and it applies here more than anywhere.

The caveat that changes the design

The honest caveat: instance availability on the free tier can be reclaimed. Oracle can take an always-free instance back, and when it does, the instance is gone — you do not get a negotiation, you get a notice. I have not been bitten, but I design as if I will be. That constraint is what forces the important habit: keep state somewhere else.

The principle is simple. The instance is a cattle resource, not a pet. Its job is to run the compute. The data it produces and the state its services depend on live elsewhere, backed up and recoverable. That way, if the instance is reclaimed, it is an inconvenience — a re-provision, a restore, a few hours of my time — not a disaster where I lose the accumulated state my agents depend on. My agent memory layer and its vector store live outside the free instance for exactly this reason.

The mental model

The always-free ARM instance is real, capable compute at zero monthly cost, and that makes it easy to over-trust it. The useful frame is: free compute, guaranteed only until it is not. Run the always-on services on it, keep the platform's monitoring eyes attached, and keep everything that matters recoverable somewhere that a reclaim cannot touch. Done that way, it is one of the best cost-per-mileage pieces of my whole stack. Done the other way, it is a single point of failure wrapped in a great price.

What would you be willing to re-provision from scratch in exchange for a permanently free ARM instance?

Originally published at agentjournal.dev.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.