Skip to content

Latest commit

 

History

History
56 lines (44 loc) · 3 KB

File metadata and controls

56 lines (44 loc) · 3 KB
title CDNFoundry overview
description Understand what CDNFoundry provides, who it is for, and where to begin.

CDNFoundry overview

::: info Serving and management are separate Laravel owns desired state and operator workflows, but DNS and HTTP requests do not pass through it. A control-plane outage pauses changes while previously activated DNS and edge state continues serving. :::

CDNFoundry combines authoritative DNS, HTTP/HTTPS proxying, managed and custom TLS, bounded caching, security controls, telemetry, and usage export in one private platform. It is intended for an operator who controls the infrastructure and wants predictable failure behaviour without a per-domain process or container architecture.

The platform has two human interfaces:

  • /admin is for active users whose users.type is admin.
  • /app is for active domain users and shows only assigned domains.

Both panels use the same policies and desired-state models as the API. API clients authenticate with Laravel Sanctum bearer tokens.

Choose your path

Audience Start here Continue with
New to CDNs CDN fundamentals How CDNFoundry works, then Desired state
Developer or contributor Local installation Developer setup and Testing
Administrator or domain user Using CDNFoundry First domain, then the feature guides
Hosting provider or ISP architect Private CDN design Production reference architectures
Production operator Production quick start Production best practices, then Operations
API integrator API conventions Endpoint catalog and Errors

::: tip Recommended learning order For a first deployment, follow concepts → local installation → first domain → production quick start → operations. The quick start owns installation order; reference pages explain individual settings and should not be assembled into a second deployment procedure. :::

Current product boundary

The implemented system supports the features documented under Feature guides. It does not include Kubernetes orchestration, billing, reseller hierarchies, a plugin runtime, GraphQL, HTTP/3, private-origin tunnels, or automated multi-region failover. Those are not implied by the presence of extension points in underlying dependencies.

The source tree and automated tests are the implementation source of truth. Repository governance separates implemented behaviour from unqualified future ideas; this public site documents implemented behaviour only.