CDNFoundrySelf-hosted private CDN software

Run authoritative DNS, bounded edge delivery, TLS, caching, security, and telemetry on infrastructure you control.

Get started

Plan a private CDN

Production quick start

Learn how a CDN works

Follow DNS, TLS, edge routing, cache, origins, desired state, and failure behavior from first principles.

Architecture

Compare production reference designs, planes, durable state ownership, bounded cells, and failure isolation.

Domain users

Add domains, manage DNS, proxy origins, TLS, cache, security, analytics, and usage.

Administrators

Manage users, system DNS identity, DNS clusters, edge pools, operations, settings, and recovery.

API clients

Use the Sanctum API, stable errors, idempotent mutations, cursor pagination, and operation receipts.

Operators

Deploy bounded Compose roles, monitor health, rotate certificates, restore backups, and scale safely.

Developers

Work in the supported Compose environment and qualify PHP, Go, runtime, and documentation changes.

Contributors

Follow the product invariants, scope rules, testing contract, and documentation checks.

CDNFoundry is open-source, production-oriented, self-hosted private CDN software. It gives companies, hosting providers, and ISPs a Laravel and Filament control plane while DNS and HTTP traffic remain on PowerDNS, DNSdist, and bounded OpenResty cells. External changes run asynchronously through revisioned reconciliation, and invalid candidates never replace the last valid runtime state.

What CDNFoundry includes

Capability	What the stack provides
Control plane	Laravel modular monolith, Filament administrator and domain-user panels, Sanctum API, policies, audit history, idempotent operations, Horizon, and Scheduler
Authoritative DNS	Public DNSdist in front of private PowerDNS, DNS-only and proxied records, Geo-DNS, revisioned reconciliation, cluster health, and UDP/TCP serving
Edge delivery	Stable placement across bounded OpenResty cells, explicit origins, host and SNI routing, shared and quarantine pools, draining, and last-valid snapshots
TLS	Managed DNS-01 certificates, encrypted private keys, custom certificate upload, renewal scheduling, and per-host certificate selection
Cache and performance	Deterministic cache keys, bounded admission and storage, stale serving, URL purge, epoch-based full purge, Gzip, Brotli, and origin failover
Security	Tenant policies, origin destination validation, trusted-client-IP handling, rate controls, managed WAF rules, quarantine, and bounded runtime resources
Analytics and operations	Vector pipelines, ClickHouse telemetry, Prometheus metrics, Grafana dashboards, operational logs, health checks, backups, upgrades, and recovery workflows

How the stack is separated

Diagram source

flowchart LR
    subgraph Management["Management"]
      Admins["Administrators"] --> Control["Control plane"] --> State[("Desired state")]
      EdgeControl["edge-control"] --> Control
    end
    subgraph Traffic["Traffic planes"]
      Agent["Edge agent"] -->|"outbound mTLS"| EdgeControl
      Agent --> Edge["Gateway + bounded cells"]
      Control -->|"async revisions"| DNS["Authoritative DNS"]
      Users["Internet users"] -->|"DNS"| DNS
      Users -->|"HTTP/S"| Edge --> Origin["Validated origins"]
    end
    subgraph Operations["Operations"]
      DNS -. "best effort" .-> Observe["Telemetry"]
      Edge -. "best effort" .-> Observe
      Observe --> Grafana["Grafana"]
      State -. "sanitized view" .-> Grafana
    end

The serving path does not depend on Laravel. DNS queries terminate at DNSdist and PowerDNS; HTTP and HTTPS terminate at the edge gateway and OpenResty cells. The control plane commits desired state, queues bounded external work, and delivers revisioned runtime artifacts asynchronously. PostgreSQL is the durable source of truth, while PowerDNS data, edge snapshots, artifacts, and telemetry aggregates are rebuildable runtime state.

Production deployment model

CDNFoundry deploys with immutable container images and generated, role-filtered Docker Compose bundles. The smallest documented production fleet uses one control node and two combined DNS/edge nodes in separate failure domains. Larger fleets can separate control, DNS, edge, and monitoring roles across regions without introducing a second application backend or a per-domain runtime.

Start with the production reference architectures to choose role placement and failure domains.
Follow the production quick start for a dependency-ordered first installation.
Use the feature guides for domains, DNS, origins, TLS, cache, security, and analytics.
Keep the operations runbooks available for diagnosis, rollback, backup, and recovery.

Who it is for

CDNFoundry is designed for companies, hosting providers, and ISPs that operate their own authoritative DNS and edge capacity. It favors predictable failure, bounded resource use, explicit infrastructure ownership, and a small operational surface. It is not a hosted CDN service and does not claim upstream volumetric DDoS protection when network capacity is saturated.

Choose a self-hosted CDN when infrastructure ownership, regional placement, data control, and explicit failure behavior justify operating DNS and edge capacity. Choose a managed CDN when a third party should own global capacity, transit, and day-to-day data-plane operations. The private CDN design guide explains the tradeoffs and minimum production topology before installation.

Grafana is a read-only operations component in the telemetry role. It has no request-path or reconciliation responsibility: an observability outage cannot change desired state or stop DNS and HTTP serving.

Start with the product overview, or choose a destination from the audience cards above. The documentation audit records how this site was reconstructed from the implementation and what remains outside the verified product boundary.