blumeops/docs/reference/infrastructure/gandi.md
Erich Blume b197bd5f58 Adopt Dagger CI for docs build (Phase 2) (#157)
## Summary

Migrates the docs build pipeline to Dagger (Phase 2 of the Dagger CI adoption plan).

- **Backfill `date-modified` frontmatter** on all 80 docs — Dagger's `--src=.` excludes `.git`, so Quartz can't use git history for page dates. Frontmatter dates work with or without git.
- **New `docs-check-frontmatter` mise task + pre-commit hook** — validates all docs have `title`, `tags`, and `date-modified`
- **New Dagger functions** — `build_changelog` (towncrier in Python container) and `build_docs` (chains changelog → Quartz build in Node container, returns tarball)
- **Simplified CI workflow** — the ~44-line inline Quartz build (clone, npm ci, build, tar, cleanup) is replaced by `dagger call build-docs`. Changelog step remains local on the runner since towncrier needs to modify the host working tree for the git commit.

### Design decisions

- **Towncrier runs twice in CI**: once inside Dagger (for the docs tarball) and once on the runner (for the git commit). This is intentional — Dagger's directory export is additive and can't delete the consumed changelog fragments from the host.
- **Artifact hosting stays on Forgejo Releases** (not migrated to Forgejo Packages as the plan doc originally suggested). That migration can happen independently.
- **`date-modified` frontmatter** preserved even though `build_changelog` installs git — the git there is only for towncrier's `git add` call, not for history. The local iteration story (`dagger call build-docs --src=. --version=dev` with uncommitted changes) depends on frontmatter dates.

### Local iteration

```bash
dagger call build-docs --src=. --version=dev export --path=./docs-dev.tar.gz
tar tf docs-dev.tar.gz | head -20
```

## Deployment and Testing

- [x] `dagger call build-docs --src=. --version=dev` produces valid 1.1MB tarball (149 HTML pages)
- [x] Pre-commit hooks pass (including new `docs-check-frontmatter`)
- [ ] Full `workflow_dispatch` run after merge

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Reviewed-on: https://forge.ops.eblu.me/eblume/blumeops/pulls/157
2026-02-11 16:33:16 -08:00

2.5 KiB

title date-modified tags
Gandi 2026-02-08
infrastructure
networking
dns

Gandi

DNS hosting provider for the eblu.me domain, managed via Pulumi IaC.

Quick Reference

Property Value
Domain eblu.me
Provider Gandi LiveDNS
IaC pulumi/gandi/
Stack eblu-me

What It Does

Gandi hosts the DNS records that make *.ops.eblu.me resolve to indri's Tailscale IP (indri.tail8d86e.ts.net). Since Tailscale IPs are not publicly routable, this gives services real DNS names while keeping them private to the tailnet.

The target IP is resolved dynamically from indri.tail8d86e.ts.net at deploy time, so if indri's Tailscale IP changes, re-running the deployment is sufficient.

DNS Records

Private services (Caddy on indri)

Record Type Value TTL
*.ops.eblu.me A indri's Tailscale IP 300s
ops.eblu.me A indri's Tailscale IP 300s

Both records point to indri, which runs caddy as the reverse proxy for all private services.

Public services (Fly.io proxy)

Record Type Value TTL
docs.eblu.me CNAME blumeops-proxy.fly.dev 300s

Public CNAMEs point to flyio-proxy on Fly.io. See expose-service-publicly for adding new public services.

See routing for the full service URL map.

Pulumi Configuration

The Pulumi program lives in pulumi/gandi/:

  • __main__.py - Creates the two A records via pulumiverse_gandi
  • Pulumi.eblu-me.yaml - Stack config (domain, subdomain)

Stack config values:

Key Value
blumeops-dns:domain eblu.me
blumeops-dns:subdomain ops

A break-glass override is available via the BLUMEOPS_REVERSE_PROXY_IP environment variable, which bypasses dynamic IP resolution.

TLS Integration

caddy uses Gandi's API separately (via GANDI_BEARER_TOKEN) for ACME DNS-01 challenges to obtain a wildcard Let's Encrypt certificate for *.ops.eblu.me. This is a different credential from the Pulumi PAT.

Authentication

Gandi requires a Personal Access Token (PAT) for API access. PATs have a maximum lifetime of 90 days (currently set to 30). See gandi-operations for deployment and PAT cycling instructions.

  • gandi-operations - PAT cycling and deployment how-to
  • routing - Service URLs and routing architecture
  • caddy - Reverse proxy using Gandi for TLS
  • tailscale - Tailnet networking
  • indri - Server hosting Caddy (DNS target)