Remove the remote-host (agent) integration (0.48.0)

StackPilot now manages exactly one Docker host: the one it runs on. The
stackpilot-agent sidecar and everything that proxied to it are gone — 4721
lines deleted against 657 added.

Deleted outright: agent/ (image, compose, env), agent_app.py, models/agent.py,
routers/agents.py (1200 lines), services/agent_service.py, the agent API client,
RemoteStackDetail, the host components and AgentStacksSection. That removes 57
API routes and the three /ws/agent-* proxies.

Threaded out everywhere else, which was the bulk of the work. Every API module
carried an optional agentId that switched the base path; every page that listed
Docker objects rendered one section per host behind a HostHeader; Files had a
host switcher; the New Stack editor and the template dialog had host selectors;
schedules, auto-update policies and stack summaries carried agent_id. All of it
is gone, and the typechecker drove the sweep — 85 files touched, tsc and the
build clean.

Two things the removal exposed as dead weight rather than merely unused:

compose_service kept an in-process busy set purely because the agent needed a
lock and has no database. With the agent gone that was a second source of truth
next to the real DB lock, so it is deleted; compute_status now reports only what
the containers say and the two callers that want "updating" overlay the lock.
StacksTable's linkBase prop only ever existed to point at /hosts/{id}/stacks.

The dashboard's "Hosts 1/1 online" KPI can no longer say anything else, so the
tile and the KPIs behind it are gone and the row is five wide.

Upgrading matters here. An existing install still has an agent table holding
each remote host's URL and bearer token — full Docker control of that host,
sitting in the database with nothing left to use it. _drop_removed_schema drops
it on first start, and drops the agent_id columns where the SQLite build
supports DROP COLUMN. Each statement runs in its own transaction on purpose: a
failed DDL poisons the transaction it is in, so sharing one would let an
unsupported column drop take the table drop down with it. test_agent_removal
covers both branches plus the fresh-install and idempotent cases, and an
end-to-end run against a seeded pre-0.48 database confirms the table is gone and
every /api/agents route answers 404.

Docstrings that justified a design by "shared with the agent, which has no
database" were rewritten rather than left lying: update_service's persistence
callback and image_status_store are still the right split (registry logic stays
testable without a database), but for that reason now, not the old one. The
README's multi-host sections are removed and an upgrade note explains what to do
with running agent containers; ROADMAP keeps its history behind a note saying
the feature it describes no longer exists.

CI no longer builds or pushes stackpilot-agent.

735 tests pass, ruff and tsc clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Dk43rmEeRfYi5wsLDbmfyG

README.md

@@ -4,17 +4,43 @@ A self-hosted Docker Compose manager for power users and homelab enthusiasts —
 as intuitive as Dockge, as capable as Portainer for Compose workflows.
 
 > **Status:** Phase 1 (Core) + Phase 2 (Volumes & GPU) + Phase 3 (Quality of
-> Life) + Phase 4 (Operations) + Phase 5 (Multi-host) + Phase 6 (Backup
-> destinations) + Phase 7 (Scheduled backups) + Phase 8 (Remote-stack backups)
-> + Phase 9 (Networks) + Phase 10 (iGPU passthrough) + Phase 11 (Remote UX &
-> network attach) + Phase 12 (File browser) + Phase 13 (Multi-host networks &
-> images) + Phase 14 (Multi-host file browser) + Phase 15 (Dashboard stack
-> resource usage) + Phase 16 (Volumes page, multi-host) + Phase 17 (Multi-host
-> dashboard) + Phase 18 (Image prune) + Phase 19 (Compose validate & diff) +
+> Life) + Phase 4 (Operations) + Phase 6 (Backup destinations) + Phase 7
+> (Scheduled backups) + Phase 9 (Networks) + Phase 10 (iGPU passthrough) +
+> Phase 11 (Network attach) + Phase 12 (File browser) + Phase 13 (Network &
+> image management) + Phase 15 (Dashboard stack resource usage) +
+> Phase 16 (Volumes page) + Phase 18 (Image prune) + Phase 19 (Compose validate & diff) +
 > Phase 20 (Container management) + Phase 21 (Container terminal) + Phase 22
 > (Auto-update) + Phase 23 (Secrets & configs) + Phase 24 (Design System v2)
 > complete.
 
+## Upgrading to 0.48.0 — remote hosts are gone
+
+The multi-host feature (the `stackpilot-agent` sidecar and everything that
+proxied to it) has been removed. StackPilot now manages exactly one Docker
+host: the one it runs on.
+
+**If you never registered a remote host, nothing changes for you.** Otherwise:
+
+- **Stop and remove your `stackpilot-agent` containers.** They will simply sit
+  there unused; nothing talks to them any more. The `stackpilot-agent` image is
+  no longer built or published.
+- **Registered hosts are deleted from the database on first start**, together
+  with the bearer tokens they held. That is deliberate: leaving credentials for
+  a feature that no longer exists is worse than dropping them.
+- **Backup schedules that targeted a remote stack will fail** with "stack not
+  found" until you delete them under Settings → Scheduled backups. Their
+  `agent_id` column is dropped where SQLite supports it.
+- **Stacks that lived on a remote host are untouched on that host** — StackPilot
+  just no longer sees them. Their compose files are still in that host's stacks
+  directory and `docker compose` still works there, which is the point of the
+  file-is-the-truth model.
+
+Gone with it: the host switcher on the Files page, the per-host sections on
+Stacks / Networks / Images / Volumes / Dashboard, the host selector in the New
+Stack editor and the template dialog, Settings → Remote hosts, and the
+`/api/agents/*` and `/ws/agent-*` endpoints (57 API routes and 3 WebSocket
+routes in total).
+
 ## Upgrading to 0.47.0 — nothing to do
 
 Three pieces of state moved out of process memory and into the database, and
@@ -112,7 +138,6 @@ it is what your saved destination credentials are encrypted with.
 - **Live deploy console** — deploying from the editor streams `compose up`
   output (image pulls, container creation) over a WebSocket in real time instead
   of a blind spinner; the deploy keeps running server-side if the modal is closed.
-  Works for **remote** stacks too — the central app proxies the agent's deploy
   stream through to the browser. Compose runs with `--progress json`, so the
   console shows a **real progress bar** (download bytes per layer, weighted by
   layer size, then container create/start) plus a per-image bar; the raw output
@@ -205,17 +230,6 @@ it is what your saved destination credentials are encrypted with.
 - **Audit log page** (admin): searchable, paginated view of all recorded actions.
 - **Mobile-responsive layout**: off-canvas sidebar + adaptive spacing.
 
-### Phase 5 — Multi-host
-
-- **Remote agents**: deploy `stackpilot-agent` (same image, different CMD) on any
-  host — it needs only the Docker socket and a shared `AGENT_TOKEN`, and exposes a
-  slim, token-guarded stack/system API (no UI, no DB).
-- **Central management**: add hosts under **Settings → Remote hosts** (name, agent
-  URL, token) with a live connectivity dot. The Stacks page groups stacks by host
-  ("This host" + one section per agent); remote stacks have their own detail view
-  with full lifecycle (start/stop/restart/pull/update/down), live logs, and
-  compose/.env editing — all proxied to the agent.
-
 ### Phase 6 — Backup destinations
 
 - **Off-box backups**: define **SFTP**, **S3-compatible** (MinIO, Backblaze B2,
@@ -226,7 +240,7 @@ it is what your saved destination credentials are encrypted with.
   config changes) and file I/O runs through throwaway helper containers.
 - **Push & restore**: the stack Backup dialog can push straight to a destination
   instead of downloading; the Restore dialog can browse a destination's backups
-  and restore (volumes included) directly from it. Remote backups can also be
+  and restore (volumes included) directly from it. Backups can also be
   deleted from the UI.
 
 ### Phase 7 — Scheduled backups
@@ -239,16 +253,6 @@ it is what your saved destination credentials are encrypted with.
 - **Run now** for an on-demand run, plus a `backup_failed` notification event
   wired into the webhook system.
 
-### Phase 8 — Remote-stack backups
-
-- **Back up agent stacks**: the agent exposes its own backup/restore endpoints,
-  and the main app streams a remote stack's backup through to a destination
-  (credentials stay central — agents never see them). Remote stack detail has a
-  **Backup** button; each host section on the Stacks page has a **Restore** button.
-- **Schedule remote stacks**: a backup schedule can target a remote host; backups
-  are namespaced per host (`backup-<host>-<stack>-…`) so retention never prunes
-  across hosts sharing a destination.
-
 ### Phase 9 — Networks
 
 - **Network management**: the Networks page lists Docker networks (driver, scope,
@@ -268,14 +272,8 @@ it is what your saved destination credentials are encrypted with.
   resolve inside images, so the numeric GID is what actually grants access. The
   GPU selector shows the detected GIDs; removal cleans them (and `LIBVA_DRIVER_NAME`).
 
-### Phase 11 — Remote UX & network attach
+### Phase 11 — Network attach
 
-- **Live remote logs**: remote-stack logs now stream over a WebSocket proxied
-  through the central app to the agent (`/ws/agent-logs/{agent}/{stack}`), instead
-  of polling — same live viewer as local stacks.
-- **Deploy to a remote host from the UI**: the New Stack editor and the template
-  dialog gained a *host* selector. Pick an online agent and the stack is created
-  (and optionally started) on that host; you land on its remote detail page.
 - **Network attach/detach**: each network row on the Networks page expands to an
   inspect view listing connected containers, with admin controls to disconnect a
   container or connect any container on the host (`POST /api/networks/{id}/connect`
@@ -285,7 +283,7 @@ it is what your saved destination credentials are encrypted with.
 
 - **New shell**: the sidebar is gone — a fixed 60px top bar carries a pill
   navigation (active route = dark pill), the logo mark, a version badge, a
-  remote-host online indicator, theme toggle and an avatar menu. Narrow
+  theme toggle and an avatar menu. Narrow
   screens get an off-canvas drawer.
 - **Design tokens** (`frontend/src/styles/tokens.css`): one CSS-variable set
   for surfaces, borders, text tiers, brand colours, radii and type scales,
@@ -299,7 +297,7 @@ it is what your saved destination credentials are encrypted with.
   auto-update policy). SVG waterfall with alternating gradient /
   diagonal-hatch bars, value chips and hover conversion/drop-off tooltips.
 - **Summary widgets** from `GET /api/dashboard/summary`: compose-containers
-  card with per-host breakdown (agents report a compose-only count) and an
+  card and an
   "Insights" chip (healthy-rate %), a 30-day uptime line chart (sampled every
   5 min into `DATA_DIR/uptime.jsonl`, charted as daily averages), and an ops
   contribution grid from audit-log activity with the peak weekday.
@@ -323,9 +321,7 @@ it is what your saved destination credentials are encrypted with.
   compose file is rewritten in place (top-level `secrets:`/`configs:` defs are
   pruned when no service still uses them); **redeploy the stack to apply**.
 - **Admin-only** (secrets are sensitive); every write/delete/attach/detach is
-  audited (`secret.*`). Works for **remote stacks** too — the agent stores the
-  files on its own host (`/agent/stacks/{id}/secrets/*`, proxied via
-  `/api/agents/{id}/stacks/{id}/secrets/*`). Names are validated against path
+  audited (`secret.*`). Names are validated against path
   traversal (single component, no `..`, no leading dot); content capped at 1 MiB.
 
 ### Phase 22 — Auto-update (Watchtower-style)
@@ -337,10 +333,8 @@ it is what your saved destination credentials are encrypted with.
 - Runs inside the existing image-update-check cycle (reuses the freshly-computed
   digest cache, no extra registry calls). Only **running** stacks are
   auto-redeployed — a stopped stack is never silently started ("skipped").
-- New `stack_auto_updated` notification event. Works for **remote stacks** too
-  (policy stored centrally; the agent answers `/agent/stacks/{id}/updates` and
-  performs the redeploy). Last run + status (updated / up-to-date /
-  update-available / skipped / error) are shown inline.
+- New `stack_auto_updated` notification event. Last run + status (updated /
+  up-to-date / update-available / skipped / error) are shown inline.
 
 ### Phase 21 — Container terminal (web exec)
 
@@ -351,9 +345,6 @@ it is what your saved destination credentials are encrypted with.
 - **Admin-only** (exec is root-equivalent): a non-admin token is rejected at the
   WebSocket handshake (`4403`). Only containers with the
   `com.docker.compose.project` label can be reached.
-- Works for **remote stacks** too: the same terminal proxies through
-  `/ws/agent-exec/{agent_id}/{container_id}` to the agent's new
-  `/agent/ws/exec/{container_id}` (bidirectional — keystrokes in, output out).
 
 ### Phase 20 — Container management
 
@@ -365,9 +356,6 @@ it is what your saved destination credentials are encrypted with.
 - Admins get **per-container start / stop / restart** buttons directly on the
   card (`POST /api/containers/{id}/{action}`), so a single misbehaving service
   can be bounced without touching the rest of the stack.
-- Works for **remote stacks** too — the same card is used on the remote stack
-  detail page, proxied through `/api/agents/{id}/containers/*` to the agent's
-  new `/agent/containers/*` endpoints.
 - Only containers carrying the `com.docker.compose.project` label are exposed,
   so this never becomes a generic "control any container on the host" backdoor.
 
@@ -380,33 +368,17 @@ it is what your saved destination credentials are encrypted with.
 ### Phase 18 — Image prune
 
 - **Prune images** (dangling, or all unused) from the Images page, on the local
-  host and on each agent.
+  host.
 
-### Phase 17 — Multi-host dashboard
+### Phase 16 — Volumes page
 
-- The dashboard now shows, **per host** (local + each registered agent, online
-  dot / offline notice), a **resource overview bar** (CPU cores, memory
-  used/total, disk used/total, Docker volumes total, containers, Docker version)
-  and a **stacks-with-usage table** with CPU/memory meters and inline
-  start/stop/restart. The volumes total reuses the cached `/volumes/sizes`
-  lookup (`docker system df`), polled gently (~60s).
-- New agent endpoint `/agent/stacks/stats` (proxied at
-  `/api/agents/{id}/stacks/stats`); `/agent/system` now also reports `cpu_cores`,
-  `mem_total`, `mem_used`, and `disk_total`/`disk_used` (disk of the host volume
-  backing the stacks dir) so the remote resource bar and meters have a host
-  reference.
-
-### Phase 16 — Volumes page (multi-host)
-
-- **New Volumes page** (sidebar) with per-host sections (local + each online
-  agent, like Networks/Images). Lists Docker volumes with driver, owning stack,
+- **New Volumes page** (sidebar). Lists Docker volumes with driver, owning stack,
   in-use containers and mountpoint.
 - Admin actions: delete a volume (with an in-use warning + force option) and
-  **Prune unused**; an *Only unused* filter. New agent endpoints
-  `/agent/volumes` (list/delete/prune), proxied at `/api/agents/{id}/volumes/*`.
+  **Prune unused**; an *Only unused* filter.
 - **Volume sizes** are loaded on demand via a *Compute sizes* button (runs
   `docker system df`, which walks volume contents and can take a few seconds);
-  results are cached ~60s. Endpoint `GET /api/volumes/sizes` (+ per-agent).
+  results are cached ~60s. Endpoint `GET /api/volumes/sizes`.
 - The Volume **Wizard** in the stack editor (bind/named/NFS/SMB/tmpfs YAML
   generation) is unchanged — the new page is for managing/cleaning up volumes.
 
@@ -420,29 +392,14 @@ it is what your saved destination credentials are encrypted with.
   otherwise it shows absolute usage against the host total. Inline start/stop/
   restart actions per row for admins. New endpoint `GET /api/stacks/stats`.
 
-### Phase 14 — Multi-host file browser
+### Phase 13 — Network & image management
 
-- **The Files page now has a host switcher.** When agents are registered, a
-  *Host* dropdown at the top switches the whole browser between the local host
-  and any online agent; switching resets the path and clipboard.
-- All file operations (browse, view/edit, create, rename, copy/move, delete,
-  upload files & folders, download) work against the selected agent, sandboxed
-  by *that agent's* `ALLOWED_BROWSE_ROOTS`/`HOST_ROOT_PREFIX`.
-- New agent endpoints `/agent/files/*`, proxied at `/api/agents/{id}/files/*`.
-
-### Phase 13 — Multi-host networks & images
-
-- **Networks and Images are now per-host.** Both pages render a section for the
-  local host plus one for every registered agent (online dot included), exactly
-  like the Stacks page. Each agent section talks to that host's Docker daemon.
-- **Remote network management**: list, inspect, create, delete, prune, and
-  connect/disconnect containers on an agent host — including a *Prune unused*
-  button, which resolves the common "all predefined address pools have been
-  fully subnetted" deploy error without SSH.
-- **Remote images**: list image tags (with using-stacks) and run on-demand update
-  checks per host.
-- New agent endpoints `/agent/networks/*` and `/agent/images/*`, proxied through
-  the central app at `/api/agents/{id}/networks/*` and `/api/agents/{id}/images/*`.
+- **Network management**: list, inspect, create, delete, prune, and
+  connect/disconnect containers — including a *Prune unused* button, which
+  resolves the common "all predefined address pools have been fully subnetted"
+  deploy error without SSH.
+- **Images**: list image tags (with using-stacks) and run on-demand update
+  checks.
 
 ### Phase 12 — File browser
 
@@ -465,7 +422,7 @@ it is what your saved destination credentials are encrypted with.
 - **Sandboxed**: all access is confined to `ALLOWED_BROWSE_ROOTS`; path
   traversal and deleting a browse root are refused. StackPilot's own `DATA_DIR`
   is refused regardless of the setting — it holds `stackpilot.db` with password
-  hashes, agent tokens and backup-destination credentials, none of which the API
+  hashes and backup-destination credentials, none of which the API
   itself ever hands out. Note that a single `/` entry in `ALLOWED_BROWSE_ROOTS`
   switches the sandbox off entirely; it is no longer part of the default. To reach the real host
   filesystem, mount it into the backend and set `HOST_ROOT_PREFIX` (see the
@@ -474,17 +431,6 @@ it is what your saved destination credentials are encrypted with.
   `move`, `upload` — with optional `rel_path` for folder uploads —, `download`,
   `DELETE`).
 
-## Deploying an agent on another host
-
-```bash
-cd agent
-cp .env.example .env          # set a strong AGENT_TOKEN
-docker compose up -d          # exposes the agent on :5010
-```
-
-Then in the central UI: **Settings → Remote hosts → Add host** with
-`http://<that-host>:5010` and the same `AGENT_TOKEN`.
-
 ## Architecture
 
 ```
@@ -563,7 +509,7 @@ Same three commands the CI runs — `build-and-push` only starts once they pass.
 ```bash
 cd backend
 pip install -r requirements-dev.txt
-pytest                            # 729 tests, no Docker daemon needed
+pytest                            # 735 tests, no Docker daemon needed
 ruff check .
 cd ../frontend && npx tsc --noEmit -p tsconfig.json
 ```
@@ -573,14 +519,12 @@ never opens a Docker socket and never starts the background loops; `conftest.py`
 points `DATA_DIR`/`STACKS_DIR` at a temp directory before anything is imported.
 
 The load-bearing one is `tests/test_route_authorization.py`. Authorization lives
-in the routers — each of 171 routes independently picks `require_admin` or
+in the routers — each route independently picks `require_admin` or
 `get_current_user`, and nothing checked that the choice was right, which is how
 0.43.0 shipped a read-only role that could download the auth database. That file
 states the policy once — *every route requires admin unless it is listed* — and
 fails on any route that disagrees. Adding a route the `user` role may reach means
 adding it to `USER_READABLE` with a note on why it cannot return a credential.
-`tests/test_agent_authorization.py` does the same for the agent, where a single
-forgotten `Depends(verify_token)` would expose a whole host.
 
 `tests/test_token_revocation.py` covers the revoke switch — that each of the
 three authority changes kills the account's tokens, that a cosmetic re-save does
@@ -594,8 +538,8 @@ that moved into the database: that a busy stack answers 409 without ever
 reaching Docker, that an expired lock is taken over rather than stranding the
 stack, that the stats cache serves repeat callers from one sweep, and that the
 update cache and rate limiter survive a restart. One of them asserts that
-`update_service` never imports the database — it is shared with the agent,
-which has none, so persistence has to stay opt-in.
+`update_service` never imports the database — it is pure registry logic, and
+persistence stays opt-in so the module remains testable without one.
 
 `tests/test_bundled_templates.py` covers the 83 shipped templates: each must
 parse, name an image per service, keep `.env.example` in sync with the variables
@@ -648,22 +592,6 @@ GET    /api/auth/users                            POST /api/auth/users
 PATCH  /api/auth/users/{id}                        DELETE /api/auth/users/{id}
 ```
 
-### Phase 5 endpoints
-
-```
-GET    /api/agents                                POST /api/agents
-PUT    /api/agents/{id}                            DELETE /api/agents/{id}
-POST   /api/agents/{id}/ping                       GET  /api/agents/{id}/system
-GET    /api/agents/{id}/stacks | /{sid}            GET  /api/agents/{id}/stacks/{sid}/logs
-POST   /api/agents/{id}/stacks                     PUT  /api/agents/{id}/stacks/{sid}
-DELETE /api/agents/{id}/stacks/{sid}               POST /api/agents/{id}/stacks/{sid}/{action}
-
-agent (on the remote host, Bearer AGENT_TOKEN):
-GET    /agent/ping | /system | /stacks | /stacks/{id} | /stacks/{id}/logs
-GET    /agent/stacks/{id}/backup                   POST /agent/stacks/restore
-POST   /agent/stacks | /stacks/{id}/{action}       PUT/DELETE /agent/stacks/{id}
-```
-
 ### Phase 6 endpoints
 
 ```
@@ -682,14 +610,6 @@ PUT    /api/backups/schedules/{id}                 DELETE /api/backups/schedules
 POST   /api/backups/schedules/{id}/run
 ```
 
-### Phase 8 endpoints (remote-stack backups)
-
-```
-GET    /api/agents/{id}/stacks/{sid}/backup        POST /api/agents/{id}/stacks/{sid}/backup/push
-POST   /api/agents/{id}/stacks/restore             POST /api/agents/{id}/stacks/restore-from
-backup schedules accept an optional agent_id to target a remote host.
-```
-
 ### Phase 9 endpoints
 
 ```
@@ -701,10 +621,8 @@ DELETE /api/stacks/{id}?delete_files=             (stack delete, now surfaced in
 ### Phase 11 endpoints
 
 ```
-WS   /ws/agent-logs/{agent_id}/{stack_id}         (live remote logs, proxied to the agent)
 GET  /api/networks/{id}/containers                 POST /api/networks/{id}/connect | /disconnect
-POST /api/agents/{id}/stacks                       (create a stack on a remote host — now in the UI)
-POST /api/templates/{id}/instantiate {agent_id}    (instantiate a template onto a remote host)
+POST /api/templates/{id}/instantiate               (create a stack from a template)
 ```
 
 ### Phase 24 endpoints