Building & Deploy

The GUI builds, previews, and deploys your site for you. The three buttons at the bottom of the Website tab are the whole workflow, and the log beside them shows what each one is doing.

Build

Build generates the static site from your current config, on your own machine. Use it to check that a change is valid before anyone sees it: a build failure is how the site tells you something is wrong — a stream pointing at a world you deleted, or a theme override that fails contrast — and the log names the problem.

The first build takes noticeably longer than the rest. The app downloads and verifies its own copy of the JavaScript toolchain (pnpm and Node) rather than using one you installed, then caches it for every build after that. Nothing is installed system-wide.

Preview

Preview starts a local dev server and shows its address. Open it in a browser: it live-reloads as you edit, so you can watch the schedule or the theme change as you type. Press it again to stop, and it stops on its own when you quit the app.

Preview is also where you write prose pages — pages beyond the built-in home and schedule, like an About page or your server rules. While the preview is running, an Edit button appears in the site header, and /edit lists every page and creates new ones. It’s a normal rich-text editor: type, format, drop in images. Saving writes the page into your config repo, so it deploys with everything else. A published site has no editor — the button and the /edit route exist only in the preview.

Prose pages join the site’s nav automatically (you can keep one out of it), each translation names itself, and a page you haven’t translated falls back to the base language rather than 404ing. Name a page index and it replaces the built-in home page.

Deploy

Deploy publishes. It asks for confirmation, then does two things: commits your config edits to your config repo, and pushes the built site to that repo’s gl-pages branch, where a GitLab pipeline picks it up and publishes it to GitLab Pages. You’ll be offered a link to the pipeline so you can watch it finish. You must be signed in — deploying pushes to your repo.

Your config repo’s normal branch keeps the history of your configuration; the gl-pages branch is managed by the app and holds only the built output.

Why Pages is enough

The schedule’s timezone conversion runs entirely in the viewer’s browser, and the whole site is prerendered to static files at build time, so there’s no server to run or pay for — Pages just serves the output.

Building it yourself

The site is a static SvelteKit app and can be built from a checkout with the usual pnpm commands, without the GUI. That’s a development workflow rather than a streamer one; see BUILDING.md in the repository.