IXCDN: turning owned servers and bandwidth into an operable CDN

IXCDN is the control plane and operations system behind IXCDN. It is designed for teams that already operate servers, bandwidth, private-cloud resources or multi-region edge nodes, and want to turn those assets into a managed CDN network.

The control plane stores configuration, reviews changes, issues certificates, builds snapshots and distributes policy. Edge nodes handle production traffic: HTTP/HTTPS reverse proxy, cache hits, WAF inspection, L4 forwarding and log reporting. DNS nodes handle authoritative resolution, GeoDNS, GSLB, line routing and LDNS observation.

To onboard a service, operators create sites and origin groups in the console, then point business domains to the cluster DNS. IXCDN can then use region, carrier, ASN, line libraries and real-time quality signals to direct users to a suitable edge node. Static assets are returned at the edge where possible, dynamic traffic follows origin policy, and suspicious requests can be detected or blocked before they reach origin.

IXCDN is more than a proxy configuration UI. It covers the daily CDN operations workflow: node registration and approval, configuration snapshot distribution, certificate automation, cache purge, WAF policy, access logs, WAF events, bandwidth metering and cache-hit analytics in one platform.

This makes IXCDN a fit for several scenarios:

• Teams with server and bandwidth resources that want to build a private or commercial CDN;
• Operators who need private deployment and control over domains, nodes, routes and logs;
• Networks that need low-latency routing across edge sites, clouds and Internet Exchanges;
• Businesses that want cache, WAF, certificates, logs and origin protection managed together.

The data plane follows a control-plane-authoritative model. IXCDN compiles sites, certificates, WAF policies, DNS zones and Geo libraries into deterministic snapshots. Edge and DNS nodes discover checksum changes, pull the latest blobs, and atomically replace in-memory runtime state. As a result, traffic hot paths do not depend on the database, and loaded data planes can continue serving production traffic even if the control plane is briefly unavailable.