Many sites, one instance
An instance hosts many sites — each with its own directory, port, and service — and the operator chooses whether a new site joins an existing instance or gets a fresh one.
An instance hosts many sites. Each site gets its own directory, its own internal port, and its own service, so several sites run side by side in one instance without colliding. A new site can launch into a fresh instance or join an existing one — the panel shows each instance's capacity and site count, and the operator decides.
The tree
node → instance → site, with a clear role at each level:
| Level | What it is |
|---|---|
| Node | The server (bare metal or a VPS) — enrolled once, running the agent. |
| Instance | A container or VM on the node — the isolation boundary. |
| Site | A workload (WordPress, PHP, Node, Docker…) running inside an instance. |
The boundary is the instance
Sites in one instance belong together and trust each other. They are demarcated — each has its own directory, port, and service, so one can never overwrite another and deleting one never touches another — but they are not walled off from each other. For a hard wall between two workloads, put them in separate instances. That is what an instance is for.
When to share an instance, when to split
Capacity decides, not a rule:
- A small VPS — the node is often itself a VM, so nesting one instance per site is wasteful. Many sites in one instance keeps it lean and the list short.
- A large node — instances are cheap; one per site (or per tenant) is clean and gives each workload its own hard boundary.
The new-site wizard lists each instance with its current site count, and the instance page shows free CPU/memory/disk. There is no automatic placement — the panel surfaces the facts, the operator places the site.
Adding a site to an existing instance
In the new-site wizard, pick any existing instance (each row shows what it already hosts and what stack would install on the way). The site's internal port is allocated automatically — the type's default when free, otherwise the next free port — so two sites never contend for one. The site launches into its own directory, named after the site.
What each site gets
| Type | Files | Serves on | Service |
|---|---|---|---|
| Static · PHP · WordPress | /srv/web/<site> | its allocated port | its own nginx server block (+ its own PHP-FPM pool) |
| Node · Python · Go · Rust | /srv/app/<site> | its allocated port | its own spipcp-<type>-<site>.service |
| Docker | /srv/docker/<site> | its allocated port | its own compose project (containers) |
The site Overview's Chain card names the real paths; see Where a site lives.
OpenLiteSpeed hosts many sites too
A WordPress site fronted by OpenLiteSpeed used to own its instance's web serving outright and could not take a co-tenant. That limit is gone: each site gets its own OpenLiteSpeed virtual host on its own port, rooted at its own directory, exactly as the nginx-fronted sites do.
Each site's PHP runs as that site's own user
A site's files belong to the site's own Linux user, with the web server able to read them through the
group — which is what lets wp-config.php stay at mode 640 and still be served. The runtime —
the PHP-FPM pool under nginx, the LSAPI process under OpenLiteSpeed — runs as that same per-site
user, so one site's PHP cannot open a neighbour's wp-config.php and the database credentials and
security salts inside it.
Before this, both web servers ran every site's PHP as the shared www-data, which the group
permission grants read access to everywhere. On an instance hosting one site that made no difference;
on an instance hosting several it did.
The runtime user is written when a site launches, so an older site keeps the shared user until it is next launched or Applied. The panel reports that as drift like any other setting that has not reached the live server — see Do the settings reach the site?.
Deleting one site never touches another
Teardown is per-site: removing a site removes its directory, its service, its web configuration, and (optionally) its database — and nothing else. A co-tenant site keeps serving through the whole operation; the shared web server is reloaded, never restarted.
Existing sites are safe
A site created before this feature keeps its original paths and stays sole tenant on its instance. Its next relaunch moves it onto its own directory automatically (a one-time move — content is preserved, nothing is wiped), after which the instance can take siblings. Until then, adding a second site to that instance is refused with a plain explanation.