SpipCP
Operations

DB console & restarts

Open the site's database in Adminer behind a single-use, short-lived token gate, copy password-free connection snippets, and restart a service (nginx / PHP-FPM / the app unit) from the site workspace — with the panel asserting the unit came back.

Two more day-2 actions live on the site workspace's Settings tab: opening the site's database console, and restarting a service without leaving the workspace.

DB console

Where: Site workspace → Settings tab → Database card (shown only for a site that has a linked database, e.g. WordPress).

The card gives you two things: connection snippets to connect with your own client, and a one-time link to the in-instance Adminer.

Connection snippets

Two copy-paste snippets, both password-free:

  • CLI — a mysql -h … -P … -u … -p <db> (or psql -h … -p … -U … -d <db>) line. The -p flag prompts for the password; it's never included in the line.
  • DSN — a mysql://user@host:port/db (or postgresql://…) string, without the password.

Neither snippet contains the plaintext password. Revealing the password stays a separate, audited action on the Databases tab.

The Adminer link is single-use

Open DB console opens a link that works once and expires after 60 seconds. The first use takes you to Adminer; opening the same link a second time is refused, and logged as a security event. So a link that leaks into your browser history or a log is dead the next time it's opened.

You can also do the same thing from the command line (the panel button and curl agree):

URL=$(curl -fsS <panel>/api/v1/sites/<id>/db-console | jq -r .url)   # mint (session-gated) → { url }
curl -fsSI "$URL"   # first use → 302 redirect to Adminer (token consumed)
curl -sI  "$URL"    # replay → 401, security-logged

The link is tied to one site's database, so a link for one site can never open another site's database.

Service restarts

Where: Site workspace → Settings tab → Services card.

Restart a service for the site without leaving the site workspace. The card shows the services for the site's type:

Site typeRestart buttons
staticRestart Web server (nginx)
PHP / WordPressRestart Web server (nginx), Restart PHP-FPM
NodeRestart App (node)

A restart is confirmed, not assumed

Clicking restart restarts the service inside the instance, then checks it actually came back up. You only get the green "Restarted php8.5-fpm.service — it is active again." when it's really active. If the service fails to come back, you see the error — never a fake green over a dead service.

Restarting needs SITES_MANAGE; listing the services needs SITES_VIEW. Every restart writes an audit row.

API

The DB console (sites.dbConsole.open, sites.dbConsole.snippets) and the restart (sites.restart) are on the typed /api/v1 surface alongside the other day-2 actions, each with its own permission check.

On this page