#FE: Application screens (from backend Phase 10)
Frontend spec for backend Phase 10 — Application panel features — requirements written 2026-10-05, not built. V8 requirement This is the phase that makes Central a hosting panel rather than an account portal.
i18n namespaces: apps.*, apps.create.*, apps.domains.*, apps.files.*, apps.deploy.*, apps.backups.*, apps.security.*.
#A. Creating an app, and the app's home
| # | Tab / feature | Rules from the backend doc | Frontend notes |
|---|---|---|---|
| 10.1 | Create app | Same as OSS: one-click apps by category (CMS, PHP, Node, development, productivity, tools, others) — all the V7 apps (WordPress, Moodle, Mautic, PrestaShop, Joomla, Uptime Kuma, Node-RED, n8n, NodeBB, phpMyAdmin, Akaunting, Nextcloud, Statamic, Craft CMS…) plus the extra OSS apps (Docker apps such as Ghost, Gitea, Vaultwarden, Grafana, Metabase); Git; custom PHP / static / Node. Setup progress is shown until ready | The catalogue is long, mixed and grows with OSS, so it must come from the API with the backend's own categories and a search — never a hand-written list. Creating is a long action: show progress, say it is safe to leave, and let the finish notification tell them. No database-engine field here |
| 10.2 | Overview | Status, site facts, source (one-click / Git), domains, database, backups, process (Node / Docker), a protection summary (password, firewall, bots, folder lock), attention checks — checks failed, no SSL, no database, folder unlocked, no backups, each with a fix button — first-run credentials shown once, magic login (WordPress), root lock, visit site | The richest screen in the phase, and two parts deserve care. The attention checks are a per-app version of the all-servers "Needs attention" idea, so the two should look and behave alike rather than being invented twice. And first-run credentials shown once is the other half of the no-secrets-in-email rule (11.15, 11.21): this is now the only place a user sees them, so the panel must make "save these now" unmistakable and offer a reset path afterwards |
| 10.3 | App actions | Enable / disable, delete — with an option to also remove files and databases | Disable is a CONFIRM ("the site stops answering"). Delete is the most destructive action in the app area: a type-to-confirm whose "what will happen" box lists exactly what the tick-box adds (which files, which databases), because the same button can mean "unlink" or "destroy everything" |
#B. Domains, files, logs and configuration
| # | Tab / feature | Rules | Frontend notes |
|---|---|---|---|
| 10.4 | Domains & SSL | Add, remove, set primary, DNS check; SSL issue / dry run / custom certificate / force HTTPS / remove | One tab, two jobs. The DNS check can legitimately say "not pointing here yet" — a state, not an error — so show the record to create, with copy, and let them re-check. Dry run should be first-class: it is the safe way to test before hitting a certificate rate limit. Force HTTPS needs a warning that a broken certificate locks visitors out |
| 10.5 | Files | Browse, edit, upload (large files), download, copy / move / rename, permissions, compress / extract, search, size per folder, trash + restore | The biggest single screen. Two things decide whether it works: large uploads (progress and a clear failure, never a silent timeout) and trash + restore, which makes destructive actions recoverable and should be visible rather than hidden. Size-per-folder was its own item in the first draft and now lives here |
| 10.6 | Logs | Access / error logs, clear, sizes | Follows the server-log pattern already specced: pick a source, live tail, filter, download, Clear behind a confirm |
| 10.7 | PHP | PHP version and settings per app, PHP isolation | A version change can break a running site, so pair it with a clear confirm naming the app. Isolation deserves one plain sentence |
| 10.8 | Environment | Edit .env, history, compare, restore | An editor with history, diff and restore — treat it as a small version-control screen. It holds secrets, so values are hidden until revealed, and it is never logged or cached in the browser |
| 10.20 | Settings | Web root, fix permissions, site type | "Fix permissions" is a one-shot action with a result, not a setting — don't render it as a switch |
#C. Deploys, data and copies
| # | Tab / feature | Rules | Frontend notes |
|---|---|---|---|
| 10.9 | Deployment | Git account, deploy key, deploy now, deploy script, history, redeploy, deploy on push (webhook) | The deploy key and webhook URL are copy-once values the user pastes into their Git host, so they need copy buttons and a plain "paste this there" instruction. History with redeploy gives a failed deploy a one-click recovery. The account comes from the per-server Git integration (Phase 5) |
| 10.10 | Databases | Attach / detach databases, one-click phpMyAdmin login | Attach/detach is a relationship, so show which databases are already attached elsewhere. The one-click login opens a session on the panel and must not leave credentials in a URL the browser keeps |
| 10.11 | Backups | Instant + scheduled, download, restore (same server only), retry, delete | The limit matters: restoring elsewhere is on the undecided list below, so no screen may imply it. Scheduled backups need a destination from the server's storage integration |
| 10.12 | Staging | Create staging, push to live | "Push to live" overwrites a working site — the most dangerous action here. Type-to-confirm with a plain list of what will be replaced |
| 10.13 | Clone | Clone an app | Split from Staging in the rewrite. Needs a target domain and a clear "what gets copied" list |
| 10.14 | Workers | Workers (Supervisor) add / edit / restart / delete; Node apps run as services | A behaviour change from V7 worth telling migrated users once: Node apps are services now, not PM2, so the language is start / stop / restart |
| 10.19 | Container & Compose | Docker apps: container status, update image, secrets, compose file | Docker-type apps only, which is why the app menu is type-dependent. Secrets are write-only. "Update image" is the only update path any app type gets — see the undecided list |
#D. Protecting a site — now four separate tabs
The first draft had one "Security" feature. The rewrite splits it the way the OSS panel does, which is better for users because each has its own on/off state and its own evidence:
| # | Tab | Rules | Frontend notes |
|---|---|---|---|
| 10.15 | Security (password protection) | Basic auth for the site: on / off, username + password (generate), a when-to-use hint | Narrower than it sounds — this is only the password wall. The generated password follows the show-once rule, and the "when to use" hint is worth keeping: people turn this on for staging and forget |
| 10.16 | Firewall | Web firewall (7G / 8G WAF) on / off and options | |
| 10.17 | Bot blocker | AI bot blocker rules + bot traffic | The traffic view is what makes this trustworthy: it shows what was actually blocked |
| 10.18 | Fail2ban | App Fail2ban on / off and settings | Login protection for this site, separate from the server's own Fail2ban |
All four change what visitors experience, so each needs a visible state on the app's Overview (the protection summary in 10.2) — a user debugging a blocked visitor will look there first.
#E. Central's own rules on top of the OSS tabs
| # | Rule | Frontend notes |
|---|---|---|
| 10.21 | Plan limits — app features join the plan feature list (7.2). As in V7 the Free plan starts without workers, app security, web firewall, a separate database server and multiple domains per app. The admin can change this per plan | The named plan and its exclusions are the admin's starting data, not frontend constants — the same rule as everywhere else in this spec. So the app menu hides or disables tabs from the plan feature list, and the refusal is the shared "upgrade your plan to use this" pattern, never a hard-coded list of what Free lacks |
| 10.22 | Permissions — every feature above has view / manage for organization roles and shared servers (Phase 4), as in V7 | So the app menu is permission-driven item by item, exactly like the server menu. The permission names are still unpublished, so checks come from the API catalogue |
| 10.23 | App activity log — who did what on this app, read from OSS | Worth noting against Phase 11: notifications deliberately do not read the OSS activity log (11.11), but this screen does. So the app's own history is complete while the notification feed only covers what Central did — two different things, and the screens should not imply otherwise |
#Where these tabs live — four of them are not in the fixed app menu
The frontend doc's app menu order is fixed (Bhavik). Mapping the backend's tabs onto it leaves four unplaced:
| Backend tab | In the fixed app menu? |
|---|---|
| 10.2 Overview · 10.4 Domains & SSL · 10.8 Environment · 10.14 Workers · 10.5 Files · 10.6 Logs · 10.11 Backups · 10.15 Security · 10.16 Firewall · 10.17 Bot blocker · 10.18 Fail2ban · 10.13 Clone | Yes — in that order (Dashboard, Domains & SSL, Environment, Workers, Files, Logs, Backups, Password Protection, Web Firewall, AI Bot Blocker, Fail2ban, Site Clone) |
| 10.9 Deployment · 10.7 PHP · 10.12 Staging | Yes, as the type-only items |
| 10.10 Databases · 10.19 Container & Compose · 10.20 Settings · 10.3 App actions | Not placed — see D-40 |
Container & Compose is type-only and would fit alongside Deployment and PHP. App actions look like header actions rather than a tab. Databases and Settings have no obvious home. The menu order is Bhavik's decision, so nothing has been reordered here.
#Waiting for the team's decision — ten V7 features OSS does not have
The list grew from eight to ten in the rewrite (backups of deleted servers and Node app Nginx config + SSR port, the V7 MERN case, were added).
| V7 feature | Why it matters here |
|---|---|
| WordPress blueprints | This site has a whole Blueprints page, a frontend-doc section and a roadmap phase — see the callout below |
| App tags + an all-apps list across servers | Overlaps the new-in-V8 tags idea in the frontend doc, which is currently server-only |
| Restore a backup to another server · backups of deleted servers | 10.11 restores to the same server only, so neither can be offered yet |
| Site migration from another host | A V7 selling point with no OSS equivalent |
| Maintenance mode for all apps | OSS has it for WordPress only, so no global switch |
| Cloudflare DNS manager · temporary domain | Both would live on 10.4; without them DNS is a manual, copy-the-record job |
| "Update app" buttons for non-Docker apps | Only Docker apps get an update path (10.19) |
| Node app Nginx config + SSR port | The V7 MERN case; without it, Node apps are service-managed only (10.14) |
#Add-on phases, not here
WP Toolkit, InsightHub / log monitoring, Object Cache Pro and self-hosted white label are explicitly out of Phase 10 — the third phase in a row to name InsightHub as later work.
#Existing users
All of a user's apps stay on their servers (in OSS); Central just shows them, and every feature follows the same user flow as V7. So there is no app migration to design — but the screens must cope with apps created long before Central existed, including ones relying on a feature whose V7 equivalent is on the undecided list.