Concepts
How authentication, roles, sessions, and settings fit together in SpipCP.
A short tour of how the panel works.
Identity and access
Access is checked on the server for every action you take.
- Each user has one role. Today the roles are
adminandoperator. - Each role can do a fixed set of things — reveal secrets, view the audit log, and so on. The permissions are built in, not stored as editable rows, so they can't quietly drift out of sync.
- An operator is blocked from every admin-only action. This is checked on the server, not just hidden in the UI.
The UI matches: things an operator can't use (Users & Roles, Settings, the audit log) simply don't appear in their navigation. But hiding them is a convenience — the server check is what actually enforces access.
Authentication
You log in with a password and TOTP two-factor. There is no magic-link or email-code login on purpose: an infrastructure panel has to be reachable when email is down, so no login path depends on email. Password reset can use email (it's not the login path), and recovery codes cover a lost authenticator.
See Accounts for enrolment, recovery codes, reset, and sessions.
Sessions
Each session shows its device, IP, and last-seen time, and slowly expires. You can revoke any session from your account — revoking the one you're using signs you out right away.
Settings and secrets
Your configuration lives in the database, encrypted. The env file is only used to seed it on first boot. Two stores share the same encryption:
- Settings — config like SMTP and the panel's default locality. Even non-secret config is encrypted, so a database dump never shows plaintext credentials.
- Secrets — a store for API tokens and credentials. Values are encrypted at rest and only shown through an explicit reveal, which is logged.
Accountability
Sensitive actions — logins, invites, role changes, settings and secret writes, and every secret reveal — are recorded in an audit log you can't edit or delete. It's a record, not editable state. See Audit log.
Locality
Timestamps follow a layered locality: your own timezone and locale override the panel-wide default, which falls back to UTC and English. See Locality.
Setup wizard
First-boot orientation — create the admin, verify the master key, seed SMTP.
Recommendations
How SpipCP suggests you choose providers — DNS, SSL, and git — and the reasoning behind it. The short version: prefer open, self-hostable, EU/sovereign options; keep US-based platforms as a fall-back, not a default.