Hosting on one box

Day to day

What the panel does

Add a site domain + image: Name the domain and choose an image. The panel creates the container, scaffolds the folder, and publishes the route.
Or bring your own custom stack: Point the panel at a git repository with a Compose file and it clones, validates and builds it on the box — any runtime, any number of containers, behind the same edge and the same certificates.
Serve it over HTTPS caddy: Every domain and alias gets its own certificate, issued and renewed on its own. There is no TLS configuration to write.
Deploy on push gitea actions: The runner lives inside the site’s own container. It builds the new release there and swaps it in, so shipping never needs a shell on the box.
Give a site a database mysql: One database and one user per site, created on request. phpMyAdmin is already on the box for when you need to look inside.
Edit the environment .env: Read and write a Laravel site’s .env from the panel. Saves are atomic, and database credentials can be filled in for you.
Limit who can reach it ip allowlist: The panel answers only to addresses you have unlocked, and any folder of any site can sit behind the same gate.
Hand a site over site owners: Give a site its own owner and they sign in to that site and no other — with the full run of it, publish through delete. One box, several people, nobody looking at anybody else’s.

Not just a UI

Every panel action is available to a program

The control panel is one client of the platform, not the platform itself. Anything you can do by clicking — create a site, change its image, provision a database, unlock an address, roll a deploy — a script or an agent can do too.

MCP server for agents

Point an MCP-speaking assistant at your box and it discovers the tools it can call, with the same permissions as the account behind them.

{
  "mcpServers": {
    "nimbus": {
      "url": "https://panel.example.com/mcp",
      "headers": { "Authorization": "Bearer $NIMBUS_TOKEN" }
    }
  }
}

HTTP API for scripts

A JSON API over the same actions, with token auth. Useful when the caller is a shell script, a CI job, or another service.

$ curl -H "Authorization: Bearer $NIMBUS_TOKEN" \
    https://panel.example.com/api/sites

$ curl -X POST -H "Authorization: Bearer $NIMBUS_TOKEN" \
    -d 'domain=shop.example.com&image=laravel' \
    https://panel.example.com/api/sites

Both speak the panel’s own vocabulary — sites, stacks, routes, databases, locks — so what you learn from the guide applies to both. How an agent uses them →

The stack

What runs on the box

Per site

Each site gets its own container, built from one of these — or from an image an administrator uploaded, which is a Dockerfile and a manifest in a zip.

Laravel app laravel PHP 8.3 — nginx, php-fpm and supervisor, with the deployment runner baked in.
Static site web-base nginx serving a docroot from the site’s folder. This site runs on it.
Single-page app web-spa The same, with client-side routes answered by the app shell instead of a 404.

Shared

Containers every site on the box uses.

caddyTerminates TLS and routes each domain to its container.
mysqlOne server, one database per site that asks for one.
redisCache and queues for the sites that want them.
phpmyadminDatabase access in the browser, behind the same IP gate.
panelThe control panel — a site on the platform it manages.

Running an app on a Nimbus box?

The site owner’s guide covers the whole path — the folder your code lives in, the runtime that serves it, the domain that reaches it, and the gate that can stand in front.

Read the guide