Skip to content

What it is

discord.sh. An Astro/Starlight site — the topsite’s directory, guides and dashboard — and the axum that serves the build output. One version and one image cover both, because a static site and the process handing it out have no separate lifecycle.

Layout

apps/discordsh/
  web/          the Starlight site, builds static to web/dist
  web/server/   discordsh-web, the axum that serves that dist
  web/e2e/      Playwright, drives the pair
  bot/          discordsh-bot, released on its own version

What the server does

Static files. ServeDir per asset prefix with brotli and gzip variants precompressed at image build time, directory requests rewritten to index.html, and Astro’s own 404.html served at a 404 status so a typo’d URL is not indexed as a page. /health for the kubelet and /version for anything that wants to know which release answered it.

It links axum and tower-http and nothing else — a process that hands out HTML has no business linking a database driver.

The half that is not here

The servers page calls /api/servers/list and /api/servers/submit same-origin, and that axum lives in the KBVE tree rather than this one. So discord.sh is two images for now: the gateway sends /api to the discordsh StatefulSet running ghcr.io/kbve/discordsh, and everything else to this one. See kube/discordsh/manifests/httproute.yaml.

Same-origin is why it is a route split rather than a second hostname: moving those calls elsewhere is a CORS conversation and a browser that has to be told about it. When the API is migrated here, that file loses a rule.

Where the version shows up

One bump lands in three places that cannot disagree, because the build stamps them from this doc before it compiles anything:

  • the image tag
  • apps/discordsh/version.toml, which web/astro.config.mjs reads at build time and the site footer prints
  • web/server/Cargo.toml, which the binary reports at /version

Deploying

A bump to the version: in this doc’s frontmatter, on the default branch, is the release. The build reads it, stamps it into the files it compiles from, and publishes it as the tag; the deploy job then opens a merge request writing that tag into the manifest this doc names, and the manifest moves when it is merged.

version.toml is watched too, so sh tools/version-sync/sync.sh bump discordsh-web <version> works and writes both. See apps/discordsh/ci.yml and tools/version-sync.

The HTTPRoute is not part of that loop: it carries no image line, version-sync never touches it, and it changes once — at the cutover, and again when the API arrives.