Platform settings
Administration → Settings (needs the “Platform settings” permission). It’s split into tabs, and each part below has its own Save changes:
- General: branding.
- Customers: customer features and customer limits.
- Network & DNS: your internal networks and DNS hosting.
- Security: sign-in and sessions.
- Email: outgoing email, with a link to the email templates.
Two tabs have permissions of their own, because they decide who gets in and where sign-in links go: Security needs “Sign-in security”, and Email (with the wording of emails) needs “Outgoing email”. Without them, staff see those tabs read-only. See Staff and roles.
Switching tabs keeps unsaved changes on the others. A tab can be linked to, e.g. /admin/settings?tab=email.
Branding
| Setting | Notes |
|---|---|
| Name | 2–40 characters. Shown in the panel, the sign-in page and emails. A fresh install says “Panel”. |
| Accent colour | Hex colour, applied live across the panel and the sign-in page |
| Billing link | https://. Where customers upgrade and pay. |
| Network status page | https://, optional |
| Support email | Shown to customers and used in emails |
| Default theme | Dark, Light, or matching each person’s device. Used by anyone who hasn’t picked their own under Account → Appearance, including on the sign-in page. |
| Show platform status on the sign-in page | Each region’s uptime over the last 60 days, shown to anyone who opens the sign-in page. Off (the default on a new install), the page shows your name instead, and visitors who aren’t signed in aren’t told your regions or the panel’s version. |
Resellers’ brands still show to their own customers.
Customer features
Switch features off and they disappear from the customer panel, and the API refuses them.
| Feature | What it is | Fresh install |
|---|---|---|
| Custom ISOs | Customers add their own installers from a link | On |
| Startup scripts | Cloud-init or shell scripts run on first boot after a reinstall | On |
| Team access | Customers share servers with other people, with chosen permissions | On |
| Rescue mode | Customers boot their server into a rescue system (staff always can) | On |
| DNS hosting | Customers host their domains’ records on your nameservers. Needs nameservers set first. | Off |
| Custom images | Customers save a server as an image and reinstall their other servers with it | On |
| Floating IPs | Customers reserve IPv4 addresses and move them between servers for failover | On |
| Private networks | Customers connect their servers in a location over a free internal network | On |
| API tokens | Customers create tokens to automate their servers. Switching it off stops existing customer tokens working. | On |
Customer limits
How much each account can keep. Customers see their limits and the API enforces them. Lowering one keeps what accounts already have; they can’t add more until they’re under it.
| Limit | Range | Default |
|---|---|---|
| Floating IPs per account | 1–256 | 3 |
| Private networks per account | 1–100 | 10 |
| Firewall groups per account | 1–200 | 20 |
| Custom images per account | 1–100 | 5 |
| Custom ISOs per account | 1–50 | 3 |
| DNS zones per account | 1–1,000 | 20 |
| DNS records per zone | 10–10,000 | 500 |
DNS hosting
The 2 to 4 nameservers customers point their domains at. See DNS with PowerDNS.
Your internal networks
Ranges your datacenter uses itself, such as a management, storage or out-of-band network. Without this, a customer could make a private network in, say, 10.10.0.0/24 while that is also your internal range. Their servers might then reach both, and it looks like it works when it doesn’t.
- Reserved ranges: IPv4 ranges like
10.10.0.0/16, one per row, each with an optional note (up to 80 characters) saying what it is, such as “Storage network”. Add a range adds a row. A range an IP pool hands addresses out of can’t be reserved, as servers need it. Removing a range removes its note. - Found on your nodes: the private networks the nodes themselves are on, from their agents. These are reserved too. A network an IP pool hands addresses out of isn’t counted, because that’s the servers’ own (behind NAT, say).
- Stop customers’ servers reaching them (on by default): every node drops anything a server sends to these ranges over its public interface. Customers’ own private networks are unaffected. Turn it off only if servers need something on your internal network. Changes reach the nodes straight away.
Customers can’t make a private network that overlaps a reserved range: they’re asked to pick another, with a free one suggested, and the panel never suggests a reserved one. Networks made before a range was reserved keep working between their servers. They’re listed here with their owner, so you can ask the customer to make a new one elsewhere.
Sign-in and sessions
Changing these needs the “Sign-in security” permission.
| Setting | Notes | Default |
|---|---|---|
| Staff must use two-factor | Staff without it can’t sign in | On |
| Ask customers to turn on two-factor | They see a banner until they do | Off |
| Sign out after inactivity | 1 hour, 12 hours, 1 day, 1 week or 30 days. However active it is, a session also ends 30 days after signing in. | 12 hours |
| Staff can sign in from | IP addresses or ranges. Empty means anywhere. Won’t save if it would lock you out. | Anywhere |
Accounts are locked for 15 minutes after 5 failed sign-ins. After 10 wrong two-factor or recovery codes within an hour, counted across every sign-in, the account’s codes aren’t accepted for 30 minutes, so someone who has the password can’t keep guessing. Each lock shows in the audit log.
- Each authenticator code works once. A code that was already used, including the one that turned two-factor on, is refused until the app shows the next one.
- Sign-in and password reset requests are limited per address. IPv6 addresses count per /64, since one client usually has the whole range.
- One email address is sent at most 3 password reset links an hour. The sign-in page answers the same way either way, so it doesn’t say whether an account exists.
- Turning on two-factor, adding a passkey and creating an API token ask for the account’s password, so a signed-in browser left open isn’t enough. Adding a passkey or API token also emails the account’s owner.
Outgoing email
| Setting | Default |
|---|---|
| From name | Panel |
| From address | |
| SMTP host | |
| Port | 587 |
| Encryption | STARTTLS (or TLS, or none) |
| Username | |
| Password | Write-only, kept encrypted |
Changing anything here, or sending a test, needs the “Outgoing email” permission. Staff without it don’t see the mail server or its username.
The saved password is only sent to the server it was typed for. Changing the SMTP host, port, username or encryption needs the password typed again.
Send test sends a test email and shows the SMTP server’s answer. The wording of each email is under Email templates.