Signing in
Administrators sign in with a passkey, or with a password followed by an authenticator code, a passkey or a recovery code. Two-step sign-in cannot be switched off for administrators or resellers. Your Security page lists your passkeys, authenticator app, recovery codes, signed-in devices, API tokens and password; ending a device signs it out within seconds.
Some actions ask you to confirm it is you again (step-up). The confirmation lasts five minutes and the session is rotated when you give it.
Finding your way
- Overview shows every server with its live status, recent activity and the installed modules.
- The menu is built from modules. Install a module and its pages appear; you only see what your role allows.
- Ctrl K (Cmd K on a Mac) opens the command palette: go to any page or run any action you are allowed to run.
- Action pages. Each module page lists its actions, filterable into changes and reads. Opening one shows a form generated from the action's schema; the server validates it again before anything runs.
Every action carries a risk level:
| Risk | What happens |
|---|---|
| low | Reads and everyday changes. Run straight away. |
| medium | Changes to a service or an account. |
| high | Changes with wide effect. Need a fresh confirmation (step-up) unless you are only previewing. |
| critical | Cannot be undone from the panel, such as deleting an account. Confirmed twice, then step-up. |
Actions that support it show a plan first: what will be created, changed or removed, as a diff. Nothing is applied until you choose Apply changes.
Dedicated screens for each module (accounts, domains, DNS, mail, files and more) are being built. Until they land, every module is fully usable through its action pages, the command palette and the API.
Servers
The server you installed on is the control server and runs the first agent. To add another, create an enrolment token and run the command it gives you on the new machine (see Add more servers). Each server has its own key and can only receive its own operations. Retiring a server drops its connection and its key.
People, roles and grants
- Four levels: administrator, reseller, user (the account owner) and sub-user. Each person manages only their own subtree.
- Roles are data. Built-in roles come from the permissions each module declares; you can add your own, such as a support role that can view and act as customers.
- Grants can be scoped to a single site, domain or folder. A deny grant always wins.
- Explain access: the panel can show why someone is or is not allowed to do something.
- API tokens are scoped and can be revoked at once. A token can never change passwords, passkeys or other sign-in settings.
Plans and limits
A plan is a set of limits: domains, sites, mailboxes, databases, storage, containers and the rest, each declared by the
module that enforces it. Modules reserve a unit before they create something and release it when it is removed or
when creation fails, so counts stay right. When a limit is reached the action fails with
limit_exceeded and names the limit.
Hosting accounts
- Create makes the identity and a Linux user on the chosen server, with its own home directory and, if you allow it, a shell.
- Each account runs inside its own systemd slice with CPU, memory, IO and process limits; disk quotas apply where the filesystem supports them.
- Suspend locks the Linux user and ends the account's sessions and API tokens in the same step. Unsuspend reverses it.
- Delete is critical: it removes the Linux user and home (unless you keep the home), and the other modules remove the account's domains, zones, sites, databases, container stacks and backups.
Acting as a customer
Staff who hold the impersonation permission can act as a customer to see exactly what they see. It needs a reason and a fresh confirmation, has a time limit, and shows a banner that cannot be dismissed. While acting as someone you cannot change their password, passkeys, authenticator or tokens, and every action is recorded with both identities.
The audit log
Every change is written to a hash-chained audit log with who, as whom, from where, and the parameters (passwords and other secrets are redacted). You can search and export it as JSON or CSV with a checksum manifest, and run a check that recomputes the chain and reports the first row that does not match. There is no action that edits or deletes an audit row.
Keeping servers healthy
- Security: firewall with an automatic rollback timer, CrowdSec, malware and integrity scans, unattended upgrades with a health watch, and a security score.
- Stats and logs: metrics, alerts, log search and live tail.
- Backups: targets, schedules, retention, verification and restores.
- Modules that manage configuration have a reconcile action that puts the server back to the desired state if something changed behind the panel's back.