The cloud for small software

Most cloud infrastructure is built for software that has a team behind it. Autoscaling groups, service meshes, IAM policies, staging environments, an on-call rotation. That machinery exists because the software it serves is large, and large software needs it.

Then there is the other kind: the Discord bot for your community, the scraper that checks four sites every morning, the internal dashboard three colleagues use, the Telegram bot that pings you when a price moves, the Stripe webhook handler behind a product doing €900 a month, the agent that runs a long job overnight and reports back.

This is small software: one maintainer (usually the person who wrote it), idle most of the day, holding a bit of state that is often a single SQLite file, with no deploy process worth the name. And it needs to keep running, because a bot that is down is a bot that does nothing.

There is a lot more small software in the world than large software, and almost nothing in the cloud market is shaped for it.

What counts as small software

Not "unimportant" and not "unfinished." Small software is a shape, not a stage. Four things define it:

One person owns it. There is no platform team, no runbook, no second pair of eyes. Whatever it takes to operate, one person does in the time they have.

It is idle almost all the time. A cron job that runs for ninety seconds a day is busy for 0.06% of the month. A bot serving a 400-person Discord spends most of its life waiting on a socket. Duty cycle is the defining economic fact about this category, and almost every pricing model in the market ignores it.

It has state that matters. The SQLite file, the OAuth refresh token, the cache it took an hour to warm, the scraper's dedup set. Losing that is not a restart, it is a data loss event.

It has to stay up. Nobody is watching it. If it dies at 3am it should still be running at 9am, and if it cannot be, it should at least come back on its own.

Software that fits that description does not need Kubernetes. It needs a computer.

Why serverless mis-fits

The industry's default answer for the last decade has been "make it a function." For genuinely stateless request handlers, that answer is correct and this article is not arguing otherwise. For small software, three of the constraints bite immediately.

There is a clock on it. AWS Lambda stops a function at 900 seconds, fifteen minutes. Vercel Functions cap at 300 seconds on Hobby, with 800 seconds on Pro and 1800 in an extended beta. A scraper walking a paginated API, a video encode, an agent working through a task list: all of these routinely exceed those numbers, and none of them are doing anything exotic.

It forgets. Between invocations there is no disk you can count on. Lambda gives you a /tmp between 512 MB and 10 GB, and the next invocation may or may not be the same execution environment. So the SQLite file becomes managed Postgres, the cache becomes Redis, and a program that was 200 lines and one file is now three billed services and a connection string.

The scheduler has opinions. The free cron most people reach for is GitHub Actions, and its schedule event runs at most once every five minutes. In a public repository, scheduled workflows are disabled automatically after 60 days with no repository activity. A job that quietly stops after two months is worse than a job that never ran, because you believed it was running.

None of this is a design flaw. Serverless was built for spiky, stateless, short request handling and it is very good at that. Small software is long, stateful and slow, which is the opposite set of assumptions.

Why a plain VPS mis-fits too

The other answer is to rent a Linux box, and it is a much better answer. The box does not time out, it has a disk, and the program you wrote runs unchanged. Two things go wrong.

You pay by the hour for something that works by the minute. As of 30 July 2026, a DigitalOcean Basic droplet is $6/month for 1 vCPU, 1 GB of RAM and 25 GB of disk. Hetzner is cheaper, at €5.49/month for a CX23 with 2 vCPU and 4 GB since the 15 June 2026 adjustment. Neither is expensive for one machine. But small software does not come in ones. By the time you have the bot, the scraper, the dashboard and the two half-finished things you would rather not colocate, you are running five boxes and paying full freight on all five for work that adds up to an hour of real compute a week.

You become the sysadmin. Unattended upgrades, a firewall, TLS certificates and their renewal, a reverse proxy, systemd units, log rotation, and the backup you keep meaning to test. Every one of these is fine on its own. Together they are the reason people put a bot on a laptop under the desk instead.

The usual response to the second problem is a self-hosted platform layer such as Coolify, which is free to self-host and does a genuinely good job of turning a VPS into something Heroku-shaped. It does not touch the first problem. You are still renting the machine around the clock.

What small software actually needs

Stripping the workload back to its requirements gives five, and they are worth stating plainly because they cut across every vendor's marketing:

1. It stays running. No wall-clock limit, no reaping between requests, no re-entering a cold process every time something happens.
2. It keeps its disk. A real filesystem that is still there tomorrow, so SQLite, a cache directory and a credentials file are all viable choices again.
3. It has a stable address. A hostname with TLS that a webhook, a bot API or a browser can reach without a tunnel you have to babysit.
4. It costs close to nothing while idle. The workload is idle by nature. Any pricing model that ignores duty cycle is charging for absence.
5. One person can run it. Setup measured in minutes, not an afternoon, and no ongoing operational tax.

Laid against the three common answers, the gap is easy to see. Every limit in the table below is as of 30 July 2026 and comes from the vendor's own documentation, linked where it is first cited:

Serverless fails the first two. A VPS fails the last two. That gap is the whole category.

What we built

boxd is a real Linux machine you reach over SSH, shaped around exactly that gap. Ten of them are €20/month, and each one is a KVM virtual machine with 2 vCPU, 8 GB RAM, 100 GB of persistent disk, its own kernel and an automatic <name>.boxd.sh HTTPS URL.

boxd machine new pricebot
ssh -t boxd.sh connect pricebot
# you are root on a full Ubuntu 24.04 machine

Three things about that machine matter for small software specifically.

Idle machines suspend and cost nothing to keep. A boxd that stops receiving traffic freezes in place and resumes in under a millisecond when the next connection arrives. The process it was running is still there afterwards, along with its memory. This is what makes ten machines a sane thing to own: the nine that are asleep are not consuming anything, so the price is a flat subscription rather than nine times a droplet.

Everything on the disk survives. Packages you installed, the SQLite file, the systemd unit you wrote, the tokens in ~/.config. It is an ordinary machine, so the ordinary answers work.

It is one machine per thing. Ten of them at €20/month works out to €2 a machine, which is less than any per-instance VPS price we know of for that spec. To be straight about it: that figure only holds if you actually run ten. One machine on the individual plan still costs €20/month, and every machine is the same fixed size. If you need one big box rather than ten small ones, Hetzner is a better deal and we would tell you so.

Isolation is worth a line too. Each machine is a KVM virtual machine with its own kernel, not a container sharing the host's. Running the scrappy scraper and the thing that holds your Stripe key on separate machines is a real boundary, not a namespace.

Where to go from here

Three companion pieces go deeper on the specific job you probably arrived with:

• You want to run the software, not write it. Where to actually run your self-hosted apps compares the four real homes for a self-hosted stack, including the home server.
• Your app used to live on a PaaS. Heroku alternatives for small apps sorts the options by shape, and is honest about when a deploy target beats a machine.
• You have a script that needs to keep running. How to run a script 24/7 without paying for 24/7 is the practical version, cron and bots and scrapers included.

The category needs a name, so here is the one we use. Small software is not a smaller version of large software, and it does not want a smaller version of the same infrastructure. What it wants is a computer that stays where you put it and costs little while it waits, without asking you to become an operations team to keep a bot alive.

SSH in and see whether that is what you have been missing.

Last verified: 2026-07-30. Prices and platform limits change; send corrections to hello@boxd.sh.