Allocus

One price. One box. Every side project.

Allocus gives you a single server of your own and lets you deploy as many dockerized apps to it as you like. You pay per developer, not per app — so your tenth throwaway idea costs exactly what your first one did.

Every app goes live at https://<app>.<you>.allocus.dev with HTTPS already working. No server to configure, no SSH key to look after, no per-app bill.

• Ship your first app Sign in, install one thing, deploy. About five minutes.

• Something's broken 502s, restart loops, deploys that don't finish — by symptom.

• Your data Where it lives, who can read it, and what isn't backed up.

• Apps with a database Frontend + backend + Postgres, deployed and rolled back as one unit.

• When to size up Reading the meters, and what a resize actually costs you.

• Billing and leaving Plan changes, failed payments, cancelling, getting your data out.

The mental model

Four things, and if you hold them you'll never be surprised:

• You get one box. A real virtual machine, a fixed size, yours alone. Not a slice of a shared cluster.
• Apps are just containers. Each one is a Docker image running on your box, routed by hostname. Deploy as many as fit.
• Overloading it is your problem — deliberately. Cram twenty apps on and it gets slow. There are no per-app quotas to fight, because there is nobody else on your box to protect. Slow is the only penalty; there is never a surprise bill.
• The box is disposable, and you should treat it that way. Its value is the running apps, and those redeploy from your git repo in a minute. Anything you would be upset to lose needs a backup you control — see Your data.

Two ways to deploy

Most people let Claude do it: open your repo and say "deploy this to allocus". The Allocus skill writes the Dockerfile and allocus.yaml if they're missing, then runs the deploy.

If you'd rather drive, the allocus CLI does the identical thing one command at a time — deploy by hand. Or put it in CI and deploy on every push to main — GitHub Actions.

There is no third, hidden path. Claude runs the same CLI you can run, and How it works traces the whole pipeline so none of it is a black box.

What Allocus is not

Worth knowing before you build something on it, rather than after:

• There is no uptime guarantee. No SLA. Allocus is run by one person on best effort. Boxes get restarted, deploys occasionally fail, outages will happen.
• Your box is not backed up for you. Snapshots exist on a best-effort basis and are not a service to rely on. There is no restore button and no point-in-time recovery. Keep your own backups.
• It is early software, and unaudited. Built carefully, but not independently reviewed by anyone.
• One box means one machine's worth of capacity. No autoscaling, no multi-region, no failover. When you outgrow that, you have outgrown Allocus, and that's a fine place to end up.

Anything that must not go down should not depend on Allocus alone. That's stated in the Terms too, but it belongs here where you'll actually read it.

Where the fine print lives

Page	What it's for
Terms of Service	The contract, including what you may not run and the data processing agreement.
Privacy Policy	Every row of data Allocus holds about you, and why.
Abuse and illegal content	How to report something, and what happens if something of yours is reported.
Service notices	The public record of incidents, price changes and Terms changes.

The rules, in practice is the plain-language version of all four: what you may run, and what happens if someone complains about something of yours.