In my last post about QuackBuilds, I mentioned almost in passing that the long-running half of my stack — schedulers, trading bots, AI pipelines that take longer than serverless function timeouts allow — runs on an Oracle Cloud ARM instance with Coolify on top. A few people asked about that part specifically, so this post is the deeper dive. It’s the corner of my stack that costs me literally nothing per month and quietly does the work that serverless can’t.
The setup makes sense if you’ve ever hit a wall that’s familiar to anyone who’s tried to build something that isn’t a CRUD app. Vercel functions time out. Cloudflare Workers have a CPU budget. Supabase Edge Functions are great until you need to keep a websocket open, run a polling loop, or hold model state in memory across requests. Once you cross into anything that resembles a daemon — anything that wakes up on a schedule, holds a connection, runs for minutes at a time, or maintains warm state — the serverless layer of your stack stops being able to help you, and you suddenly need a server. That gap is what Oracle Cloud’s Always Free tier fills, and what Coolify makes pleasant.
The Always Free tier itself is, on paper, almost too generous to be real. Oracle gives you up to four ARM Ampere A1 cores and 24GB of RAM, split however you want across instances, with 200GB of block storage, all permanently free. Not free for a year. Not free until they email you. Free indefinitely as long as the account stays active. The hardware is genuinely capable — the A1 cores are modern Ampere ARM chips, not the wheezing shared CPUs you sometimes get from “free tier” providers — and 24GB of RAM is enough to comfortably run several services simultaneously, including ones that hold model weights or large in-memory caches. The catch, and there is a real catch, is that Oracle has a reputation for reclaiming idle Always Free instances if they need the capacity for paying customers. In practice I have not had this happen, and the workaround if it ever did is straightforward, but it’s worth knowing going in.
On top of that bare instance, I run Coolify. If you haven’t come across it, the easiest description is “a self-hosted Heroku” — an open-source platform layer that gives you git-push-to-deploy, automatic Let’s Encrypt SSL, environment variable management, application logs, database provisioning, and a clean web UI that turns the Linux box into something you can actually manage at 11pm without remembering Docker incantations. Installing it is a one-line curl command. Once it’s up, deploying a new service is connecting a GitHub repo, picking a build pack, and clicking deploy. The DX is genuinely close to Heroku circa 2014, which is to say, the era when deploying a web app was actually fun.
The combination — Oracle Always Free ARM plus Coolify — is what lets me run the stuff serverless refuses to host. My Polymarket trading bot, which runs on a four-hour cycle and needs to maintain state between cycles, lives there. A scheduler that polls APIs and triggers workflows lives there. An AI pipeline that processes video in the background lives there. A handful of small services that exist purely because I wanted them to exist live there. None of these would work as serverless functions, all of them work fine on a single ARM instance, and the combined cost of running all of them is exactly zero dollars a month. The variable cost only kicks in for the apps that actually scale on Vercel and the database rows that actually get written to Supabase, both of which are usage-priced. The fixed-cost half of the stack — the part that would normally be a $7-or-more droplet on every other infrastructure provider — is free.
A few honest tradeoffs are worth naming, because I don’t want this to read like an ad. ARM compatibility is real but occasionally annoying. Most modern Docker images have ARM variants now, but you’ll occasionally hit a dependency that only ships x86 and have to find an alternative or build from source. Oracle’s web console is genuinely one of the worst enterprise UIs I’ve ever used, and the initial setup — getting the instance provisioned, networking configured, ports opened — is meaningfully harder than the equivalent flow on DigitalOcean or Hetzner. Once the instance exists and Coolify is running on it, you barely touch the Oracle console again, but the first hour is rough. Backups are your problem; Coolify can help, but you have to set it up. And the Always Free reclaim risk, while I haven’t personally experienced it, is real enough that you should treat the instance as cattle rather than pets — keep your configurations in git, your data in Supabase or somewhere you don’t host yourself, and make rebuilding the instance a thirty-minute exercise rather than a weekend project.
The architectural pattern this enables, and the reason I set it up this way for QuackBuilds, is what I think of as a three-tier stack with the cost curve flipped. The frontend tier is Vercel, where I pay for what I use and the free tier covers small projects entirely. The data tier is Supabase, same model. The compute tier — the part that would traditionally be the most expensive — is Oracle ARM with Coolify, where the fixed cost is zero and only my time is on the meter. For a catalog of small apps, where any individual app might never make money but the catalog as a whole eventually will, this cost shape is the only one that actually works. I can ship a new tool, let it run for a year while it finds its audience, and pay nothing to keep it alive. That’s not possible on a stack where the compute layer charges you whether anyone is using your app or not.
If you’ve been hitting the serverless wall and wondering where to put the things that don’t fit, this is what I’d suggest trying. The setup costs you an evening. The running cost is nothing. The ceiling is high enough that I haven’t come close to hitting it with several real services running concurrently, and if you do hit it, you’ve probably built something successful enough that paying for real infrastructure makes sense.
Next post in the series will be the Base payments integration — how I’m using onchain rails to do what Stripe does, but for sub-dollar payments and agent-to-agent flows. If there’s a different layer of the stack you’d want me to dig into instead, drop it in the comments and I’ll write that one first.
— @itsevilduck / quackbuilds.com