Most CDNs are standalone services. You sign up with a third-party provider, point your DNS at their network, and hope it plays nicely with the rest of your infrastructure. Your origin server is in one place, the CDN is somewhere else entirely, and the traffic between them goes over the public internet.

CubePath CDN works differently. It's built on the same global network that powers everything else on the platform. The same PoPs in Miami, Houston, Virginia, and Spain. The same BGP multihoming and Anycast routing. The same private backbone with MTU 9000 connecting it all together. The CDN isn't a bolt-on service from a third party. It's a native extension of the infrastructure where servers already run.

This post explains how CubePath CDN works, what makes it different, and why it matters for teams that care about performance.

How It Works: Anycast, Edge Caching, and the Private Backbone

When a user requests content from a domain behind CubePath CDN, here's what happens:

BGP routes them to the nearest PoP. Thanks to Anycast, the user's request automatically lands at the closest CubePath Point of Presence. A user in Mexico City hits Houston. A user in Barcelona hits Spain. A user in New York hits Virginia. No GeoDNS tricks, no client-side logic. The network handles it.

If the content is cached, it's served immediately. Static assets like images, CSS, JavaScript, fonts, and videos are cached at the edge. When a request comes in for content that's already in the PoP's cache, it gets served directly from that location. The origin server is never contacted. The response is fast because the data traveled a short distance.

If it's not cached, the origin fetch goes over the private backbone. Here's where CubePath CDN differs from external CDNs. When a cache miss happens and the PoP needs to fetch content from the origin, that request doesn't go over the public internet. It goes over CubePath's private backbone with MTU 9000. The same fast, low-latency, high-throughput internal network that connects all CubePath infrastructure. Cache fills are faster, and the origin is never exposed to the public internet for these requests.

TLS terminates at the edge. The TLS handshake, which requires multiple round trips and is highly latency-sensitive, happens at the nearest PoP. Since the PoP is geographically close to the user, those round trips are short and the connection establishes quickly. This directly reduces time-to-first-byte for HTTPS traffic.

For the customer, setup is straightforward. Point the domain at CubePath CDN, and traffic starts flowing through the edge network. No complex configuration, no separate accounts, no juggling between providers.

Smart Caching with Custom Rules

Out of the box, CubePath CDN caches static content automatically. Images, stylesheets, JavaScript bundles, fonts, videos, anything with standard cache headers gets stored at the edge and served to subsequent users without hitting the origin.

But not every application is the same, and default behavior isn't always enough. CubePath CDN gives full control over caching logic:

Cache by path. Serve everything under /static/ from the edge with a long TTL, but always go to origin for /api/ endpoints. Define different caching strategies for different parts of the application based on URL patterns.

Cache by headers and query strings. Need to cache different versions of a page based on the Accept-Language header? Or vary cache by specific query parameters? Custom rules handle this without workarounds.

Configurable TTLs. Set how long content stays in the edge cache before it's revalidated with the origin. Short TTLs for content that changes frequently, long TTLs for assets that rarely change. Fine-tune the balance between freshness and performance.

Instant cache purge. When new content goes live, purge the cache immediately from the control panel or via the API. No waiting for TTLs to expire, no stale content being served to users. Deploy the update, purge, and the new version is live globally within seconds.

Cache bypass for dynamic content. API responses, authenticated pages, real-time data. Mark specific paths or request patterns as non-cacheable so they always go to origin. The CDN handles the routing and TLS termination, and the origin handles the response.

Built-In DDoS Protection

When traffic passes through CubePath CDN, it hits the PoP network before it ever reaches the origin server. This architecture provides DDoS protection as a natural side effect of how the CDN works.

Traffic is distributed across PoPs. Because Anycast routes users to the nearest PoP, attack traffic gets spread across multiple locations automatically. A volumetric attack that would overwhelm a single server gets absorbed across the entire PoP network. Each location handles a fraction of the volume.

The origin is shielded. With CDN in front, the origin server's real IP is never exposed to end users. Attack traffic hits the edge, where it can be identified and filtered before it reaches the infrastructure running the actual application.

It's not a separate service. There's no additional DDoS protection product to purchase or configure. The protection comes from the CDN architecture itself. Traffic flows through the distributed PoP network, and the origin sits behind it. The same infrastructure that delivers content fast also absorbs malicious traffic.

Who CubePath CDN Is For

E-commerce platforms serving customers across the Americas and Europe. Product images, category pages, and static assets load from the nearest PoP. Faster page loads mean better conversion rates. During traffic spikes like sales events, the edge cache absorbs the load instead of hammering the origin.

SaaS applications with global users. The application dashboard, marketing site, documentation, and static assets all benefit from edge caching. Users in different regions get consistent performance without deploying the application in multiple locations.

Media and content platforms. Images, video, downloads, podcasts. Large files benefit the most from edge delivery because they're the most expensive to serve from a single origin. CubePath CDN caches them at every PoP and serves them from the location closest to the viewer.

How It Compares to Using an External CDN

The obvious question: why not just use Cloudflare, Fastly, or BunnyCDN?

Those are good products. But using an external CDN on top of CubePath infrastructure introduces tradeoffs that disappear with a native CDN:

Origin fetches stay on the private network. When an external CDN has a cache miss, it fetches from the origin over the public internet. When CubePath CDN has a cache miss, it fetches over the private backbone with MTU 9000. Faster cache fills, lower origin load, and the origin is never exposed publicly for these requests.

One provider, one platform. Servers, Kubernetes, DNS, Load Balancers, and CDN all managed from the same panel and API. No separate accounts, no separate billing, no context-switching between providers. When something needs debugging, everything is in one place.

No external dependency for a critical path. The CDN is often the first thing users hit. Making that dependent on a third-party service means adding a point of failure outside of your control. With CubePath CDN, the content delivery layer runs on the same infrastructure and network as everything else. Same uptime guarantees, same support team, same accountability.

Configuration that matches the infrastructure. CubePath CDN knows about the rest of the CubePath platform. Caching rules, origin configuration, and SSL certificates integrate natively instead of requiring manual setup between two separate systems.

This doesn't mean external CDNs are wrong for every use case. For teams running infrastructure across multiple cloud providers, a standalone CDN makes sense. But for teams already on CubePath, the native CDN removes a layer of complexity and delivers better performance between edge and origin.

The CDN Is a Natural Extension of the Network

CubePath didn't build a CDN from scratch in isolation. The CDN is what happens when a global network with Anycast, BGP multihoming, EVPN, and MTU 9000 gets a caching layer on top.

The PoPs were already there. The Anycast routing was already there. The private backbone was already there. The DDoS resilience from distributed traffic was already there. Adding content caching and delivery rules to that foundation was the natural next step.

For teams already running servers on CubePath, activating the CDN means adding a caching and delivery layer on top of infrastructure that's already optimized for performance. The network is fast, the origin fetch is fast, and the cache is close to the users.

That's what a CDN should be. Not a separate product from a separate provider. An extension of the infrastructure that's already doing the work.