CDN changelog
Content delivery: the control plane, domains, caching and how workloads are served.
Deploying a site whose content hasn't changed no longer fails
Deploying an unchanged Level 0 site again was refused with "workload already exists with different bytes", because each build stamped its time into the package. Identical files now build identically. Encrypted sites and rollbacks still fail.
Claim your own domain in the portal and get its certificate automatically
Each deployment target with a custom domain now has a Custom domain block in the portal. Claim the domain, add the TXT and CNAME records it shows, and the certificate is issued once they are found. An unverified claim lapses after 48 hours.
ee-cdn-cli finds your output folder and keeps .git out of what it publishes
ee-cdn-cli can now work out your build's output folder, turn on trailing-slash and clean-URL handling with a flag, and pin the builder version. Builds leave out version-control folders and refuse links that point outside the site.
First requests to a site no longer wait several seconds
A site could take 3 to 13 seconds to answer the first request after a gateway's 30-second domain cache expired, because the control plane was starved of processor time. It now has dedicated capacity and does far less routine work.
A public status page at status.evolvingedge.ai
You can now see whether our services are up at status.evolvingedge.ai. It checks the control plane, the portal, sign-in and our own sites every minute, and the changelog shows live status badges above its entries.
Two outages on 3 October, their causes and the fixes
On 3 October every site timed out for about 20 minutes, and later node check-ins hung for about an hour. Both causes are fixed, the fixes were live the same day, and we now monitor the service from outside and publish its status.
Encrypted workloads no longer reveal their unencrypted size
The readable header of a Level 1 or Level 2 workload included the exact size of its unencrypted content. New encrypted builds leave that out; the real values are kept inside the encrypted index, where only a reader with the key can see them.
Serve /about from about.html with the clean-URLs option
Add the line # ee:clean-urls on to your _redirects file and an address like /about serves about.html directly, with no redirect. For sites that build page.html files instead of a folder per page. Level 0 sites only.
Visitors can now load a site's files from nearby operator nodes
A public site's images, scripts and styles can now come from operator nodes, even ones behind home routers, over WebRTC. Each piece is verified before use, and pages always come from the gateway.
Set response headers with a _headers file in your site
Ship a _headers file in the Netlify format and the edge adds its headers to your site's responses, on Level 0 and Level 2 sites. A Content-Security-Policy keeps the edge's own scripts working without allowing inline code.
Portal deploys now check your _redirects file before publishing
A _redirects file deployed from the portal was published unchecked, so a mistake showed up only as a rule that quietly did nothing. The portal now checks it the way ee-cdn-cli does, and an error stops the deploy, naming the line.
_redirects now handles rewrites and per-section 404 pages
A _redirects rule with status 200 serves another page at the requested address, the usual single-page-app fallback, and 404 serves a section's own not-found page. Rules now give way to a real file unless forced with !.
Level 1 sites now decrypt when served by a standalone edge node
A node installed as a standalone program didn't serve the scripts a Level 1 site needs to decrypt in the browser, so the page loaded but stayed encrypted, with no error. From v0.0.107 those scripts are built into the node.
Pages such as /healthcare, /stats and /ee/docs now reach your site
The edge answered some paths on your domain itself, so pages like /healthcare/, /discover/products, /stats or /ee/docs/ returned a bare 404 instead of your page. They now reach your site. One path is newly reserved, /.ee/.
evolvingedge.ai now runs on Evolving Edge
The Evolving Edge website is now served by the Evolving Edge CDN, like the blog and this changelog, so every public Evolving Edge site runs on the network it describes. Every old link still works.
Redirect old addresses with a _redirects file in your site
Ship a _redirects file with your site and matching requests get a 301 or 302, in the format Netlify and Cloudflare Pages use, so a site moving here can bring its redirects along. Works for Level 0 sites.
Your domain no longer lists what else an edge node has cached
Addresses such as /workloads and /discover on a customer's domain listed the content IDs of every site cached on that edge node, other customers' included. They now show only that site's own, and node diagnostics answer only on the node itself.
Videos and large files on your site can now be seeked and resumed
Files inside a site ignored range requests, so a video couldn't be seeked and Safari wouldn't play it at all. The edge now sends just the part of a file that was asked for. HTML pages are still always sent whole.
Deploy alias addresses now serve the deploy they name
Alias addresses of the form ee-name.cdn.3dge.app answered "domain not configured" for every deploy. They now serve the deploy they point to. Custom domains are unaffected and always take priority over an alias.
A missing page no longer reveals where we store your files
A request for a page that doesn't exist used to answer with the internal storage path we had looked up, in unstyled plain text, with no cache headers at all. It now returns a branded page carrying no internal detail and an explicit cache policy.
Your site's own 404 page is now served
Ship a 404.html in your build and it is now served when someone asks for a page that doesn't exist, in your design, with a 404 status. Sites that don't ship one still get the branded fallback rather than plain text.
Level 2 content now opens only for people you authorise
Level 2 exists so we can decrypt your content for people you have approved. It did not work — the key travelled inside the page and access checks refused everyone — so in practice anyone with the link could read it. Access is now granted one person at a time.
Decryption keys are wiped from memory after use
Level 2 workloads are decrypted on the edge node, so the node holds the content key while it serves a request. Edge nodes and the control plane now overwrite keys as soon as they are finished with them, instead of leaving them in memory until it is reclaimed.
Level 1 decryption keys never reach our servers
Level 1 means only you, and whoever you share your link with, can read your content. Two faults broke that — one left the key on our servers, the other handed back no key at all. Both are fixed, and we now keep no copy of your key.
Deleted workload secrets stop working across the fleet within five minutes
The control plane kept every workload secret it had loaded in memory until it restarted, so deleting a secret didn't stop running edge nodes decrypting that workload. Loaded secrets now expire after five minutes.
The control plane records node state far less often
The control plane now saves each node's peer-discovery details only when they change, instead of on every heartbeat, cutting its routine database writes about sevenfold. Delivery is unchanged; two rare recovery cases behave slightly differently.
Sites stay up when an edge node's credentials are rejected
When the control plane rejected an edge node's credentials, the node kept retrying them, and sites it served returned "domain not configured". Nodes now re-authenticate within seconds, and the visitor who triggers recovery still gets their page.
Static sites are now cached by browsers and crawlers
Sites served from their own domain were sent with no-cache on every file, so each visit re-downloaded everything. Build assets are now cached for a year, and pages revalidate in a single cheap round trip.