#FE: Server screens (from backend Phase 9)
Frontend spec for backend Phase 9 — Server panel features — requirements complete 2026-10-06 (Pair 1), not built. V8 requirement This was the biggest gap left on this site: Phase 8 said how a server gets into Central, and nothing said what happens afterwards. Now 9.1–9.33 cover the server list, the server-level actions and every screen in the server menu. Revised 2026-10-07, when Pair 1 checked the phase against V7 and added six things (see the rows marked added 2026-10-07); the three rules at the end moved from 9.28–9.30 to 9.31–9.33.
Central's own data — server list, search, filter, sort, shared-with-me, deleted servers
Cloud provider — power on / off and resize, managed servers only
OSS API (live) — dashboard, databases, users, firewall, cron, services, PHP, Node, logs, backups, settings, sync
Central jobs — service monitoring (restart what is down), alerts, panel update
i18n namespaces: servers.*, servers.list.*, servers.actions.*, servers.panel.*, servers.settings.*, servers.deleted.*.
#A. The server list
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 9.1 | Server list | /servers | The organization's servers, from Central's own data — so the list does not wait on any panel. Search by name, IP, provider, OS, stack · filter managed / not managed · sort by name or created · 12 per page (as V7) | Reading from Central is what makes this page fast, and it is also why the rows can be stale: the cached facts come from the moment the server connected (8.11). Label them "at connect" or refresh them, but never present a cached row as live. 12 per page is the backend's number — use it rather than inventing a page size, and keep search, filter and sort in the URL so a filtered list can be shared and restored |
| 9.2 | Shared with me | Same page, own tab or filter | Servers shared with the user (4.6) | Shared servers are not the user's own, so the row must say who owns them and the actions must be cut to the shared permissions — the quickest way to lose trust here is to show an action that then fails |
| 9.6 | Deleted servers & restore | /servers/deleted | As V7: list deleted servers and restore them, with no time limit. Restoring runs the plan and server-limit checks. Managed servers cannot be restored | This closes a question this spec had parked V8 requirement — it was listed as "V7 only, not in the backend or OSS" and no screens were written for it. Now there are rules, so: a plain list with Restore, the limit check reported before the button where possible, and managed rows shown as not restorable with the reason, not hidden. "No time limit" is worth saying on screen, because V7 users will assume there is one |
#B. Server-level actions
These are actions on a server, not items in its menu — they belong in the server page header or its Settings area, and the risky ones follow the frontend doc's confirm rules.
| # | Action | Rules from the backend doc | Frontend notes |
|---|---|---|---|
| 9.3 | Power on / off | Managed servers only (as V7). Central calls the cloud provider. Power on is blocked while credits are negative | So the button exists on a minority of servers and must simply be absent on the others, not disabled with a puzzle. The negative-credit block needs the real reason and an Add credit link — and it pairs with 6.13, where a top-up clears the threat but does not power anything back on, so this is the screen the user comes to afterwards. Say that plainly |
| 9.4 | Resize | Managed servers only (as V7). New size from the admin price list; needs credits of at least one month's price; Vultr cannot move to the same or a lower price | This answers an open question about migrated managed servers — resize is kept V8 requirement. The screen shows the new monthly price and the shortfall before the button. The Vultr rule is a provider-specific limit, so it must come from the API's own list of allowed sizes; never hard-code a provider's rules in the frontend |
| 9.5 | Delete | Removes the server from Central, with an optional "also delete at the provider" — always for managed servers. Shared members are removed | Two very different outcomes behind one word, so the confirm must state which one is about to happen. For managed servers the provider deletion is not optional, so do not offer a tick-box that cannot be unticked — say it outright |
| 9.8 | Disconnect | Removes the server from Central without touching it — OSS, apps, databases and sites keep running. A warning explains this and the user types the server name or IP to confirm. Central asks OSS to revoke its Central token, then removes its record. If OSS is offline, Central still removes its side and tells the user to turn Central off in the panel later. Shared members lose access; the server stops counting toward the plan limit; it can be added back with 8.5. Not for managed (8.2) or free managed (8.6) servers — those can only be deleted | This closes the oldest open worry on the Servers page V8 requirement: that Central could not revoke its own key, so a disconnected panel kept working with a live token. Central now asks OSS to revoke it. Two things the screen must get right: the offline case is a partial success — "removed here, still enabled on the panel, turn it off there when it comes back" — not a failure and not a clean success; and the type-to-confirm matches OSS's own pattern, so accept either the name or the IP, and say which ones work |
| 9.7 | Tags | ⏸ Decision pending — may not be in V8 | Left exactly as the backend left it. The frontend doc keeps server tags as a V8 idea of its own, so nothing is removed, but nothing is promoted to a backend-backed rule either |
#C. The server menu — same screens as the OSS server panel
Each row is one screen in the fixed server menu, and each reads live from the server's OSS panel.
| # | Screen | What it holds (backend wording) | Frontend notes |
|---|---|---|---|
| 9.9 | Dashboard | Live health and usage (CPU, memory, disk, load, network), processes with kill, server facts | The one screen users leave open, so it streams: facts first, metrics as they arrive. Kill a process is destructive and needs a confirm with the process named |
| 9.10 | Databases | Database engines — add only, no remove (corrected 2026-10-07: OSS has no remove), databases, database users, remote access, exports, database monitor, phpMyAdmin login | The add-only rule changes the screen, not just a button: an engine the user installs by mistake cannot be taken away from here, so installing one is a CONFIRM that says it is permanent, and the list shows installed engines without a delete action rather than with a disabled one. The heaviest screen in the menu — treat engines, databases and users as three clear areas, not one table. Remote access exposes a port, so it needs a warning rather than a plain toggle. Confirms Phase 8's rule that no database engine is chosen when the server is created — it is installed here |
| 9.11 | System users | Add / edit / delete, SSH access and SSH keys. Added 2026-10-07: root SSH access per user on / off (as V7) — needs OSS API support | SSH keys are credentials: show fingerprints, never the private half, and make removal explicit. Root SSH access is the most dangerous switch in the menu, so it is a CONFIRM that names the user and says plainly what it grants — not a row toggle. Missing on the OSS side, so it is specified but cannot be built first |
| 9.12 | Firewall | Server firewall rules | Rules can lock the user out of their own server. Order matters and the screen must make an existing allow-before-deny visible rather than silently accepting a rule that will never match |
| 9.13 | Fail2ban | Server jails and settings | Pair the jail list with "currently banned", or users cannot tell whether it is doing anything |
| 9.14 | Cron jobs | Add / edit / enable / disable / delete, presets | Show the schedule in words next to the expression. Presets are the fast path and belong first |
| 9.15 | Services | Web server, database and other services: status, start / stop / restart, and added 2026-10-07: test the web server config before restarting | Stopping a web server takes sites offline, so that action is a confirm, not a button. Report the result from OSS rather than optimistically flipping the row. The config test belongs in the restart confirm itself, not beside it — run it, show the real output, and let the user restart anyway or cancel. A silent restart on a broken config is how every site on the server goes down |
| 9.16 | PHP | PHP versions and extensions (incl. ionCube) | Phase 8 already refuses a PHP version an app cannot run on; keep the same wording here |
| 9.17 | Node.js | Node.js versions on the server | Hidden when the server cannot run it, as the navigation rules already say |
| 9.18 | Docker | Networks and volumes for Docker apps (Phase 10) | No home in the fixed server menu — see D-45. It also only makes sense on servers that run Docker apps, so it is a candidate for a type-only item |
| 9.19 | Logs | Read system log files | Large files: paginate or tail, never load whole. Read-only |
| 9.20 | Disk cleaner | Free space: caches, old logs, temporary files | Say what will be removed and how much, then confirm. Never a one-click "clean" |
| 9.21 | Backups | Server backups, history, restores (backup storage from Phase 5). Added 2026-10-07: backups of deleted servers stay listed and downloadable (as V7) | Restore is the most destructive action in the product — confirm with the backup's date, and make clear what it overwrites. The deleted-server rule needs a home: those backups outlive the server, so they cannot live only under a server that no longer exists. Either the deleted-servers page (9.6) lists them, or there is one account-level backup list — the backend does not say which, and this spec does not pick for it. What it must not do is hide them |
| 9.22 | Settings | Server (hostname, timezone), SSH sign-in security, swap, Redis, update automation, reboot now, scheduled reboot, reboot-required notice | Group them: identity · security · memory · updates · reboot. Reboot now is a confirm; reboot required is a banner on the server page, not a line buried in Settings |
| 9.23 | Server sync | Find apps, users and settings already on the server and add them to the panel | A review step before anything is adopted: show what was found, let the user choose, then report what was taken in |
| 9.24 | Panel update | Update OSS on the server — replaces V7's "update agent" | No home in the fixed menu — see D-45. It is also the one action that can break the connection Central depends on, so the screen must show the current version, warn that the panel restarts, and tolerate a short unreachable gap without declaring the server broken |
| 9.25 | Service monitoring | As V7: on / off per server and a check interval. Central checks services through the OSS API and restarts any that are down. An alert is sent (Phase 11 — Alerts) | Central restarts things on its own, so this screen must say so in plain words before the toggle — a silent auto-restart is the kind of behaviour users discover during an incident. Pairs with the Services screen (9.15); D-45 covers where it sits |
| 9.26 | Default web page | As V7: view and edit the page shown when someone opens the server's IP or a domain that is not set up. Needs OSS API support | Missing on the OSS side — the backend says the API does not exist yet, so this screen is specified but cannot be built first. Owner-supplied markup, so it is sanitised like the White label pages (12.8) |
| 9.27 | Change database root password | As V7: new password + confirm; single quotes, double quotes and spaces are not allowed. Needs OSS API support | Missing on the OSS side. The character rule goes in the field hint before typing, not in an error afterwards. Phase 11 (11.21) already says the email about this must not contain either password |
| 9.28 | Server alerts | New 2026-10-07, as V7: set the limits — CPU, memory, disk, load — that trigger an alert; the alert goes out through Phase 11 (Alerts). Needs OSS API support | This answers half of D-37. Phase 11 (11.13) said alert limits are set per server by the user, with V7's defaults, but nothing said where that screen lived; 9.28 now puts it in the server panel. So the limits are a server screen — and the per-server notification channels of 11.7 still have no screen in this phase, which is the half of D-37 that stays open. Show the V7 defaults as the starting values and name the unit on every field. Missing on the OSS side |
| 9.29 | Change server IP | New 2026-10-07, as V7: update the server's IP in Central after it changes at the host (Central stores the IP, 8.11) | The one screen in this menu that edits Central's own data rather than the panel's — which is exactly why it exists: the cached copy from 8.11 goes stale when a host moves a server. So it must not look like a server action: no restart, no provider call, just "tell Central the new address", with the old value shown for comparison. Phase 11's V7 email map already carries a "Server IP changed" message, so this is the action behind it |
| 9.30 | PHP-FPM config | New 2026-10-07, as V7: view and edit the PHP-FPM config. Needs OSS API support | A text editor on a real config file, so the same care as the firewall: show what is there, never a blank box, and make clear that a bad value affects every PHP app on the server. Sits naturally with PHP (9.16) — but like the three items in D-45, the fixed menu has no slot of its own for it. Missing on the OSS side |
| 9.33 | Server activity log | Who did what on this server — read from OSS | Same as the app activity log (10.23): it is OSS's record, so it is a read-only view that may be missing while a panel is offline — say that instead of showing an empty log |
#D. Rules that apply to every server screen
| # | Rule | What the frontend does |
|---|---|---|
| 9.31 | Plan limits — server features join the plan feature list (7.2), and the admin can change them per plan | The same mechanism as the app features, so nothing hard-codes which plan has what. A feature the plan does not include is hidden, with the upgrade path only where a user can act on it |
| 9.32 | Permissions — every feature has view / manage for organization roles and shared servers (Phase 4) | Menu items the role cannot view are hidden, never disabled-and-empty — the rule already in the frontend doc's navigation section. View-only renders the screen without its actions, not a greyed-out copy |
| — | Offline panel | Every screen in §C depends on a live panel, so each needs the same offline state: the menu stays, the page explains, Retry is offered. The exact screen is still the backend's Q3 Open question |
#What this phase answers
| Open item | Answer |
|---|---|
| The whole "after a server exists" gap (D-13, and the frontend doc's open question 10) | Answered V8 requirement — 9.1–9.30 specify the list, the actions and every menu screen |
| Central cannot revoke its own key — the warning that stood on Servers since this site began | Answered by 9.8: Central asks OSS to revoke its Central token on disconnect, and handles the offline case by removing its own side and telling the user |
| Deleted servers & restore — parked as "V7 only, not in the backend or OSS" | Answered by 9.6 V8 requirement — list, restore, no time limit, plan and limit checks, managed servers excluded |
| Is resize kept for migrated managed servers? | Yes — 9.4 V8 requirement, from the admin price list, with the one-month credit check and Vultr's own restriction |
| What replaces V7's "update agent"? | 9.24 Panel update — Central updates the OSS panel on the server |
| Which server actions are managed-only? | Power on / off (9.3) and resize (9.4), and disconnect is the opposite — not available for managed or free managed servers (9.8) |
#Still open after this phase
| # | Question |
|---|---|
| D-45 | Where do Docker (9.18), Panel update (9.24), Service monitoring (9.25) and now PHP-FPM config (9.30) go in the fixed server menu? The menu order is fixed and has none of them, though 9.30 sits naturally under PHP and 9.29 Change server IP under Settings. Same family as D-37, D-40 and D-43 |
| D-37 | Half answered on 2026-10-07. The alert limits now have a home — 9.28 Server alerts, in the server panel. What stays open is the other half: Phase 9's menu still has no Notifications screen, yet 11.7 says the user attaches channels per server at Server → Notifications |
| D-41 | Still open, and the backend agrees: Phase 9's "Not in this phase" names hosting users (the limited panel login) — part of 8.6, still open. Pair 2's 12.12 may be the other half of this answer — see the note on FE: Control Panel & White label |
| — | Tags (9.7) are a pending backend decision, so the frontend doc's own server-tags idea stays an idea |
| — | Refreshing server data and the "needs a new token" state are still the backend's Q3 Open question — and 2026-10-07 adds that reconnecting after a broken link is part of the same decision |
| — | Site migration and restoring a backup to another server are now named in Phase 9 as pending decisions Open question — both exist in V7. No screens are written for either, which is also the frontend doc's rule |
| — | 9.11 root SSH, 9.26 default web page, 9.27 DB root password, 9.28 alerts and 9.30 PHP-FPM all need OSS API support that does not exist yet Missing — five of the phase's screens are blocked on the OSS side, not on Central |