Cloud docs
CDN
Serving your site from the edge, and how to clear the cache from your own code.
A CDN puts copies of your site in datacentres near your visitors, so a page loads from the same continent rather than from the machine it is built on. The platform runs it for you: you buy an amount, and the pull zone, your domains and their certificates are all set up for you.
#Buying it
In the configurator when you set a project up, or afterwards under Commercial terms on the project's configuration page, under Edge. It is bought by the terabyte a month, minimum one.
It is a commitment, not a meter. You pay for what you bought whether or not you use it, which is what lets us sell it without metering every byte. The CDN tab shows what you have actually served this month, so you can tell whether the number is the right one before the next invoice rather than after it.
Raising the amount takes effect at once, charged for the rest of the period. Lowering it, or setting it to zero to give it up, is recorded and takes over at your next invoice — you keep what you bought until the period it was bought for ends, and it is not credited. Once zero applies the pull zone is removed, and your domains stop being served from the edge the moment DNS catches up. See Billing.
#Pointing a domain at it
The CDN is for your own domains. An environment's …vallic.cloud hostname
is deliberately never put behind it — it stays a direct route to the machine,
which is what gives you a way in that does not depend on the cache, and what
lets the pull zone read from it without reading from itself.
So the order is:
- Add your domain under Routing and prove you control it.
- Point it at the address the CDN tab shows. Copy it from there rather than guessing at its shape — it is the one value in this that is not yours.
- Wait. A certificate is issued once the name resolves to the edge, which cannot happen before you publish that record.
The console does the rest: attaching the hostname to the pull zone, asking for the certificate, and telling you when it is ready. Until the certificate arrives the name will not serve over HTTPS — that is the CDN waiting for your DNS, not something to fix here.
An apex domain cannot hold a CNAME. If your DNS provider offers ALIAS or
ANAME, point that at the same name; if it does not, use a subdomain such as
www.
#Clearing the cache from your code
A cache is only useful if you can drop it when you publish. Your application can, without any credential:
VALLIC_CDN_PURGE_URL=http://127.0.0.1:9339/purge
VALLIC_CDN_PURGE_TOKEN=…
Both arrive in the environment like every other variable, and are there only when the CDN is on. Send a POST to that address with the token as a bearer:
{"scope": "all"}
{"scope": "url", "values": ["https://www.example.com/news"]}
{"scope": "tag", "values": ["node:42"]}
- all empties the whole cache. The blunt instrument, and the one to reach for after a deploy that changed templates.
- url drops individual addresses. Only hostnames this environment answers on are accepted; anything else is ignored rather than failing the batch, so one mistyped address does not stop the rest.
- tag drops everything carrying a cache tag you set on the response. The precise one, and the one worth wiring into a CMS that already knows which pages a change affects.
You never name the pull zone. The request is answered on your own machine, and which environment is asking is decided by the token — which is why the token should be treated like any other secret in the environment, and why a CDN credential never appears in your container.
#Who is really asking
Behind a CDN every request reaches your application from the CDN, not from your visitor — so the address your framework reports is one of a few hundred edge servers. Two headers carry the truth instead, on every request:
X-Vallic-Ip: 203.0.113.9
X-Vallic-Country: DE
Read X-Vallic-Ip wherever you would have read the client address: rate
limiting, fraud checks, anything that logs who did what. X-Vallic-Country is
the visitor's country as a two-letter code, for a price list or a language
default. Only trust them on requests that came through the CDN — somebody
reaching your platform hostname directly can send any header they like.
#What is cached, and what never is
A page your application marks private, no-cache or no-store is never
cached, whatever else is configured. That is how a signed-in page stays
somebody's own: every framework already sends one of those on a response that
belongs to a person, so there is nothing to set up and no session cookie name
to get right.
Beyond that, four settings on the environment's CDN tab are yours:
- Dynamic cache lets the CDN decide what is cacheable from your own response headers rather than by file type. For a site that will not be purging by URL or cache tag. Leave it off if you have tuned your cache headers yourself.
- Vary the cache by WebP or AVIF support, mobile against desktop, country, region, hostname or cookie. Each one keeps a separate copy of every page per value, and two of them multiply — so tick only what your site genuinely serves differently. Cookie is the one to be careful with: most sites set a cookie that differs per visitor, which means a cache entry per visitor.
- Blocked countries are refused at the edge and never reach your site.
- Never cache these paths —
/admin/*,/cart— for anything that should always come from your application even though it does not say so itself.
They are read from the CDN and written straight back to it. Nothing is kept separately, so the page always shows what the edge is actually doing.
Some things are decided for every site and are not switches: a stale copy is served while your site is slow or down rather than an error, error responses are cached briefly so a failing page does not take the full force of your traffic, and redirects are passed to the browser rather than followed at the edge — so your canonical URLs stay enforced.
#How it is bought
By the terabyte a month, committed rather than metered — you pay for what you bought whether or not you use it, and nothing here counts bytes. A CDN bought by the hundred gigabytes before it was sold by the terabyte keeps its amount and its price until you change it; a new amount is rounded up to whole terabytes.
On one of two networks. The Volume network is the one selected to begin with: it reaches 10 locations across Europe, Asia and North and South America, costs a fraction as much, and is enough for most sites. The Standard network reaches 119 locations worldwide, and is worth its price when your visitors are spread out; anybody far from a Volume location gets a slower first byte. You can move between them later; the pull zone stays and no hostname is lost. Moving to the Standard network happens at once; moving to the Volume network is a reduction, so like any other it takes over at your next invoice.
A project that was already behind the CDN before there was a choice is on the standard network and stays there until you change it.
The Volume network is one price everywhere. The Standard network is priced by the datacentre you chose, because that is what decides where the bytes come out: Europe and North America is the cheapest, then Asia and Oceania, then South America, then the Middle East and Africa. Change the datacentre in the configurator and the figure moves with it.
The figure itself is quoted where it is agreed, not here: the configurator and the Commercial terms dialog both show what will actually be invoiced.