Small apps don't need to scale. They need a machine and a disk.
Open source projects that already ship a single binary. One click to deploy:
| App | What you get |
|---|---|
| PocketBase | A database, auth, file storage and an admin UI, in one file. |
| Sharkord | A self-hosted chat server with voice, video and screen sharing. |
| Boop | A self-hosted notification inbox for your own apps. |
| Gitea | A self-hosted Git service with repositories, issues, pull requests, packages and CI. |
| OpenConnector | One OAuth hub for 1,000+ providers, with prebuilt actions your agents can call. |
| Context Use | A personal knowledge base your agents read and write over MCP, behind a passkey. |
A compiled binary is already a whole application in one file. Whatever language produced it, nothing has to be installed on the other side. The only two things it still needs are somewhere to run and somewhere to read and write files.
For an app that five people use, most of the rest is ceremony:
| What it usually gets | What it actually needs |
|---|---|
| ❌ |
✅ A machine to run on |
| ❌ |
✅ A disk to write to |
| ❌ |
|
| ❌ |
|
| ❌ |
|
| ❌ |
|
| ❌ |
|
| ❌ |
nibrun is those two things and nothing else: a Firecracker microVM of its own (1 vCPU, 256 MiB)
and a data/ directory that survives every redeploy. It answers on an HTTPS subdomain the moment
it boots, sleeps after five minutes idle, and wakes on the next request in ~120 ms.
If your app needs to be more than one machine, it has outgrown this — and that is not a roadmap, it is the design.
Create an HTTP app (use the bun-full-stack-starter template) and compile it to a single Linux x86_64 binary. Then deploy it:
Prepare the app and deploy it to nibrun using the deploy-to-nibrun skill.
Install it using:
npx skills add ilbertt/nibrunUse the dashboard
Drag and drop the binary onto app.nibrun.com.
Use the CLI
curl -fsSL https://nibrun.com/install.sh | shnib run ./my-servernib apps export .
tar -xzf my-app.tar.gz
./my-serverThe same binary you uploaded, the same bytes that were on the disk, and a .env of the variables
it was deployed with. There is no managed database to migrate off, because there never was one.
