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 gives you a single handoff panel that gathers the endpoint, the owner login, and the database credentials in one place.
Create a database with the site
In the launch wizard you 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 by you) 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 engine you want 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 you can hand a site over at launch or any time after.
Secrets are only fetched when you ask:
- 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 you click Reveal — and that reveal is audited. The panel never pulls a secret you haven't asked to see.
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 your configured SMTP (see Settings → Email).
- Set it yourself — the password can be one you 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 you can hand off this way.
Next steps
- Site owners — the owner identity behind the credentials you're handing 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 your app (wp-config, process env) depends on the site type.