Cloudflare Acquires Linc to Close the Gap Between Static and Dynamic Frontends

Cloudflare has announced the acquisition of Linc, an automation platform focused on frontend development workflows. The Linc team will join Cloudflare to accelerate development of Cloudflare Pages, with an emphasis on supporting full-stack applications. The deal brings with it the Frontend Application Bundle (FAB) specification and its compiler, designed to simplify the deployment of dynamic backends for frontend developers.

The stated goal of the acquisition is to drive Pages beyond static site hosting. By integrating with Cloudflare Workers, Cloudflare intends to offer a unified deployment model where frontend and backend code live together at the edge. The FAB format is central to this plan: it bundles frontend assets and server-side logic into a single, portable artefact that can be deployed across hosting providers, currently including Cloudflare Workers.

The Problem with Static vs. Dynamic Hosting

Frontend development has long faced a tradeoff between simplicity and capability. Static sites — a directory of HTML, JS, and CSS — are easy to host and fast to serve, but offer limited flexibility. Full applications built on NodeJS and a web server provide on-demand rendering and per-user customization, but introduce operational overhead and often suffer from performance issues when served from only one or a few geographic locations.

Serverless platforms solved parts of this problem for backend services, but are less cost-effective for frontend assets that are largely static. The JAMstack approach has bridged some of the gap, enabling static site rebuilds and adding small "cloud functions" alongside app updates. However, the architecture remains constrained: a static layer always sits between the user and the application, and growing dynamic needs tends to complicate the build pipeline or push logic client-side.

The more dynamic your needs, the more complex your build pipeline becomes, or the more you're forced to rely on client-side logic.

How FABs (Frontend Application Bundles) Changed the Model

Linc took a different route with FABs: instead of anchoring the deployment model in static assets, a FAB is an artefact that accommodates the full range of server-side requirements. A compiled FAB (fab.zip) contains two components:

  • A server.js file that acts as the server-side entry point.
  • An _assets directory holding HTML, CSS, JS, images, and fonts sent to the client.

This structure is adaptable to any framework. For a static site, server.js holds just a few auto-generated lines that add redirects for any files outside _assets. For an application with full server rendering, the format is identical — server.js just contains more code. This design means a FAB can span the spectrum from entirely static pages to full server-side streaming rendering, which Linc emphasizes as its core advantage over existing tools.

Deployment in Practice

fab.zip is designed to run both locally and in production. On a NodeJS server, a FAB is served with the fab serve fab.zip command. For production, the deployment process typically splits the FAB into its component parts: the assets directory is sent to a low-cost object storage platform fronted by a CDN, while the server component goes to dedicated serverless hosting. The deployment is atomic and idempotent, keeping the workflow simple. Asset deployment to object storage is suitable for CDNs, but it's not always how Cloudflare Workers operates.

The Cloudflare Workers Difference

Workers differs from other serverless platforms because it runs at the edge, without a CDN or load balancer in front of it to split off /_assets routes. That means every request reaches the Worker, whether it is a full page render or a request for an image file. Linc's report reflects that this is not considered a penalty: the performance and cost profile of Workers enables more flexibility in what can be built.

The applied example of this within the FAB framework is the asset storage. Instead of a dedicated static file host, a Worker can store assets in Cloudflare's Workers KV and map /_assets requests directly into the KV store. As a consequence, the VM can stream requested results to users without the overhead of proxying to a third-party host.

Why Linc Chose Cloudflare

Linc's stated mission was to give frontend developers the best tooling regardless of hosting provider. The observed reality, however, was asymmetric: teams with a free choice increasingly selected Cloudflare Workers. At points, Linc users would demonstrate performance improvements by deploying a FAB to Workers while maintaining existing hosting, before making the switch permanent.

Linc notes that the developments requiring deeper integrations with hosting providers proved to be the most compelling. As they explored the potential for edge rendering and global serverless hosting, the discussions with Cloudflare presented the opportunity to influence those platforms directly. For Linc, that aligns with the prospect of "next-generation deployment, review & hosting platform" built around innovations like Durable Objects and their new storage paradigms.