← Special pages

Architecture

One Astro site serves every conference year, the travel page, the archive and the countdown. It is built ahead of time, as plain pages, one directory per hostname, and served from S3 behind CloudFront, whose viewer function picks the directory from the hostname. Large files live on assets.doreancon.org. Everything is built with Bazel and deployed by GitLab CI when a release is merged.

doreancon.org architecture Visitors reach CloudFront, whose viewer function picks each host's directory of the static site in S3 and answers redirects; large files come from assets.doreancon.org. Merge requests build everything with Bazel against a shared cache, and a release tag deploys the files and the function. SERVING A REQUEST Visitor any *.doreancon.org CloudFront doreancon.org, *.doreancon.org DNS: Porkbun (svrbc), ALIAS + CNAMEs viewer function, from the release: • bare domain → www (308) • host → its directory: /hymns on 2025.* is /2025/hymns/index.html • redirects: current year → www, /register, archive years, large files S3: the whole site (cached) svrbc-doreancon-org-site Astro, built as static pages at release: one directory per host — /www (the current year), /2025, /2027, /travel, /archive, /countdown — beside the files they share: /_astro, /images, /hymnal, /pdf/museum, and the special pages, /_/ assets.doreancon.org CloudFront + S3 svrbc-doreancon-org-assets bulletin PDFs, countdown music, at /<sha256>/<name>, cached for a year the site's links to large files redirect here (302) BUILDING AND RELEASING Merge request from svrbc/forks/doreancon.org CI check: bazel test //... Merge: fast-forward. Shared Bazel cache bazel-cache.svrbc.org S3 + CloudFront; steps whose inputs didn't change are reused Release merged bump → v* tag uploads new assets, then bazel run //:deploy_aws deploy (GitLab OIDC role) the release publishes the viewer function
Solid arrows: a visitor's request. Dashed: a release deploying. Colored outlines: AWS.

Serving

  • DNS is at Porkbun (the svrbc account), pointing every name at one CloudFront distribution.
  • A CloudFront function redirects the bare domain to www, and serves each hostname from its own directory.
  • Every page is a file, built at release; nothing is rendered on request.
  • The same function, with the same routes, runs the dev server.

Building and releasing

  • Every generated file (hymnal, bulletins, QR codes, the site) is a Bazel step, and so are the tests.
  • Changes are merge requests from the project's fork, built and tested before they are opened, with the results uploaded to the shared cache; CI confirms them from it.
  • A release is a merged version bump: CI tags it, and the tag deploys only what changed.
  • CI holds no AWS keys: it assumes roles with GitLab's OIDC token.