Pin the build stage to $BUILDPLATFORM so Hugo runs once on the native
arch instead of once per target arch under QEMU. Hugo output is static
HTML and identical across arches, so the emulated arm64 Hugo run (~59s
vs ~12s native) plus emulated base-image extraction were pure waste.
The runtime stage stays on TARGETPLATFORM, so multi-arch amd64+arm64
images are still produced.
Surface VPN connection status in the deploy job so netbird failures are
legible instead of a cryptic DeadlineExceeded:
- Pre-flight check for /dev/net/tun + NET_ADMIN before connecting
- id + timeout-minutes:3 on Netbird Connect to bound its wait loop
- Post-connect 'netbird status --detail' with a Management:Connected assert
- Always-run diagnostics + 'netbird down' teardown
caddy-cf now bundles WeidiDeng/caddy-cloudflare-ip, so document
'trusted_proxies cloudflare { interval 12h; timeout 15s }' as the
primary (auto-refreshing) approach, with the static-list method noted
as the fallback for builds without the plugin. Also explains
client_ip_headers (Cf-Connecting-Ip preferred, X-Forwarded-For fallback).
caddy-cf now includes WeidiDeng/caddy-cloudflare-ip, so replace the
hardcoded 22-range static list with 'trusted_proxies cloudflare' which
auto-fetches and refreshes Cloudflare's IPv4/IPv6 ranges (interval 12h,
timeout 15s). No static list to keep in sync when Cloudflare updates.
Kept client_ip_headers Cf-Connecting-Ip X-Forwarded-For (prefer CF's
authoritative end-user IP, fall back to XFF) and documented why.
Validated + fmt-clean and tested end-to-end against the updated caddy-cf
image: starts cleanly, serves HTTP 200 with gzip + security headers.
The live production setup is Cloudflare -> Caddy (HTTP :80) -> SWS, which
differed from the DNS-01 topology the doc previously assumed. Add a
'Deployment topologies' overview and a dedicated Cloudflare-fronted
section pointing at the committed root Caddyfile, covering reverse_proxy,
encode, security headers, and Cloudflare trusted_proxies. Label the
existing Compose/K8s examples as the DNS-01 alternative.
Replace 'private_ranges' with Cloudflare's official published edge ranges
(15 IPv4 + 7 IPv6 from cloudflare.com/ips-v4 and /ips-v6). This ensures
Cf-Connecting-Ip / X-Forwarded-For are only honoured for requests that
genuinely originate from Cloudflare, preventing client-IP header spoofing
from any other source.
Validated + fmt-clean and tested at runtime against the caddy-cf image:
Caddy starts cleanly with all 22 ranges, serves HTTP 200 with gzip and
security headers.
The live Caddy was returning a blank page (NOP, status 0) because its
site block had no responder \u2014 no reverse_proxy to the blog. This adds a
known-good HTTP-only Caddyfile matching the actual topology
(Cloudflare terminates TLS -> Caddy :80 -> SWS blog:80):
- reverse_proxy blog:80 (the missing responder that caused the blank page)
- encode zstd gzip (fixes: origin was serving everything uncompressed)
- security headers (fixes: HSTS/X-Frame-Options/etc were absent)
- trusted_proxies + client_ip_headers for correct Cloudflare visitor IPs
- http:// scheme so Caddy does not try to provision TLS (Cloudflare does)
Validated + fmt-clean against the caddy-cf image; tested end-to-end
locally (Caddy -> SWS) returning HTTP 200 with gzip and headers.
The deploy pipeline works end-to-end now (Gimli deploys successfully),
so the diagnostic step used to trace the WireGuard/TUN issue is no
longer needed. RPIC continue-on-error is kept until the cluster returns.
CI pushes to tea.ahmza.com/ahmza/blog-ahmza-com, not ghcr.io, and a
bare reference could resolve to the non-runnable :buildcache tag. Pin
the image to tea.ahmza.com/ahmza/blog-ahmza-com:latest so docker compose
pulls the actual runnable image.
The Raspberry Pi cluster is temporarily out of service. Mark its deploy
step continue-on-error so its failure no longer skips the Gimli deploy
or fails the whole job. Revert once the cluster is back online.
The GitHub-hosted 'gha' cache backend is unreachable from the
self-hosted Gitea runner (dial tcp 172.18.0.2:44181 i/o timeout), which
failed the build step even though the image pushed successfully. Switch
cache-from/cache-to to a registry-backed cache stored as a :buildcache
tag in the same Gitea registry, which works on self-hosted runners.
Other Netbird peers connect fine, so the server and 51820/udp are OK --
the hang is specific to the Gitea runner. Replace the UDP port probes
with runner-side checks: /dev/net/tun presence, effective capabilities
(NET_ADMIN), WireGuard tooling/module, and a definitive 'ip tuntap add'
test. A runner container lacking TUN/NET_ADMIN cannot create the
WireGuard interface, which explains 'netbird up' timing out after the
control plane connects.
The Netbird server multiplexes management + signal + dashboard behind
Traefik on :443 (no separate :10000 signal port). The tunnel data plane
is WireGuard on 51820/udp and STUN on 3478/udp. Update the debug step to
probe those UDP ports plus a general outbound-UDP check (public STUN) to
determine whether the runner network blocks UDP egress -- the likely
cause of 'netbird up' timing out after the control plane connects fine.
Temporary diagnostic step before 'Netbird Connect' that checks secret
presence (masked), DNS resolution, HTTPS reachability to the management
API, and the signal server TCP port from the runner. Helps distinguish
DNS/connectivity issues from auth/registration failures behind the
recurring 'netbird up' DeadlineExceeded error. Marked continue-on-error
so it never blocks the build.
Switch the deploy job's Netbird Connect step to read management-url from
the NETBIRD_URL secret instead of a hardcoded value, so the URL can be
managed in the Gitea UI alongside the setup key.
Update the README to reflect the actual infrastructure: CI/CD runs on
Gitea Actions (not GitLab), images live in the Gitea container registry,
and the clone URL points to tea.ahmza.com. Also clarify the Blowfish
theme is a Hugo module, so no submodules are needed.
Switch the Caddy doc to the custom caddy-cf image
(ghcr.io/ahmzaa/caddy-cf) which bundles the Cloudflare DNS module, so
TLS certs are issued via the ACME DNS-01 challenge instead of HTTP-01.
This removes the need to expose ports 80/443 to the public internet,
which suits the Netbird-only infrastructure.
- Add (cloudflare) snippet + import cloudflare to both Caddyfiles
- Read CF_API_TOKEN from env (.env for Docker, Secret for K8s)
- Document token scope (Zone:DNS:Edit) and Cloudflare-hosted DNS
requirement
- Validated Caddyfile against the caddy-cf image (caddy adapt)
Document running Caddy in front of the SWS origin for both deployment
targets (Docker Compose on Gimli and the Kubernetes Pi cluster), with
Caddy handling automatic HTTPS, compression, and security headers.
Explains the layer separation: SWS serves static files + Cache-Control,
Caddy owns TLS/compression/security headers (matching sws.toml where
those are disabled). Caddyfile validated with 'caddy validate'.
The site sits behind a reverse proxy that already handles compression
and security headers. Disable those in SWS to avoid redundant work and
duplicate/conflicting headers, letting each layer own one concern.
- compression / compression-static: off (proxy compresses)
- security-headers: off (proxy sets them)
- cache-control-headers, page-fallback, health: kept (origin concerns)
Replace nginx:alpine-slim with the scratch-based static-web-server
image, reducing the final image size ~32MB -> ~23MB (28% smaller).
- Dockerfile: serve from static-web-server:2, copy site to /public
- sws.toml: mirror previous nginx behavior (compression, cache-control,
SPA index fallback) plus security headers and /health endpoint
- Remove now-unused nginx.conf
ahmza