Small internal apps, behind company sign-in, on one server

An agent can write an internal tool in an afternoon: a small server, a SQLite file, a call to some API. Then come the questions the code does not answer. Where does it run? Who can open it? Where does the API key live? Who restarts it, and is its data backed up?

sitesolide answers them once. It is an MIT-licensed CLI and a few small services that turn one Debian server you own into the place those tools run: each at its own HTTPS subdomain, behind your company's sign-in when you want it, with its secrets on the server and its data snapshotted every hour. Y Combinator's request for startups A Cloud for Small Software describes the same problem: such tools are now easy to build, and still hard to deploy and share.

How it works

A project is a folder. sitesolide deploy generates a systemd unit and a Caddy block from its sitesolide.json, and --dry-run shows both before anything changes. Each project runs as its own system account, sees only its own files, cannot reach another project's port, and has no network beyond the loopback unless its manifest asks for it. There are no containers.

Each app is Public, Restricted, or opened with a code, like a shared document. Restricted puts a sign-in portal in front: Google Workspace, Microsoft Entra, Okta or any OpenID Connect provider. You give a person access by email with a role, or let a whole domain open the app, and the app learns who came in from headers it can trust. On the managed platforms I looked at, your own identity provider in front of an app is an enterprise feature; here it is in the MIT code.

Built for agents, without giving them root

Every command takes --json and ends with one result, or one error with a hint for the next step, and an MCP server exposes the same commands. Colleagues and agents deploy with personal tokens, scoped to projects, revocable, and never stronger than their holder's role. Only the owner holds SSH, and a token can write a secret but never read one back.

How I checked it

On 19 October I ran an adversarial review with Claude Code: ten agents each attacked one component, a finding counted only with a test that failed first, a second round attacked the fixes, and the release then went onto a fresh Debian VM. More than thirty holes were fixed in v0.6.0 and v0.6.1, among them an app able to read every preview code, and an app able to take the portal's port while the portal restarted. It is not a third-party audit. The threat model is in Who may touch what, and SECURITY.md says how to report a hole.

What it does not do

It is one machine: no failover, and what breaks it breaks every site. A deploy restarts the app in place, so visitors may see a 502 for a moment, and there is no automatic rollback. Backups stay on the server until you give them a bucket. It runs on Debian 13 only, automates DNS on Cloudflare only, and has one author. My own machine runs 18 projects on 4 vCPU and 8 GB of memory, and uses 1.5 GB of it.

Try it

curl -fsSL https://github.com/cthiriet/sitesolide/releases/latest/download/install.sh | sh
sitesolide setup root@203.0.113.10 --zone example.com --email you@example.com
cd your-project && sitesolide deploy

You need a domain on Cloudflare, and a Debian 13 machine you reach as root or a Hetzner token for sitesolide machine create. The code and the docs are on GitHub. Tell me where the threat model is wrong.