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.
A site often needs a database, and once it's live someone has to be told how to reach it. SpipCP does both at launch: it can create a database with the site, and it provides a single handoff panel that gathers the endpoint, the owner login, and the database credentials in one place.
Create a database with the site
The launch wizard can provision a database as part of launch:
- Engine — choose an engine already installed on the instance (MariaDB, MySQL, or PostgreSQL).
- Owned by the site owner — the database user is the site's owner, so the owner owns its database the same way it owns its files.
- Credentials — the database password is generated (or set explicitly) and stored encrypted, like the owner password. SpipCP records the secret's name, never the value.
SpipCP records which database the site is bound to, so the engine, name, and user show up on the site workspace and in the handoff panel.
Install-on-the-way
If the selected engine isn't installed yet, it's installed as part of the same launch rather than blocking on a separate step — SpipCP provisions what the site needs on its way up.
Handing over credentials
The handoff panel is the "store these now" surface. It appears on the launch success screen and stays on the live site's workspace, so a site can be handed over at launch or any time after.
Secrets are only fetched on request:
- The non-secret details show immediately — the reachable endpoint (attached domains, the node host/IP, and the served port), the owner login name, and the database engine, name, and user.
- The secrets (owner password, database password) are fetched only when Reveal is clicked — and that reveal is audited. The panel never pulls a secret that wasn't explicitly requested.
Three ways to deliver
- Show-once / copy — reveal on screen, with a per-field Copy and a Copy everything
button that yields one labelled
.env-style block. - Email the owner — send the credentials to an address (audited). Uses the configured SMTP (see Settings → Email).
- Set it manually — the password can be one typed in the wizard rather than a generated one.
Nodes and instances have no emailable password
This handoff is a site feature. A node or instance terminal logs in as root; there's no per-tenant password to email for them — break-glass access to a node/instance is the agent PTY, not a mailed credential. Only sites carry an owner identity that can be handed off this way.
Next steps
- Site owners — the owner identity behind the credentials being handed off.
- Settings — configure SMTP so the email channel works.
- Sites — the full launch flow.
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.
Environment editor
Edit a site's environment in a real .env code editor (line numbers, syntax highlighting) or a key/value table — comments are saved, and how the variables reach the app (wp-config, process env) depends on the site type.