d6cebb337109616dab2d42955f43633c02479073
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 menzeljandClaude Opus 5.5
|
d6cebb3371 |
Fix what a review of the whole app found, end to end (0.67.1)
A pass over every feature against a real Docker daemon, then clicking through the UI as admin and read-only user, on a desktop and a phone. Security. /ws/deploy ran compose up for the read-only role; it is admin-only now. A container's inspect view, a stack's compose file (POSTGRES_PASSWORD: hunter2) and the viewer's .env tab no longer show credentials to that role. Git branch and URL values that git would read as options (-x, ext::) are refused. SFTP host keys are checked: pinned on first use or entered by hand (key line or SHA256 fingerprint), a different key is refused before the password is sent. A backup name from the API can no longer reach outside the destination folder. The file browser refuses to move or rename a browse root, as delete did. Docker lifecycle. Closing the deploy console released the stack lock while compose was still running and logged rc=None as success; deploys and updates are now background runs that hold the lock to the end, report the real exit code and can be re-attached to. Every closed log view left a `compose logs -f` behind. A dozen open tabs exhausted the default thread pool and hung the API; event and exec streams have their own threads. Auto-update and the update endpoint ignored failed pulls. A deleted git stack was recreated and started by the next webhook or poll; deleting a stack now drops its git source, auto-update policy and schedule entries. Deleting no longer walks into mounted shares, is refused while a backup runs, and removes the containers even when the compose file is broken. Stack folders compose has to normalise (Nextcloud -> nextcloud) work everywhere and group correctly on the volumes, networks and images pages. Detection. Host port conflicts read the container's own network namespace; /proc/1/net is read instead. Images referenced as docker.io/… were never update-checked; local builds no longer report "needs credentials". NVIDIA GPUs are read from the driver's procfs. The backup dialog's "path mismatch" warning came from mountinfo's filesystem-relative root and fired for any stacks folder on its own disk, ZFS dataset or btrfs subvolume; the host path now comes from Docker's mounts. Backups and destinations. The download ignored the folder/volume selection (axios sent binds[]). Restoring under a new name kept the old one. A report header past nginx's buffer turned a good backup into a 502. SFTP/S3 errors were bare 500s and "Test" did not try to write. A destination used by a schedule could be deleted. Backup file names are in the schedule's or the browser's time zone instead of UTC. Editor and converter. `docker run` conversion produced invalid compose for --network host, named volumes and -dit; --gpus and --mount were dropped; a multi-line command pasted into the one-line field became `image: ' '` (now a textarea, and flattened continuations are read). Validation failed for env_file stacks. The editor overwrote unsaved edits on every container event, lost them on a stray click (now asks), threw when closing the diff, and its helper panel listed the starter service "app" for every existing stack. Monaco is bundled instead of loaded from jsdelivr, so the editor works offline (and monaco-editor 0.57 drops the dompurify advisory; axios and react-router updated). UI. All times were two hours off: offset-less UTC from SQLite was read as local time, and "next run" always said "just now". A token refresh mid-session duplicated deploys, reset terminals and doubled logs. A backend restart (update, self-update) signed everyone out on reload; the page now waits for it. The editor was unusable on a phone, tables and tabs overflowed, dialog text was black on the dark theme, and the file browser opened on an error with the default roots. Read-only users get "Admin only" pages instead of 403s; in-use networks offer no delete; "Scan all" covers StackPilot's own stacks only and runs in the background instead of timing out at 600s. Deployment. nginx passes the port in Host (the OIDC redirect URI lost :5009) and keeps an outer proxy's X-Forwarded-Proto. The frontend waits for a healthy backend (healthcheck probes every 2s while starting). The frontend image builds with npm ci. Secrets are 0644 in a 0700 folder so non-root containers can read them; existing files are fixed at startup. The test suite no longer starts real containers on a host with Docker. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Fx7gcuy8d6nPd95g43rGHu |
||
|
menzeljandClaude Opus 5
|
57231e4a67 |
Show live progress while pruning volumes, and ask first (0.62.0)
The volume prune gets the same treatment as the image prune in 0.61.0:
the candidates are listed and removed one by one in the background, and
the Volumes page shows a progress bar (x / y, the volume being removed,
failures) followed by a toast with the space freed.
The button also used to delete without asking, and a bare docker volume
prune only removes anonymous volumes on Engine 23+ with no way to include
named ones. It now opens a confirmation dialog with an explicit -a option
that warns it also takes the data of every stack that is down.
- Candidates: volumes no container (running or stopped) mounts, local
scope only, and anonymous (com.docker.volume.anonymous) unless -a.
Volumes from pre-23 daemons carry no such label, so they only go with
-a, which errs on the side of keeping data.
- Removed without force, so a volume mounted since the listing is
refused; one refusal does not stop the rest.
- No closing daemon prune: nothing is left over, and on a pre-23 daemon an
unfiltered one would delete named volumes too.
- Freed space is the sum of the deleted volumes' sizes (volumes share no
data), from the size cache, which is invalidated afterwards.
- POST /api/volumes/prune takes all= and background=; without background
it still waits and returns {VolumesDeleted, SpaceReclaimed}.
GET /api/volumes/prune-status is admin-only.
- volume_sizes() ("Compute sizes") now uses the long-timeout client; it
walks every volume and could hit the same 60s limit.
The progress machinery moved into services/prune_job.py (PruneJob,
PrunePlan) and, on the frontend, the usePruneJob hook and PruneProgress
component, shared by both pages. The status now carries a phase
(preparing / removing / finishing) so the parts without a count say what
they are doing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
menzeljandClaude Opus 5
|
a2adb59526 |
Group Images and Networks by stack, like Volumes (0.55.0)
The same argument as 0.54.0: these pages already sorted a stack's resources next to each other, and still made you read prefixes to work out where one stack ended and the next began. Networks are the clearest win — compose names a stack's own network <project>_default, so the column was almost entirely prefix. Doing it a second and third time made the shape obvious, so the grouping is now one function and one heading component shared by all three pages rather than three copies drifting apart. A stack looks and sorts the same wherever it turns up. volumeGroups.ts became stackGroups.ts on the way, and the Volumes page moved onto it with no behaviour change. Images forced the model to grow, and this is the part worth reading. An image carries no compose label — the backend derives its owners from the containers running it, so ownership is a *list*, and postgres:16 may belong to four stacks at once. Listing it under each owner would show the same image four times with four sizes, and a page that adds up to more disk than the host has. So anything with more than one owner is listed once in a "Shared by several stacks" group, and the Used by column names them. Each resource appears exactly once, which keeps the per-group totals honest. Networks needed a second new kind. bridge, host and none belong to no stack, but they are not leftovers either, and dropping them into the unassigned group pads the exact list people scan for junk. They get their own group below it. The built-in check runs before ownership is even considered, so they can never be counted as unclaimed. Ordering is unchanged and now stated once: stacks by display name, then shared, then unclaimed, then built-ins. The trailing three are appended, never sorted in, so "unassigned at the bottom" holds whatever anything is called — there is a test for the case where the only real stack sorts after them. Group headings gained the counts each page can actually produce: volumes show unused and total size, images total size and how many have an update waiting, networks how many are idle. Both row bodies moved into their own components. Nesting them a level deeper inside the group left the indentation adrift, and the networks row had a second <tr> for its expanded detail riding along inside an already doubled map. Fifteen tests on the shared grouping, including the shared and built-in groups and a stack that has been deleted since. No server change: every one of these already knew its stack. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
menzeljandClaude Opus 5
|
76a228314a |
Plate only the logos that need one, instead of all of them (0.53.0)
0.52.0 put every app logo on a white tile. The reason was real — a good number of logos are solid black line art and vanish into a dark surface — but the cure was applied to all of them, and in dark mode that makes each row look like it has a sticker pasted on it. So the tile goes back to the same neutral surface everything else uses, and the decision is made per image. The browser already holds the bytes, so it draws each one into a 24px canvas once and measures it: no new dependency, no second request, and it covers uploads as well as catalog logos. Measuring luminance alone was the first attempt and it is wrong. It plates Home Assistant, whose logo is a mid-blue house that reads on anything, and it plates Plex, which is dark *orange* — mean luminance cannot see that hue is doing the work. So chroma is measured too, and a plate requires low contrast **and** art with essentially no colour of its own. The threshold sits between the logos that only look monochrome (Sonarr 0.115, Uptime Kuma 0.129) and the ones that are (MinIO 0.065, Memos 0.037). Checked against 66 real logos rather than guessed: six get a plate in dark mode (Vaultwarden, Tailscale, Frigate, Heimdall, Miniflux, MinIO, all solid black), two in light mode (Ollama, Open-WebUI, solid white). The other ~90% sit bare. Mid-grey art like Bazarr is deliberately left alone — it already has contrast against both grounds, and a plate would be noise. Every failure path returns "no plate": jsdom with no canvas, a blocked canvas, an image that will not decode. Being wrong in that direction costs contrast on a handful of icons; being wrong the other way is the sticker problem again. The unit test is built from the measured luminance/chroma pairs, so it tests the rule against the art it actually has to handle. 0.53.0 because 0.52.0's images are already in the registry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
menzeljandClaude Opus 5
|
b629d1b2c2 |
Use the apps' real logos as stack icons, fetched server-side (0.52.0)
0.51.0 gave every stack an icon, but a generic one: jellyfin got a clapperboard,
not the Jellyfin logo. Glyphs make a list readable; they do not make a stack
recognisable, which was the point. This resolves stacks against the selfh.st
icon catalog (~2900 self-hosted apps, the set Homarr and Homepage draw on), so
the row shows the thing people already recognise. All 83 bundled templates
resolve to their own logo.
The whole design question was *who* talks to the CDN. If the <img> points at
jsdelivr, then every client needs internet, every page load leaks the names of
somebody's stacks to a third party, and an air-gapped box gets nothing. So the
backend does it: the catalog on startup and weekly after, each logo once on
first use, both into ${DATA_DIR}/stack-icons/. Browsers keep reading icons from
the authenticated endpoint that already existed for uploads, and after the first
fetch the feature is fully offline. Logos are cached per *app*, not per stack —
verified: two stacks resolving to jellyfin produce one download.
Nothing here can fail loudly. Every entry point returns None rather than raising
when the network is absent, the catalog refresh is a task the lifespan does not
await, and an install with no outbound internet simply keeps 0.51.0's glyphs.
That fallback is also what covers a name the catalog does not know
("Mediaserver Wohnzimmer" is still a clapperboard), and the seconds after a
fresh install before the catalog lands. The glyph is derived even for stacks
that *do* have a logo, so an image that cannot be fetched degrades to something
meaningful instead of a box.
Matching gained a second source that turned out to matter more than expected:
the compose images. A stack called "medienserver" says nothing, but it pulls
lscr.io/linuxserver/jellyfin — strip the registry, the vendor and the tag and
the app is right there. Name first, then the longest run of words inside it,
then the images. It is deliberately cautious: a single word shorter than four
characters never claims a logo, because "web", "app" and "db" are all catalog
entries and a *wrong* logo is worse than a neutral glyph. A short alias table
covers what the catalog spells differently from Docker Hub (postgres →
postgresql, pihole → pi-hole, wg-easy → wireguard).
A slug arrives from the database and from query strings and then becomes a
filename, so it is pattern-checked before it is ever joined to a path, catalog
entries that are not slug-shaped are dropped on load, and a downloaded logo is
verified to start with the PNG magic bytes before being cached.
The picker searches the catalog too — pre-seeded with the stack's own name, so
opening it on "jellyfin" offers the Jellyfin logo first — which is how a wrong
match gets corrected, and how a stack can be given any app's logo on purpose.
Verified end to end against the live catalog and real downloads: list rows carry
the resolved logo, the icon endpoint serves real PNG bytes, an unmatched stack
404s (and falls through to its glyph), a hand-picked logo round-trips, reset
clears it, and a traversal slug 404s. 30 new backend tests and 12 new frontend
ones run without any network at all.
0.52.0 rather than amending 0.51.0: those images are already in the registry,
and rebuilding a published version tag with different content is exactly what
breaks the self-update checker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
menzeljandClaude Opus 5
|
7682460b4f |
Give every stack an icon, and put the status on it (0.51.0)
Stacks were a name and a coloured dot. The dot carried the status but nothing
carried identity, so a list of twenty stacks read as twenty identical rows.
This gives each one an icon in front of its name and moves the status onto that
icon as a halo in the status colour, which is the thing the eye lands on anyway.
The constraint that shaped the design: people already have stacks. Asking them
to pick an icon for each one before the feature does anything would mean it
never gets used, so the icon is *derived* from the stack's name and the column
stays empty until somebody overrides it. ~700 keywords in 79 groups cover the
self-hosted long tail (jellyfin -> clapperboard, vaultwarden -> key,
home-assistant -> house) plus generic English and German terms; the longest
match wins, so photoprism beats a bare photo, and short keywords like "tv" only
match as whole words. No backfill, no migration, and a rename moves the icon
with it.
That is also why the catalog and the matcher live in the frontend. It is the
only place that can render an icon, so a copy in the backend would be a list to
keep in sync and nothing else. The server validates the shape of the stored
value and stores uploads; it never needs to know what "lucide:database" looks
like. An icon name that later leaves the catalog falls back to the derived one
rather than blanking the row.
Overriding happens in two places, because there are two moments: the editor
(holding a chosen file until the stack exists, since uploading needs an id) and
a click on the icon on the detail page, which is how a stack that has existed
for a year gets one without a trip through the editor.
Uploads are classified by their bytes, not by the filename or Content-Type the
browser claims, and land in ${DATA_DIR}/stack-icons/ under the stack id. SVG is
allowed — <img> does not execute it — but the endpoint serves every icon as an
attachment so one can never be opened as a document in the API's own origin. A
client-supplied "custom:" value is refused: the server mints those, so a stack
cannot be pointed at a file it does not own. Files follow the stack: replaced on
re-upload (including across formats, or the old one orphans), copied on clone,
removed on delete.
The one piece of plumbing worth knowing about: the icon endpoint needs the
bearer token like everything else, and an <img src> would not carry it. So
StackIcon fetches the bytes through the API client and renders the blob, keyed
on the stored value — which carries an upload timestamp precisely so a re-upload
changes the key and retires the cached image.
Covered by 22 backend tests (the value rules, byte-sniffing, the file lifecycle,
the API round-trip, and that the read-only role cannot change an icon) and 29
frontend ones for the matcher. The schema change was verified against a
hand-built pre-0.51 database: the column is added on start and existing rows
come back NULL, i.e. automatic. Not click-tested in a browser — no Docker in
this environment — so the row height the taller icon produces is unverified.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
menzeljandClaude Opus 5
|
a25741f579 |
Add an error boundary and split the bundle (0.50.0)
F15 — Two unrelated frontend weaknesses. A render error unmounted the whole React tree: a white window, no navigation, no indication of what happened, and the only way out was knowing to reload. ErrorBoundary now shows the message with a retry and a reload, and clears itself when resetKey (the route) changes, so navigating to a working page just works instead of staying stuck. There are two: one inside AppShell around the routed pages, one at the root for the shell itself and the login screen, which sit outside it. The bundle was one 841 kB file (234 kB gzipped) every visitor downloaded in full, with Vite warning about it on every build. Routes are lazy now and the entry chunk is 377 kB (120 kB gzipped) — a 55% cut, warning gone. Measuring first changed what to split. Monaco turned out not to be in the bundle at all: @monaco-editor/react loads it from cdn.jsdelivr.net, so only the small wrapper ships. xterm.js *is* bundled, all 294 kB of it, and it was reachable from ContainerCard — which renders on every stack detail page — so every visitor paid for a terminal most never open. It is lazy now and lands in its own chunk. (Worth knowing separately: the compose editor therefore needs jsdelivr.net reachable. For a self-hosted tool on an air-gapped network that is a real limitation, but vendoring Monaco means +3 MB and is its own change.) Adding a boundary whose behaviour I could only reason about was not good enough, and the missing frontend test runner was already flagged as the gap from 0.49.0. So this also sets up vitest + jsdom + testing-library and covers the boundary: that it renders the error rather than a blank page, offers a way out, clears on navigation, and stays put on an unrelated re-render. CI runs `npm test` next to pytest. One snag worth recording: installing the dev dependencies triggered npm's optional-dependency pruning and dropped @rollup/rollup-linux-x64-gnu, which broke the build. Reinstalling it directly put a linux-x64-glibc binary in package.json, which would have broken `npm ci` on every other platform — so that was backed out and the lockfile now carries the bindings as rollup's optional deps, where they belong. Verified with a clean `npm ci` in a scratch copy: install, typecheck, build and test all pass from the committed lockfile. 758 backend tests, 7 frontend tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Dk43rmEeRfYi5wsLDbmfyG |
||
|
menzeljandClaude Opus 5
|
f6f82245f7 |
Keep the progress bar on one line, and portal modals out of the top bar (0.42.1)
CI / build-and-push (push) Successful in 1m48s
The stacks-list bar sat below the name and grew the row when an action started. It now runs inline to the right of the name and service count, filling the space before the CPU column, so the row keeps its height. Label, percentage and byte detail sit on that same line. Also fixes the self-update prompt being cut off at the top. The top bar is backdrop-blurred, and a non-none backdrop-filter makes an element the containing block for `position: fixed` descendants — so the dialog centred itself in the 60px header instead of the viewport and overflowed off-screen. ConfirmDialog and the update overlay now render through a portal on document.body. ConfirmDialog also scrolls itself rather than its backdrop, which would otherwise strand its top edge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016pMmFFkdfxkoYjcEcpZTa5 |
||
|
menzeljandClaude Fable 5
|
34cb215266 |
Phase 24: Design System v2 — analytics-style UI (0.30.0)
- New /api/dashboard/funnel (5-stage stack health, 30s TTL cache) and /api/dashboard/summary (containers, daily uptime jsonl, ops activity) - Token system (tokens.css + Tailwind sp-* aliases); legacy bg/card/accent remapped onto the tokens; Schibsted Grotesk bundled via fontsource - TopNav pill navigation + AppShell replace the sidebar layout (off-canvas drawer below 1024px); central display-weight page titles - Dashboard redesign: FunnelChart (gradient/hatch SVG waterfall), container count card with per-host bars + Insights chip, UptimeChart, OpsGrid, AiPromptBar; 30/7-day range selector; host sections retained below - Stacks page honours ?q= / ?filter= deep links + new status-filter select Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
menzeljandClaude Opus 4.8
|
a4e26f880a |
Phase 9: network management + stack delete in UI (0.9.0)
- Networks: network_service (list w/ subnet/containers/in-use/owning-stack, create bridge/macvlan/ipvlan/overlay + optional subnet/gateway/internal, delete with default-network guard, prune) + routers/networks.py; real Networks page replaces the placeholder. - Fix: local stacks can now be deleted from the UI — Delete button on stack detail (with optional keep-files-on-disk) and a trash action on stack cards, via a shared ConfirmDialog. (Backend DELETE existed; no UI surfaced it.) Verified: py_compile, frontend tsc build, live network list smoke test (defaults flagged, compose nets + in-use detected); main 104 routes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
menzeljandClaude Opus 4.8
|
f732cb080b |
Initial commit: StackPilot Phase 1 (Core)
Self-hosted Docker Compose manager. - Backend: FastAPI + docker-py + SQLite (JWT auth, file-first stacks, lifecycle, live status, WebSocket logs, docker-run converter, audit log) - Frontend: React + Vite + Tailwind (login/setup, dashboard, stacks, stack detail, Monaco editor, dark/light theme) - Deployment: docker-compose.yml, Dockerfiles, nginx reverse proxy Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |