Cloudflare has introduced a new Worker template for Vertical Microfrontends (VMFE), enabling development teams to achieve true architectural independence by mapping multiple independent Workers to a single domain. This approach allows teams to own entire technology stacks—from framework selection to deployment pipelines—while delivering seamless, unified user experiences.
The Monolith Problem
As organizations scale, monolithic frontend architectures become bottlenecks. Multiple teams contributing to a single codebase face cascading issues: a regression in one team's feature forces rollbacks affecting everyone, framework choices become rigid compromises, and deployment coordination creates dependencies that slow innovation.
Traditional "horizontal" microfrontend architectures attempt to solve this by splitting individual pages into components served by different services. While this provides some isolation, teams still coordinate on shared frameworks, design systems, and deployment schedules. The promise of independence remains partially unfulfilled.
Vertical Slicing: Complete Ownership
Vertical microfrontends take a different approach by assigning teams complete ownership of URL paths. In this model:
/ = Marketing (Astro)
/docs = Documentation (Next.js)
/blog = Blog (Hugo)
/dash = Dashboard (React)
Each path represents a distinct Worker with zero shared code. The marketing team can rebuild their site with Astro while documentation uses Next.js—all without coordination. More granularly, within a single experience like a dashboard:
/dash/product-a = WorkerA (React)
/dash/product-b = WorkerB (Vue)
Navigating between products means crossing entirely different codebases, potentially built with different frameworks, libraries, and deployment strategies. This is true autonomy: teams ship independently, choose technologies based on requirements rather than organizational inertia, and bear full responsibility for their vertical slice.
The User Experience Challenge
Autonomy creates a new problem: how do you stitch together multiple independent applications into experiences that feel unified? If implementation details leak to users—visible loading states between "pages," inconsistent navigation, or jarring transitions—the architecture fails.
Cloudflare addresses this through two powerful browser technologies: View Transitions and Speculation Rules.
View Transitions: Seamless Navigation
The View Transition API enables smooth animated transitions between distinct pages, making multi-page applications feel like single-page apps. Traditional navigation between separate Workers produces the dreaded white flash—a blank screen while the browser loads the next page.
With minimal CSS, developers can eliminate this:
css
@supports (view-transition-name: none) {
::view-transition-old(root),
::view-transition-new(root) {
animation-duration: 0.3s;
animation-timing-function: ease-in-out;
}
nav { view-transition-name: navigation; }
}
This tells the browser to keep the navigation element visible during transitions, animating any differences between the old and new pages. Suddenly, navigating from WorkerA to WorkerB feels instant and fluid—the user has no indication they've crossed application boundaries.
Speculation Rules: Instant Loading
View Transitions handle the visual experience; Speculation Rules address loading performance. This API allows browsers to prefetch linked pages into memory, making subsequent navigation nearly instantaneous:
html
When users hover over navigation links, the browser preloads those Workers. Clicking feels instant because the page already exists in memory. While Firefox and Safari don't yet support Speculation Rules, Chrome, Edge, and Opera do—and the degradation is graceful.
Together, View Transitions and Speculation Rules create the illusion of a single-page application across entirely separate codebases deployed by different teams.
Service Bindings: Zero-Config Request Routing
The Router Worker acts as the traffic controller, forwarding requests to appropriate vertical slices based on URL paths. Cloudflare's service bindings enable this without public URLs or complex networking:
json
{
"name": "router",
"main": "./src/router.js",
"services": [
{"binding": "HOME", "service": "worker_marketing"},
{"binding": "DOCS", "service": "worker_docs"},
{"binding": "DASH", "service": "worker_dash"}
]
}
Service bindings allow Worker-to-Worker communication without traversing the public Internet. The Router Worker receives all requests to your domain, matches URL paths to service bindings, and forwards requests accordingly. If a user visits /docs/installation, the router strips the /docs prefix and forwards the request to the DOCS binding, which references worker_docs.
This prefix stripping is intentional: it allows each Worker to function independently at its own URL while also working seamlessly when accessed through the router. Teams can develop and test Workers in isolation, then integrate them into the unified domain without code changes.
HTMLRewriter: Automatic Path Correction
A subtle challenge emerges when Workers designed for standalone deployment get reverse-proxied through path prefixes. An image tag like 
https://docs.example.com/ but breaks at https://example.com/docs/ because the browser resolves the relative path incorrectly.
Cloudflare's HTMLRewriter solves this transparently. As responses stream through the Router Worker, it rewrites absolute paths to include the proxied path:
javascript
// Before:
// After: 
This happens automatically for all responses, requiring no changes to the underlying Workers. Teams continue writing normal HTML, and the router ensures everything resolves correctly.
HTMLRewriter also injects View Transition CSS and Speculation Rules scripts automatically when configured:
json
{
"smoothTransitions": true,
"routes": [
{"binding": "APP1", "path": "/app1", "preload": true},
{"binding": "APP2", "path": "/app2", "preload": true}
]
}
Set smoothTransitions to enable view transitions globally. Set preload per route to inject speculation rules for instant navigation. The Router Worker handles implementation details, letting teams focus on their vertical slices.
Real-World Application at Cloudflare
Cloudflare uses this architecture internally for its own dashboard. When users navigate from the core dashboard into the Zero Trust product at /:accountId/one, they're actually crossing into an entirely separate project maintained by a different team. The transition is seamless—users have no indication they've moved between applications.
This allows the Zero Trust team to iterate rapidly, choose optimal technologies for their use case, and deploy on their own schedule without coordinating with dozens of other product teams. It's the architectural equivalent of microservices, but for frontend applications.
When to Use Vertical Microfrontends
This architecture shines in specific scenarios:
- Multi-team organizations where coordination overhead exceeds value from shared codebases
- Diverse use cases where different sections benefit from different frameworks (marketing site vs. interactive dashboard)
- Rapid iteration requirements where teams need to ship independently without blocking each other
- Legacy migration scenarios where incrementally replacing parts of a monolith with modern architectures is necessary
It's less appropriate for small teams or applications where coordination is trivial and shared infrastructure provides genuine efficiency.
Getting Started
The Vertical Microfrontend template is available today in the Cloudflare Dashboard. Navigate to Workers & Pages, click "Create application," select "Select a template," and choose "Create microfrontend." From there, configure path mappings to existing Workers and enable features like View Transitions.
The setup requires:
- Multiple deployed Workers representing your vertical slices
- A Router Worker configured with service bindings and path mappings
- Optional: smooth transitions and preload settings for enhanced UX
The Broader Architectural Shift
Vertical microfrontends represent a maturation of frontend architecture thinking. Rather than seeking universal solutions that work for all teams, this approach acknowledges that autonomy and appropriate tool selection often outweigh code reuse benefits.
By pushing decisions about frameworks, build systems, and deployment strategies to individual teams, organizations can optimize locally while maintaining global cohesion through well-defined interfaces (URL paths) and shared user experience standards (transitions, design systems).
Cloudflare Workers provides the infrastructure—global deployment, service bindings, HTMLRewriter, and instant scaling—that makes this architecture practical. Teams get true independence without sacrificing user experience or operational simplicity.
Source: Cloudflare Blog announcement of Vertical Microfrontend template for Cloudflare Workers. Learn more in the official Cloudflare Workers documentation.