Site owners (isolation)
Each isolated site gets its own Linux owner inside the instance — a login user that owns the docroot and has a narrow, safe permission grant, so a site is walled off from its neighbours.
Inside an instance you can run several sites. Site isolation gives each one its own Linux owner: a per-site user that owns the site's docroot, can manage its own files from a terminal, and is walled off from the other sites on the box. It's the isolation layer below the tenant boundary (which separates whole instances).
Isolation is on by default
Site isolation is a checkbox in the launch wizard's Configure step, on by default. A site can opt out and run under a shared user, but the default is its own owner.
When isolation is on, the owner is created before anything is written, so it owns the docroot from the first byte. A relaunch just re-applies the owner's shell, password, and permission grant — it doesn't duplicate them.
What the owner can do
The owner is a real login user (it has a login shell, unlike the SFTP-only access-key user), so the site terminal logs in as the owner, not as root. Its powers are deliberately narrow:
- Owns its docroot. The site's files belong to the owner; it can read, write, and repair permissions on them.
- Scoped permissions only. The owner has a narrow allowlist confined to its own docroot —
chown/chmodon the site root, so it can re-take ownership after a deploy. Nothing box-wide.
Why service control is withheld (for now)
The owner can manage its files, but it cannot restart shared, box-wide services. On a typical
instance nginx and php-fpm serve every site on the box, so letting one owner restart them
would hand it power over its neighbours — exactly the escalation isolation prevents. Service
control will be granted only when a site type declares the exact, site-scoped service actions its
owner may take (e.g. a per-site php-fpm pool reload). Until then, site-scoped-and-safe wins.
Naming the owner
- From the domain — when isolation is on and you don't set a name, the owner is derived from the
site's domain:
localtown.ie→localtownie(non-alphanumerics stripped, lowercased, ≤32 chars, collision-suffixed if taken). - You set it — the wizard lets you type an explicit owner name; your choice wins over derivation.
- No domain yet — a site is usually launched before a domain is attached, so when there's no
explicit name and no domain, the owner falls back to a deterministic
sitedev-<hex>name.
The name is saved on the site and re-used on every relaunch, so the owner never drifts.
The password
A site owner has a strong generated password by default, or one you set in the wizard. Either way it's stored only encrypted — SpipCP records the secret's name, never the value. The password is delivered to you once, through the handoff panel.
SFTP and shell coexist
The owner's login shell doesn't replace the SFTP confinement used for access keys — the two coexist. An access key still gets the locked-down, SFTP-only path; the owner adds shell login on top. See Day-2 · Access keys.
Next steps
- Site database & handoff — create a database with the site and hand the owner its credentials.
- Tenant isolation — the layer above: separating whole instances.
- Sites — launching a site and the wizard end to end.
Blueprint authoring
How a site type is defined — the blueprint, its required services, environment, install steps, the smoke check, the beta badge, and how to add a new one.
Site database & handoff
Create a database alongside a site on an installed engine, owned by the site owner — then hand the endpoint, owner login, and database credentials to whoever runs the site.