Platform · Edge

KERNSTACK CDN

CDN delivery on KERNSTACK is deliberately unglamorous: there is no separate CDN product to configure, no distribution to model, no second console. Setting cdn_enabled: true on a gateway prefix route puts cached delivery in front of the bucket that route serves. The honest scope: this is cached delivery for project sites and assets, declared in one boolean — not a planetary edge network with a rule language.

CDN Edge

Talk to us Read CDN Docs → Software Lifecycle Cloud →

Why teams replace assembled cloud services with KERNSTACK CDN

Teams otherwise bolt a CDN onto a bucket: a distribution, an origin, cache behaviours, invalidation rituals, and a certificate in a second account. On KERNSTACK the cached surface is a property of the route that already serves the site.

What the boolean buys

Cached delivery for the route’s bucket content, governed by the same route declaration that sets the default document, canonical redirects, and the 404 policy. Deploys that publish frontend apps write kernstack-routes.json into the bucket, and a scoped app redeploy can purge just that bucket’s CDN routes (--purge-cdn) — invalidation is a flag on the operation that changed the content, not a separate ceremony.

What it is not

It is not an edge compute platform and not a global anycast empire with request-rewriting rules. Projects are served from their European zone with caching in front; products whose value is intercontinental latency should keep a global edge in front (which composes fine — the origin stays one declared project). The claim is narrower and, for most company sites and product frontends, sufficient.

One boolean per route: marketing site cached, private app shell not — policy per surface
Purge rides along with the deploy that changed the app (--only app:web --purge-cdn)
Canonical redirects and CDN behaviour are declared together, so cached URLs and canonical URLs agree

SDKs & Language Integration

Every KERNSTACK environment vendors typed SDK packages into .kernstack/ so both engineers and coding agents in Agent Sandboxes can call CDN without external credentials:

Go SDK: github.com/coding-berlin/kernstack-sdk-go/sdk_stacks
Node.js SDK: kernstack-sdk
Python SDK: kernstack_sdk
PHP SDK: kernstack/sdk (Composer)

European alternatives to the hyperscaler equivalent

Amazon CloudFront →

CDN in the Project Graph

Declarestack.jsoncdn

RunCDNinfrastructure

MeterOne credit balanceEU zone

stack.json — cdn configuration plan · deploy

{
  "gateway": { "routes": [{ "name": "www", "type": "prefix",
    "target": { "kind": "bucket", "name": "www" },
    "default_key": "index.html", "cdn_enabled": true,
    "canonical_redirects": true, "fallback_mode": "not_found" }] }
}

Metering · compute, storage, or network 1 Shared Balance

Usage draws from the same credit balance as compute (0.01 credits/GiB-s), storage (0.04 credits/GB-hour), and egress (9.00 credits/GiB).

Replaces: Amazon CloudFront · Cloudflare CDN · no direct equivalent

FAQ

Frequently asked questions

Is there a separate CDN to configure or pay for?

No separate product, console, or distribution object. cdn_enabled is a route property; delivery draws on the project’s ordinary meters (storage and egress at 9.00 credits per GiB).

How is the cache invalidated?

Redeploying an app can purge its bucket’s CDN routes in the same operation (--purge-cdn with a scoped deploy). Content changes and cache invalidation therefore share one command and one review.

Can we keep Cloudflare in front instead?

Yes. Nothing requires using the built-in delivery; teams keep an external edge for global reach during and after migrations. The project remains the origin, declared the same way.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →