Spotcraft 0.2.0

Databases for hosted apps, and a backend kit that gives server-rendered apps guest accounts:
one Postgres on the apps server with a database per app, the spotcraft dev command to run
the same setup locally, and the dashboard to see and delete an app's users.

Before deploying, add the POSTGRES_AGENT_PASSWORD secret (see Upgrading).

Added

• Postgres on the apps server (postgres service, Postgres 18), the base for databases for
  hosted apps. Reachable only inside Docker; the superuser only over the local socket.
• App databases: database: true (the dashboard's Database checkbox) gives an app its own
  Postgres role and database as DATABASE_URL. Removing an app keeps its database unless you
  also choose to delete it (?purge=true). When the agent starts, it brings every app database
  up to date.
• Backend kit (@spotcraft/kit on npm): guest accounts for server-rendered apps on Better
  Auth. Server-only: an httpOnly session cookie, no auth routes, and it fails to bundle for the
  browser. currentGuest reads without creating, so apps create guests only when a visitor
  saves something, not for every page view or crawler. New guests are limited per client
  address, and the kit checks the auth schema version.
• spotcraft dev (spotcraft on npm): the apps server's Postgres and app database setup on
  your machine (start, stop, status, env --write, reset, migrate).
• App users: for apps with a database, the dashboard lists their users (guests and
  registered, created, last seen) and deletes one with everything the app kept for them. The
  agent's API has GET /apps/:name/users and DELETE /apps/:name/users/:id.
• Dashboard: a Database checkbox when adding or editing an app, the database in the app's
  settings, and "Also delete its database" when removing it.
• npm packages published by CI on release tags, with provenance. Their APIs join the public
  API (ADR 0019).
• Guide: Guest accounts with the backend kit,
  for a SvelteKit app locally and on Spotcraft.

Changed

• The Deploy workflow needs a new secret, POSTGRES_AGENT_PASSWORD, on the production
  environment. The apps server needs about 1 GB more memory.

Security

• Each app's role can open only its own database, and can't change the auth schema, which
  Spotcraft owns and migrates. The built-in databases are closed to everyone but the agent's
  role, which can create databases and roles but is not a superuser.
• An app's database password is generated by the agent and kept with mode 600. The agent's API
  never returns it.
• Two zlib CVEs in the distroless base image (CVE-2026-85091, CVE-2026-76844) are accepted
  until 2026-12-08: nothing in the images loads that zlib, and no fixed base image exists yet.

Upgrading from 0.1:

1. Add POSTGRES_AGENT_PASSWORD (openssl rand -hex 32) to the production environment.
   Without it, the deploy stops with "POSTGRES_AGENT_PASSWORD is empty".
2. Run the Deploy workflow with 0.2.0. Hosted apps keep running; they only get a database
   once you tick Database.

Images: vindotski/spotcraft-agent:0.2.0, vindotski/spotcraft-dashboard:0.2.0, vindotski/spotcraft-site:0.2.0 (amd64 and arm64).

npm: @spotcraft/kit@0.2.0, spotcraft@0.2.0.

Full changelog: v0.1.0...v0.2.0

Spotcraft 0.1.0

The first release: two servers, a deploy agent, a dashboard, and monitoring, enough to run a
handful of server-rendered apps from Docker Hub images behind HTTPS.

Added

• Apps server: Caddy with automatic HTTPS in front of one container per app; www.
  redirects for root domains; HTTP/3.
• Agent (spotcraft-agent image): HTTP API on the private network to list, deploy, update,
  remove and read logs of apps. A deploy pulls the image, starts it with a health wait and
  reloads Caddy, and puts the previous version back if any step fails.
• Dashboard (spotcraft-dashboard image): password login; apps list with status and
  24-hour uptime; add and edit apps with tag suggestions from Docker Hub; per-app reachability,
  uptime, CPU, memory, response time and logs; redeploy and remove; a server page with host
  CPU, memory, disk, load and uptime.
• Monitoring on the ops server: VictoriaMetrics, vmagent, node-exporter and cAdvisor
  metrics, and HTTPS uptime probes of every app that follow the app list automatically.
• Hetzner module (OpenTofu): two ARM servers, a private network, a cloud firewall and a
  deploy key; optional daily backups of the apps server.
• First-boot setup (infra/cloud-init.yaml) for any Debian/Ubuntu VPS.
• Deploy workflow: deploys both servers at a published image tag from a GitHub
  environment, then checks the dashboard from outside.
• Multi-arch images (amd64 and arm64) on Docker Hub with provenance and SBOM.
• Website at spotcraft.dev (spotcraft-site image): a home page and the docs for each
  release, rendered from the repository's Markdown.
• The dashboard follows the system's dark mode.

Security

• Hosted apps run without Linux capabilities, with no-new-privileges, a read-only root
  filesystem by default, and memory, CPU and process limits.
• Spotcraft's own services run without capabilities (Caddy keeps NET_BIND_SERVICE), read-only
  where possible, with limits and health checks; none runs privileged.
• The agent answers only the ops server's private address and requires a bearer token.
• The dashboard uses a scrypt password hash, an HMAC-signed SameSite=Strict session cookie, a
  per-address login lockout, a nonce-based CSP, HSTS and a 1 MB request limit.
• Real client addresses for IPv6 visitors (IPv6-enabled Docker networks).
• Distroless Node 26 images; CI fails on fixable HIGH/CRITICAL vulnerabilities; Dependabot
  proposes weekly updates. Base images and actions are pinned by digest and commit.
• Servers: key-only SSH as a deploy user with modern algorithms only, root login refused,
  two firewalls, automatic security updates.

Upgrading: this is the first release. To install, follow Getting started.

Images: vindotski/spotcraft-agent:0.1.0, vindotski/spotcraft-dashboard:0.1.0, vindotski/spotcraft-site:0.1.0 (amd64 and arm64).