Every multiplier traces to a mechanism
Not adjectives — line items. Each claim below names the machinery that produces it, so you can check it rather than believe it.
Scale to billions
Every person gets their own instance with its own database. A crash, a leak or a runaway query takes down one person's process; the next request restarts it and nobody else notices. Growing means adding boxes to the fleet, not architecture to your app.
mechanism: per-person instances · blast radius of one · add boxes, not architecture
Build faster
AI is the factory. Extravagant machines are spent at build time — at length, under tests that fail the build — to produce one lean artifact. The compute is spent once, at the factory; what ships stays small forever.
mechanism: extravagant machines in · one lean artifact out
Query without a network hop
SQLite is compiled into the process, so a query is a function call and your data lives next to your compute: microseconds where a round trip costs milliseconds. Even a sleeping instance wakes in milliseconds.
mechanism: a query is a function call, not a round trip
Cheaper, and more efficient with it
Most software is used a few hours a week and billed for all 168. On CARLOS an idle app hibernates to object storage — a few objects in a bucket, no process, no memory, costing nothing — and wakes on the next request. Less compute standing idle is also less energy burned for nothing.
mechanism: pay for the hours used, not all 168
From branch to live, without a rebuild
One artifact, one pointer by default. What you tested is what ships, because it is the same bytes.
A live URL for every branch
Push a branch and get a canary URL in seconds: a real deployment on the real platform, not a localhost preview. Send it to a teammate before the code review starts.
One command to serving
carlos deploy ships, promotes, and returns only when the URL is provably serving the new build — the edge names the version it serves and the command checks. Exit 0 means refresh and it is there.
A staged pipeline is one command, opt-in
carlos pipeline init --template edge-production gives an app more channels, each with its own bake window and approval rules; --template full-ladder is the old fixed canary → edge → beta → stable ladder, still there for anyone who wants it. Either way, promotion only ever points an existing channel at bytes you already shipped — nothing is rebuilt to get there.
Rollback is a pointer move
Point the channel back at the previous release and the bleed stops. Immediate, no rebuild, no waiting. Going backwards is never new code.
Safe to deploy, and safe to be deployed to
The default is live the moment you ship — the platform's job is to make that boring. Want a frightening step to guard against instead, on your own terms? That's a pipeline you opt into, not one you're stuck with.
A bake window, when you ask for one
Give a channel --bake 72h and a new release must sit on it for that long before the channel's instances adopt it, so a compromised publisher cannot rush a poisoned build across your fleet. Deploys to an app's default edge channel carry no bake — they're live as soon as the header proves it — and canary channels never do either; the window is something you add per channel, through carlos pipeline.
Rollback always skips the bake: pointing back at a hash that already served traffic takes effect immediately.
Residency, enforced below your code
Declare where your data lives — per app, or per customer instance — and a host outside that region will never claim it. There is no "just this once during a failover" path: no eligible host means the wake fails loudly instead of quietly relocating.
Sleeping data rests in region-scoped buckets too, so residency covers rest as well as execution. Enforced by the platform, not promised in a policy PDF.
Placement follows declared trust, not just capacity
Each workload publishes what a host can learn by running it, and the platform will not place it somewhere less trusted than that declaration requires. The classes are on the framework page.
When it breaks, it says why
carlos logs is one timeline: your app's own output merged with the platform's events about it — wakes, restarts, and the reason a wake failed — filterable, followable live with -f, and in the console. No server access required, because the answer comes to you.
Recurring work, on an app that sleeps
A hibernating instance cannot run its own timer — the process is not there to fire it. So the platform keeps the clock. carlos schedule set declares the work once, -every 6h or a cron line in UTC, and at the due time the platform wakes the instance, POSTs the path you named with the token already in its environment, and holds it awake until your handler returns. A sync every six hours; reminders in the days before a date.
2xx means done, 5xx is retried with backoff, 4xx is your app declining and nothing retries. carlos schedule ls prints the next and last fire for every instance, so "did it run?" is a question you answer from your terminal.
The whole platform is
That heading is not a lead-in to a longer list. It is the list.
No proprietary control plane, no license server, no essential piece that exists only in someone else's account. Run it on our cloud because it is convenient. If you ever want to leave: copy the binary, take your bucket, point your DNS, and walk away with everything still running.
Real companies, real traffic
Production tenants are live today — an event-ticketing company and a training platform among them — and the framework page lists what was answering when this site was last deployed.
Apps live at <sqid>.oncarlos.com, an address that never encodes region or host, so placement stays invisible; custom domains ride on top as aliases.
Ship something this afternoon
A canary URL is seconds away — on your boxes or on ours.