Why Zerolith: going live without becoming a sysadmin

Every other article on this blog is a tutorial. This one is the first we wrote, and it does something else: it says why the platform exists, what we won't do, and what we'd like to add next.

The problem we're trying to solve

Putting a small application online takes skills that have nothing to do with the ones you used to write it.

Broadly there are two options, and neither really suits a small project.

The first is a machine of your own, a VPS for a few euros a month. You install it, patch it, watch it, deal with the certificate, the firewall, the backups, and six months later try to remember what you rigged together. The bill is predictable, granted. But the work never stops, and all of it lands on someone who only wanted their code to answer a URL.

The second is a big cloud provider. Technically nothing is missing. Except that the console assumes a specialist, you have to swallow three dozen concepts before deploying anything at all, and above all the bill is open-ended: you hand over a card, and you find out what the month cost at the end of the month. A company with a finops team copes with that. An individual, a non-profit or a three-person startup copes with it much less well, and that's often the real reason the project never ships.

Something is missing in between: a place to put a piece of code that answers a URL, with nothing to administer, and whose cost can't exceed what you put on the account. That's what we're building.

Who it's for, and who it isn't for

We're aiming at small projects. The script you'd like to expose as an API, the webhook behind a contact form, the prototype you want to show three people before deciding it deserves better, the internal POC, a product's first version.

And mostly we're aiming at people who are neither infrastructure developers nor sysadmins. Someone who can write, or have written, thirty lines of Python, and who has no wish to learn Kubernetes to put them online. There's nothing to provision and nothing to size: your workspace is created on the first deploy, and it's walled off from the rest of the platform.

It isn't for everything, though. A steady, high-traffic workload will cost less on a machine rented by the month; that's arithmetic, and we write it on the pricing page rather than waiting for you to find out. A compiled binary, a service that keeps state in memory between requests, a process that has to run continuously: wrong tool. The right case is code that runs when it's called and doesn't exist the rest of the time.

A bill that can't run away

This is the part that matters most, and it's an architectural decision before it's a sales argument.

An account runs on prepaid credit. You top it up, usage draws it down, and at zero nothing starts. It isn't an alert, and it isn't a quota checked after the fact: the check happens at the network edge, before the request reaches anything at all. An unauthenticated call wakes no container, and neither does an account with nothing left on it. The balance can't go below zero, so there's no nasty surprise at the end of the month. There's no end-of-month invoice at all, in fact.

The rest follows from that. An idle function has no container alive, so it costs nothing. Execution time is counted to the second. The prices are unit prices and they're public: €0.000004 per GiB-second of reserved memory, €0.0000125 per vCPU-second, €0.0000004 per call.

One clarification we'd rather make ourselves, because you can't guess it: you don't pay for how long your calls take, you pay for how long the container lives. After the last call it stays up for roughly a minute and a half before it goes away. So the shape of the traffic matters as much as the volume. Five thousand calls arriving in bursts cost a few thousandths of a euro; the same five thousand spread out one by one, each on its own, cost under a euro. Either way you're a long way from a monthly subscription, and either way the ceiling is whatever credit is left on the account.

The credit we hand you at signup (€1, no card) covers a project that size for years. That's deliberate: we'd rather a prototype nobody cares about cost its author nothing than charge a monthly fee for an empty account.

The AI agent as the admin interface

A platform with no administration is still a platform with an API. Someone still has to turn "I want this script to answer a URL" into API calls, and that's exactly the kind of work an agent is good at.

So Zerolith runs a managed remote MCP server (Model Context Protocol), connected to your account over OAuth 2.1: no API key pasted into a config file, no secret sitting on disk. Any client that speaks MCP can connect, whether that's Claude or Claude Code, Codex, Cursor, VS Code, Zed, or the agent you wrote yourself. The agent then sees the same actions you do: write the function, deploy it, call it, read its logs and metrics, create a database, check what it's costing.

Nothing forces you through that door. The dashboard and the API do everything the agent does, and both paths lead to the same functions. But when you're neither a dev nor an ops engineer, the gap between reading API documentation and describing what you want is not a small one.

What we add, and on what test

The test fits in one question: does the absence of this piece force the user back into running a server? If it does, it belongs here. If it doesn't, it waits.

That reasoning is what produced the private database. A function is stateless, and without state half of all projects stop right there; there had to be somewhere to write. It's a SQLite-compatible database, private, in your own space, reachable only by your own functions, replicated to object storage, asleep when nobody queries it, and you can pull a full dump out of it whenever you want. The same reasoning produced cron triggers, write-only secrets, and custom domains with managed TLS certificates.

What we hope to add next

What follows is an intention, not a schedule. We publish it anyway, because when you pick a platform you're entitled to know which way it's heading.

• File storage. A function that needs to keep a file, an uploaded image, a generated PDF, a cache, only has the database for it today, and the database isn't built for that. A simple storage space attached to the account, the way the database already is, is the piece people ask us for most often.
• Uploading a whole bundle. Today you deploy code that leans on the libraries already in the language image. That's comfortable, and it stops you dead the moment you need a dependency that isn't there. Being able to upload an archive with your own dependencies would open up a language's whole ecosystem, without going back to per-user image builds.
• More languages. Python and Node.js today. The runtimes are built on a single minimal contract, a request goes in and a response comes out, which makes adding a language fairly mechanical.
• More European countries. The platform is hosted in France and we stand by that (see the security page). Being able to pick which region your functions run in, elsewhere in Europe, is the logical next step, for latency as much as for the regulatory constraints some projects carry.

None of those four has a date. Two already exist as drafts, two are still ideas. The order they ship in will depend on what people ask us for.

Tell us what you're missing

This is the most useful line in the article. We're a very small team, and we're building for projects that don't necessarily look like ours. The piece blocking you today is probably more important than the one we'd planned to write next week, but we have to hear about it first.

An idea, a need, a use case that doesn't fit, a price that doesn't work for you: write to contact@zerolith.io. We read all of it, and we answer.

And if you'd rather start with something concrete than with a statement of intent, the documentation gets a first function deployed in a few minutes, with enough credit on the account that you won't have to think about it.