Live site: arpeteria.net-flow.fr — Code: github.com/Radiowar1792/arpeteria (public repository)
Context
My brother is a museum curator, passionate about Savoyard/Arpitan culture and language. He needed a way to reference, digitise and publish this heritage — old texts, songs, grammars, contemporary works — without depending on me every time he wanted to publish something. I designed and deployed Arpeteria end-to-end, on my own, for a real non-technical user, not as an academic exercise.
What I did
Architecture & infrastructure — the core of the project
- Monorepo split into independent, replaceable modules:
apps/web(frontend),cms/(versioned Directus config),infra/(reverse proxy, backups),scripts/,docs/ - Production Docker Compose orchestration of 6 services on a Debian 12 VPS: PostgreSQL 16 (application data), Directus 11 (headless CMS), the Astro build (static site), Umami + its own Postgres instance (analytics), and Caddy 2 (reverse proxy)
- Segmented Docker networks (
internal/web/umami): the application database is never reachable from the reverse-proxy network, and analytics run in their own isolated network - Caddy as the single entry point: multi-domain routing (
arpeteria.net-flow.fr→ site,admin.arpeteria.net-flow.fr→ Directus), automatic HTTPS via Let's Encrypt, security headers (CSP, X-Frame-Options, nosniff) - Autonomous publishing pipeline: a Directus Flow calls a webhook handled by a dedicated systemd service (
arpeteria-rebuild-webhook), which reruns the Astro build and republishes the site in ~2 minutes — zero technical intervention required from the curator - 3-2-1 backup strategy: daily PostgreSQL dump + incremental archive of the uploads volume (scanned heritage documents — irreplaceable) to external storage
- Self-hosted analytics (Umami) instead of Google Analytics: lighter, data stays under control, no consent banner required
Development & data modelling — proving this isn't infra-only
- Data model designed in Directus (works, categories, historical figures, places, recommendations) with conditional forms suited to a non-developer editor
- Astro 6 frontend (SSG): one HTML page per work, TypeScript for the Directus API client and SEO helpers
- Advanced structured SEO: JSON-LD Schema.org typed per content (Book/VideoObject/AudioObject/Article/Person/LandmarkOrHistoricalBuilding), sitemap, marked-up breadcrumbs
- Client-side full-text search with Pagefind (index built at build time, no search server to maintain), with facets by section/type/language/category
- Light/dark theme, dedicated print stylesheet, RSS feed, classification by Savoyard spelling convention (ORB, graphie de Conflans…) — all added iteratively from the curator's real usage feedback
Production architecture
Caddy (reverse proxy, auto HTTPS)
├── arpeteria.net-flow.fr → web (Astro static build)
└── admin.arpeteria.net-flow.fr → directus:8055
│
├── database (PostgreSQL 16) — network: internal only
└── /uploads volume (PDFs, images)
umami (analytics) + umami-database — isolated "umami" network
Publishing pipeline
Curator publishes a work in Directus
│
▼
Directus Flow (trigger: "item published")
│ webhook
▼
systemd service (arpeteria-rebuild-webhook)
│
├── npm ci && npm run build (Astro queries the Directus API,
│ generates one HTML page per work + sitemap)
├── npx pagefind --site dist (search index)
└── Astro container restart (Caddy reverse-proxies to it)
│
▼
Site live in ~2 minutes — the curator never touches a terminal
Skills demonstrated
Led solo, from architecture to production, for a real non-technical end user — a complete project rather than a training exercise. It directly covers infrastructure design (B2.1 — multi-service Docker architecture, network segmentation), installation & configuration (B2.2 — VPS deployment, Caddy, systemd), project management (B1.4 — monorepo, roadmap, handover docs), hardening (B3.3 — automatic HTTPS, CSP, network isolation, secrets kept out of the repo), and project governance (B3.5 — 3-2-1 backups, handover documentation). The frontend/CMS side (B1.3 — online presence, B1.5 — service availability) shows that web development and data modelling complement, rather than replace, the systems and network skills that remain the core of this project.