CDNFoundry v1.2.1
v1.2.1 is a zero-state release. Deploy it from scratch with the production quick start; there is no upgrade path from 0.x and no backward-compatibility promise with earlier versions. See Upgrade and rollback for how later 1.2.x updates are handled.
The full list of changes is in the changelog.
Highlights
- One version for the whole project (
VERSION): control plane, API contract, edge agent, edge gateway, fleet generator and release manifest. - Hardened origin validation, edge artifact freshness, bounded telemetry and cache refresh.
- Apache-2.0 license,
NOTICE,SUPPORT.md, supported-version policy.
Breaking changes
- Edge headers use the
X-CDNFprefix. - No migration path from 0.x. Existing 0.x installations must be rebuilt.
Supported software
Taken from the repository (core/composer.json, compose.prod.yml, Dockerfiles):
| Component | Version |
|---|---|
| PHP / Laravel / Filament | 8.5 image (requires 8.3+) / 13.x / 5.x |
| Go services | built with Go 1.26.10 |
| PostgreSQL | 18.6 |
| Valkey | 9.1.2 |
| PowerDNS Authoritative / DNSdist | 5.1.4 / 2.1.2 |
| OpenResty | 1.31.1.1 |
| ClickHouse | 26.8.7 |
| Vector / Loki | 0.58.0 / 3.7.8 |
| Prometheus / Grafana | 3.13.3 / 12.4.11 |
Support statement
Qualified by evidence that exists:
- CI runs the Laravel suite, Go tests, fleet tests, Compose and supply-chain policy checks, the OpenAPI contract, the documentation build, and non-UI Python real-runtime qualification (
tests/e2e) against real PostgreSQL, PowerDNS, DNSdist, OpenResty, Vector and ClickHouse. - Images are built once, scanned, signed and published with SBOM and provenance.
- A clean staging rebuild (one control host, two DNS/edge hosts) enrolled both edges and answered authoritative DNS; the archived record is in
docs/legacy/feature-test-matrix.md.
Not qualified, and owner/operator-run:
- Manual browser qualification (
docs/manual-browser-qualification.md): not run. - Customer traffic on physical edges, public IPv6 paths, BGP/Anycast routing, registrar delegation at scale, and load limits for your hardware. Complete the production qualification before sending customer traffic.
CDNFoundry is suitable for operators who run their own qualification; it makes no claim of volumetric DDoS scrubbing.
Known limitations
- Single control plane (PostgreSQL is not clustered by the shipped Compose files).
- One origin per proxied hostname.
- Eight bounded cell slots per edge.