One component per job, so pages stop hand-building them:
- ServerPicker: which machine; local first, capacity, capability filter
- CopyField: any value meant to be copied; secrets stay masked
- PortField: host ports checked live against /ports/check, naming the
app that holds a taken port and offering the next free one
- EnvEditor: KEY=value rows for forms; a pasted .env fills the rows
Call sites move onto them in the following commits.
The deploy paths already know which host ports are taken (app rows,
slot rows, Docker mappings, a bind test) but only used that to pick a
port silently. Exposing it lets the shared port input say "8001 is
used by shop-api" and offer the next free port, instead of failing
at deploy time.
Every screen that asked for a domain had its own input: a copied
regex in service settings, a separate "give it a subdomain" modal, a
bare required field on the Domains page. DomainField offers a managed
subdomain (label + base domain) or the user's own domain, normalizes
what is pasted, and says what will happen with DNS before submit.
attachDomain() sends either kind to the right endpoint.
Service settings now has one add-domain flow instead of an attach
form plus a subdomain modal, and the Domains page add modal uses the
same field.
The three remaining catalogs each had their own card: a 140px cover
banner with source, category, first-party and trust badges on
Extensions, a legacy SharedCard on Server Templates, and a bespoke
button card in the engine drawer. All three now use the shared
CatalogCard: one tag, author and trust as plain text, an outline
action, and a flat surface. Server-template facts also get singular
forms ("1 package", not "1 packages").
Extensions, templates, server templates and database engines each
drew their own card with their own badges. CatalogCard is the one
shape for browsable things: icon, name, version line, one plain-text
tag, a two-line description, facts and one action. Templates is the
first user; the icon-only website/docs markers and the hover-reveal
deploy button went with the old card.
The explorer drew its own toolbar with an h1 titled differently from
the sidebar entry and a hand-rolled New menu. It now uses PageLayout
like the other workbench pages, with the shared button and dropdown
primitives; the tree and workspace below are unchanged.
Docker was the one list page with its own layout: an inner sidebar
for Containers/Images/Volumes, an Inventory panel repeating the KPI
counts, and a bespoke workbar title. It now uses PageLayout like every
other standalone page, with those sections as top-bar tabs and the
target picker, prune and create actions in the bar. /docker redirects
to /docker/containers so the first tab lights up. The old sidebar,
workbar and container-card CSS was unused and is removed.
Section headings in Settings, the new-service wizard, Agent Fleet and
restore points each had a one-line description that restated the
heading. The Installed section header said "installed" three times.
Only lines that say something specific (what disabling a module does,
install instructions, user data) are kept.
Detail headers and table heads used a top-lit gradient plus a radial
accent wash. They are now a flat surface, matching every other card.
The old Servers card layout (hero, health panel, card grid, empty
state) was no longer referenced anywhere and carried most of the
remaining gradients, so it goes.
Vela holds one ServerKit API key as a host-side secret and polls the
fleet list, so this read route moves from bare @jwt_required() to
auth_required() + require_scope('servers:read') — a deliberate,
per-route jwt_only_census exception, not a sweep. JWT callers are
unchanged; a restricted key without servers:read gets 403 from the
scope middleware, no credentials get 401.
Scope choice: the existing servers:read catalog entry already covers
'list servers, agents, and metrics', and the serverkit-gui read routes
(capabilities/frame/surface, sibling repo) take the same scope, so one
key scope serves the whole Vela polling surface.
The census ceiling ratchets down to 600 and the migration inventory is
regenerated, as both ratchets require. tests/test_servers_api_key_scope.py
pins the four cases: scoped key 200, wrong-scope key 403, JWT 200,
anonymous 401.
Session keys must name their purpose, and both loopback legs skip
environment proxies so the grant and bearer token never leave the box.
In the tunnel the API always goes through the relay, which attaches the
grant, and the two raw root anchors become router Links so they stay
under the /t/<device> prefix.
The connect-session route authenticates by the loopback-only Cloud
grant rather than a session, and the tunnel's Socket.IO bridge starts
two raw threads; both guards failed CI until they were recorded.
Until now the connect client refused every http and sio stream, so
Open panel in ServerKit Cloud showed a blank page. The client now
bridges them to the loopback listener, the panel serves its page
under the relay's /t/<device>/ prefix, and the SPA prefixes its
router, API and Socket.IO paths from it. The Cloud grant is checked
against Cloud's JWKS before signing in the panel user with the same
email; panel two-factor still applies.
Registry logos drew at 44px beside 92px bundled icons, and the white
tile was picked by whether bundled art existed rather than by what
rendered, so a registry-only logo like Minecraft's sat on the gradient
meant for white glyphs. The cover now picks its tile from the image it
actually shows, and a failed logo drops back to the gradient.
TagsPanel and RemoteAccess named their .map item t, so every t('...')
inside called a tag or tunnel object and crashed the page as soon as a
tag or tunnel existed.
Plan 87 phase E, compose part. For a compose app on slots, the live
release is a slot project, not the project its own compose file names.
Status maps to the live project only (a stopped standby never reads as
a degraded app), start/stop/restart and sleep/wake act on it, container
listings show the live and standby projects, and an image update runs
as a queued slot deploy instead of recreating the stack in place.
Plan 87 phase C. A compose app on slots runs each slot as its own
project, <name>-a / <name>-b, rendered from the merged compose config:
container_name stripped, only the web service published, on the
slot's loopback port, and every named volume pinned to the name it has
today. Without the pin compose prefixes volumes with the project name
and slot B would start on empty ones; the real-Docker leg checks this.
Stateful services (a database, cache or queue with a named volume)
cannot run twice. They move once, on an explicit previewed split, into
a shared <name>-data project that both slots reach by the same names.
The webhook, template-update and rollback paths deploy through the
engine instead of stopping the stack. The --scale web=2 rolling
restart and the Webhook.zero_downtime flag are deleted: it assumed a
service named web, ignored its own health result, and no UI set it.
Compose slot images get immutable per-deployment tags and are pruned
with the rest.
Plan 87 phase D. Both slots share the database, so what changes it
runs once, before the switch, while the old release still serves:
the app's managed databases are dumped (a warning, never a blocker),
then the release command runs in a one-off container of the new
image. A failed release aborts the deploy with the live slot
untouched. The command comes from the app's setting, the Procfile
release: line, or serverkit.yaml; a rollback never re-runs it.
Rolling code back never rolls the database back: after a switch
back the slot card offers the pre-deploy snapshot as an explicit
second step with a data-loss warning. stop_old_before_release is
the announced-downtime fallback for schema changes that cannot stay
backward-compatible for one deploy.
Plan 87 phase F. A slot deploy job lists its real stages (Preflight,
Build, Boot slot X, Health gate, Switch, Watch) and advances through
them as the engine reaches each one, so PipelineStrip renders them
unchanged. The overview gets a slot card: which release is live,
which is the standby and how long it stays warm, with Switch back;
when slots are off it lists why the app does or does not qualify.
Settings gains the opt-in, watch window, standby minutes and the
shared-volume confirmation.
Plan 87 phase E, single-container part. Start, stop and restart act
on the live slot's container (stopping the app also stops its warm
standby), container listings show the live slot as web and the
standby separately, and status, stats, logs and the terminal follow
app.container_id, which the switch now updates.
A vhost restore point records which slot the captured file pointed
at, read from the file itself, and restoring it starts that slot
first, so a restore never points nginx at a stopped standby.
Plan 87 phase B. An app that opts in keeps two slots, like the
panel updater's two installs. A deploy boots the new release in the
idle slot on its own loopback port while the live one serves, holds
it to the health gate, then switches nginx by moving app.port to the
new slot and rewriting the vhost, so every app.port reader follows
without edits. A watch window switches back on its own if the
release falls over; the old slot stays warm for an instant switch
back, then is stopped (not removed) by a standby sweep.
Opting in adopts the running container as slot a with no restart.
Eligibility is shown with reasons and re-checked on every deploy;
opting out folds the slots back on the next in-place deploy. Slot
images are never pruned and slot ports stay reserved.
Plan 87 phase A. Fixes the deploy bugs that make a rollback or a
health check lie:
- builds get an immutable tag per deployment, so rolling back runs
the image that actually ran instead of whatever :latest became;
old tags are pruned so this is not a new disk leak
- the deployment records the commit after the pull, not before
- the health wait is a real gate: a 4xx fails, it takes three passes
in a row, an exited container fails at once, and it raises
- a per-app deploy lock makes a second deploy wait for the first
- a compose rollback rebuilds and recreates its containers, and a
rollback with no version finds the previous release again
- a failed template update says when restoring the old stack failed
Health path, timeout and the 4xx rule are editable in Settings.
The load-balancer builder's /proxy POST and /lb-methods were deleted
with the scaling pieces, but their API client methods stayed behind;
the route contract test caught them.
The roadmap gains the per-app traffic and bottleneck hints, the
page cache and compression work, and attaching services to apps.
The removed scaling pieces are simply no longer listed.
Replica counts could be changed, but nginx only proxied to one port
and the auto-scale sweep was never scheduled, so neither the
Auto-scale section nor its five routes could work; the nginx
upstream builder had no UI at all. With one live copy per app they
are gone, and the scale-policy table is dropped. Running containers
are not touched. The scaling spec now says replicas are not
pursued.
A container with a restart policy that keeps dying looked running.
A one-minute builtin tick counts each app's container restarts;
three within ten minutes opens a crash-loop incident through the
monitor incident path and puts a hint on the Overview, and ten quiet
minutes resolve it. Build-pack workers count too.
Webhooks were the only way to hear a core event, and app.deployed
sat in the catalog without ever being emitted. EventService now
calls registered in-process listeners on every emit (best-effort,
torn down with the extension), and a successful deploy emits
app.deployed with the app's hostnames, which a CDN extension uses to
purge exactly those hosts.
The Docker vhost set no caching at all. An opt-in rule serves files
whose name carries a content hash with a one-year immutable
Cache-Control, proxying exactly like location /. A name only counts
as hashed with 8+ characters and a digit, so app-settings.js is never
pinned. Off by default: the panel cannot know an app's asset layout.
A rule-based check reads the app's request metrics, its container
CPU and the CPU and top queries of the databases it references, and
names what fits: page cache for a busy app over an idle database,
a cache or index when one query dominates a busy database, slot
deploys for errors during deploys, and TTL for a low hit ratio. Each
hint links to the fix and states its failure mode; nothing is added
automatically.
An installed PostgreSQL can switch on a transaction-mode PgBouncer
sidecar through its managed override, with no host port, on the
shared network. fromService gains pooledUrl; apps keep the direct
connectionString unless they switch, because transaction pooling
breaks prepared statements in some drivers, LISTEN and advisory
locks, and the card says so.
A new collector template receives OTLP; Attach → Tracing gives an
app the standard OTEL_EXPORTER_OTLP_* variables, and a Jaeger
attached to the collector as its trace store receives the spans.
ServerKit does not instrument apps; it only wires the path. A docker
leg sends a span from an app and finds it in Jaeger.
The image runs unprivileged and a new named volume at /badger is
root-owned, so badger could not create its directories and every
Jaeger install exited with mkdir /badger/key: permission denied.
It now runs as root inside its own container.
The Prometheus, Grafana and Loki templates installed but connected
to nothing. A Grafana install now takes Metrics and Logs
attachments: the panel creates the data source through Grafana's
API with the recorded admin login, and a metrics attach also imports
a dashboard of the panel's fleet metrics. An attached app joins the
shared network, so Grafana reaches the source by name.
Juan Denis