#Servers

Phase 9 (2026-10-17): Pair 2 started the server panel — Step 0 groundwork (Ready-only, permission per screen incl. Docker / panel update / service monitoring, OSS data passed through, oss_message errors). Screens come step by step.

Phase 8 status (2026-10-16 10:59, Pair 2): 8.1 (all 5 cloud providers), 8.3, 8.4, 8.5, 8.7, 8.9–8.12 built & pushed. 8.8 checks built except plan active / server limit (wait for Phase 7) and provider enabled by admin (waits for the admin panel). Pending: 8.2 managed (waits for Billing — no user screen anyway, D-36) and 8.6 Lite (waits for Phase 10 + Phase 12 Control Panel). Still needs the OSS installer update before install-based ways go live.

Phase 8 Step 4 (2026-10-16): 8.1 cloud server — all five providers built (DigitalOcean, Vultr, Hetzner, Linode, Lightsail) (Pair 2, API71–75): account → region → size + Ubuntu + stack + optional SSH key → Creating → install progress; Retry on the same droplet; Delete can also delete the droplet. Other providers one by one. Cloud server.

Phase 8 Step 3 (2026-10-16): 8.3 root password built (Pair 2, API69–70): name + stack + public IPv4 + SSH port + root password → Central checks Ubuntu/CPU over SSH, starts the installer → same progress as the install command; Retry asks for the password again. Install APIs renumbered: 66 retry, 67 delete (one delete for all servers). Root password.

Phase 8 Step 2 (2026-10-15): 8.4 install command built locally (Pair 2 33bd7c0, API65–68, not pushed): name + stack, official OSS command, live progress, Ready → create admin in the panel, Retry/Delete on failure. Needs the OSS installer update before release. Force cleanup dropped. Install command.

Phase 8 latest (2026-10-14): Step 0 pushed (2899bd1); 8.5 Connect an existing OSS panel + server list/view built and pushed (Pair 2 API62–64, up to 5be6dec; response field system_info (was facts); tested live on an OSS test server; API address (https://api.…) + token only — panel web address refused with oss_not_a_panel). Next: 8.4 → 8.1 → 8.3. Connect a panel.

Phase 8 build plan (Pair 2, 2026-10-12): Pair 2 builds Servers in steps — Step 0 foundation → 8.5 connect OSS panel → 8.4 install command → 8.1 own cloud account → 8.3 root password; 8.2 managed + 8.6 Lite later. 8.8 plan-active/server-limit checks skipped until Phase 7 is built. Step 0 foundation built locally 2026-10-13 (4a375e9, not pushed) — no server endpoints yet, so no server screen can be wired. Account and organization delete are now refused while servers exist. Add a server.

In V8 a "server" is an OSS panel linked to an organization. Central keeps only a link record. Everything else is read live. V8 requirement R5

#Connecting an existing server

User provides: server name, panel (API) address, Central key.

# 1. On the OSS panel (admin session) — creates or rotates the key, shown once
POST https://api.<panel-host>/api/central/enable
201 {"central_token": "sv_central_…", "message": "…"}

# 2. Central backend — reachability + version (no auth)
GET https://api.<panel-host>/api/health
200 {"health": {"status": "ok", "version": "1.0.14"}}

# 3. Central backend — key check (signs in as the machine admin)
GET https://api.<panel-host>/api/auth/me
Authorization: Bearer sv_central_…
200 {"user": {"username": "central", "is_admin": true, …}}
401 {"message": "Unauthenticated."}        # wrong / revoked / rotated key

# 4. First data for Server Details
GET https://api.<panel-host>/api/server/facts
200 {"facts": {"hostname": "srv1", "os": "Ubuntu 24.04 LTS", "public_ip": "…", "cpu": {…}, …}}

Getting the key: on the OSS panel, an admin opens Admin → Central and clicks Connect. POST /central/enable returns central_token once. Enabling again rotates it, and the old key stops working at once. OSS API

The demo uses sm_<hex> "Server Management Key" in the same wizard. The real format is sv_central_…. Demo UI only Conflict (cosmetic; follow OSS)

#Link record — answered by 8.11 (was Q1)

#States

A background job (Horizon) refreshes status every few minutes, so lists don't wait on servers. Missing Assumption interval. Phase 9 adds a related job that acts, not just reads: service monitoring (9.25) is switched on per server with its own check interval, and Central restarts services it finds down — so a screen must say that before the toggle. Refreshing the server facts, and the "needs a new token" state, are still the backend's Q3 Open question.

Plan-expired state on top of the above (Phase 7, 7.12, 2026-10-05) V8 requirement: while the owner's plan is expired, the server pages stay readable and only two actions survive — Delete server and Add credit. Everything else is disabled with "Plan has expired. Please renew it". Don't blank the pages; disable the controls. And because auto-renew retries daily until the lock day (7.10), adding credit brings everything back without a Renew click. The end of that road differs by server type: a managed server is powered off at the warning day and deleted at the provider at the lock day; a self-managed server is only removed from Central and keeps running. So the expiry warning must name the servers and say which happens to which, and the locked screen may only promise "still at your provider" for self-managed ones.

Billing states on top of the above (Phase 6, 6.12, corrected 2026-10-05) V8 requirement: a managed server can be powered off because of unpaid credit and still be in the list with its deletion date, which must not be shown as offline — the user fixes it with credit, not with Retry. On the expire date the outcome splits by content: a server with no apps and no databases is deleted, the others are powered off, so the warning before it must name which servers face which. Adding credit later does not power a server back on (6.13, confirmed 2026-10-05): the deletion threat goes away and the saved dates are cleared, but the server stays off until it is started again — so never show a top-up as having "restored" it. (The earlier "backups, SSL renewals and health checks stop" state came from Phase 6's wallet track, which Pair 1 removed on 2026-10-05 — it is gone.)

#Remove / disconnect

Removing a server means disconnecting it from Central. The server and its sites keep running. V8 requirement (no server deletion in OSS)

Phase 9 (2026-10-06) separates the two words. Disconnect (9.8) leaves the server completely alone. Delete (9.5) removes it from Central with an optional "also delete at the provider" — which is not optional for managed servers, where the provider deletion always happens. Two very different outcomes, so the confirm has to say which one the user is about to get.

Destroying a VPS created through a provider is a separate, explicit action (provider API), and only if the backend supports it Open question.

#Edge cases