Elements vs Cloudflare

Markdown

Cloudflare is a network company, founded in 2009, that runs a global network with data centers in more than 300 cities. Its core product is a content delivery network (CDN), which keeps copies of a website's files on servers close to visitors and serves them from there. On the same network, Cloudflare sells DNS, security services such as DDoS protection and a web application firewall, and products for running code on its network. The main one is Workers, which runs code on Cloudflare's servers around the world. Pages builds and hosts sites from a Git repository, and Cloudflare now recommends Workers for new projects. Its free plan includes the CDN, DNS and DDoS protection, and paid plans add security and performance features.

Elements is not a CDN or a hosting company. It is an integrated app environment for building web apps, built for people and their agents: one coherent system that includes a project server that runs while you work, a default app framework, a package installer, a test runner, a bundled Postgres database, and a deploy command. It deploys to ordinary Ubuntu servers you rent from any provider and reach over SSH, where its own load balancer terminates HTTPS and spreads requests across your machines. Elements charges for that tooling, per machine, and meters nothing (pricing).

Together they serve an app's files from Cloudflare locations near its visitors, with no cache purge after a deploy. Elements runs the app on your server, called the origin. Cloudflare sits in front of it: it answers DNS, absorbs attack traffic and caches files near visitors. Elements gives every built JavaScript, CSS and image file a URL that changes only when the file does, so Cloudflare can cache each one for months, and a deploy never needs a cache purge.

Cloudflare Serves the Network, Elements Builds and Runs the App

An Elements app's origin is the built-in load balancer on each of your servers, which terminates HTTPS, spreads requests across your machines, and retries another machine when one fails. Cloudflare's part is the network in front of it: copies near visitors, DNS, and protection from attack traffic.

A Deploy Never Needs a Cache Purge

When a file changes but keeps its URL, a CDN keeps serving the old copy until it expires or someone purges it. Elements never has that problem, because a built file's URL changes whenever its bytes do (build). New files arrive under new URLs, and unchanged files stay cached at the edge and in every visitor's browser.

Elements also serves each JavaScript module as its own file, loaded by a small script on the page, instead of bundling everything into one large file. A small code change therefore produces only a few new URLs, and most of the edge cache survives each deploy. The deploy itself sends only the files that changed to your server and often finishes in under a second (deploy).

Cloudflare Caches Every Elements Asset

Cloudflare caches a response when the origin marks it public with a max-age above zero. HTML and JSON are the exception: it does not cache them by default. Every Elements asset qualifies: its URL carries a hash of its contents, and Elements serves it as public and immutable with a long max-age (load balancer). There are no cache rules to write.

HTML Revalidates Through ETags

Because Cloudflare does not cache HTML by default, it passes page requests through to the origin. Elements gives every HTML response an etag, a fingerprint computed from the page's source, its data and the session state. When the browser already holds the current version, the server answers 304 Not Modified, a short reply with no body (html server).

Cloudflare passes origin etags through, and marks them weak when it recompresses a response; Elements matches weak etags too. Two optional Cloudflare features, Email Obfuscation and Automatic HTTPS Rewrites, rewrite HTML on the way through and strip the etag. Leave both off, and an Elements site keeps its 304 replies.

Setting Up Cloudflare for an Elements App

The usual setup proxies your domain through Cloudflare:

  1. Deploy, and load the site once over HTTPS while the domain's DNS record is set to DNS only (the grey cloud), so the load balancer gets its certificate from Let's Encrypt (load balancer).
  2. Turn on the proxy for the record.
  3. Set the SSL/TLS encryption mode to Full (strict). In Flexible mode Cloudflare reaches the origin over plain HTTP, the load balancer redirects HTTP to HTTPS, and the browser loops on redirects.
  4. Leave Always Use HTTPS off. The load balancer renews its certificate through Let's Encrypt over plain HTTP on port 80, and it already redirects every other HTTP request to HTTPS (load balancer).

With the domain proxied, Cloudflare caches assets on your main hostname, and nothing in Elements changes. To serve assets from a separate hostname instead, such as cdn.example.com, add that hostname to deploy.domain so the load balancer's certificate covers it (setup), and point build.assetUrl at it (config):

config.jsoc
{ build: { assetUrl: env("ASSET_URL", ""), }, }
config/env/production.env
ASSET_URL=https://cdn.example.com

Workers and Pages Are Not Needed

Workers and Pages run apps on Cloudflare's network, priced by requests and CPU time, the same hosted model as Vercel's platform (Elements vs Vercel). An Elements app already runs on its own server, with its database, job worker and realtime channels in one place. That leaves Cloudflare to do what it is known for: the network in front.

Questions

Can I put Cloudflare in front of an Elements app?

Yes. Proxy your domain through Cloudflare and set the SSL/TLS encryption mode to Full (strict). Every Elements asset is cacheable by default, so no cache rules are needed.

Why does my Elements site loop on redirects behind Cloudflare?

Cloudflare's SSL/TLS mode is probably set to Flexible, which reaches the origin over plain HTTP, and the Elements load balancer redirects HTTP to HTTPS. Set the mode to Full (strict) and the loop stops.

Do I need to purge the Cloudflare cache after an Elements deploy?

No. When a built file changes, its content hash and therefore its URL change, so browsers and the edge fetch the new file. Unchanged files keep their URLs and stay cached.

Can I run an Elements app on Cloudflare Workers?

No. An Elements app is a long-running Node.js server with its own Postgres database and job worker. Workers runs short-lived functions in a different runtime. Deploy the app to an Ubuntu server with Elements' deploy command and keep Cloudflare in front.

Do I need a CDN at all for Elements?

No. Elements serves every built asset under a content-hashed URL that browsers cache for months. Its load balancer spreads requests across as many machines as you add. A CDN adds copies close to visitors worldwide and absorbs attack traffic before it reaches your servers.