One Build. Many Clouds. Zero Headaches.
We're not saying you must deploy your app to multiple cloud providers simultaneously. But if you've ever dealt with failover requirements, regional domains, or compliance standards that read like cryptic wizard scrolls, you'll love this.
Today, we're announcing an amazing upcoming feature: multi-CDN deployments in Zephyr Cloud — giving you the ability to push the same build to multiple cloud providers and domains in a single, seamless flow. Whether it's Cloudflare, Fastly, Netlify — Zephyr, handles the propagation for you.
Because "Just deploy it" should mean one command. Not five.
🧠 The Origin Story: When a Pipeline Just Isn't Enough
It started, as many good features do, with a customer request.
We need to deploy the same app under different providers for compliance. Some countries require specific domain endings, and some of our infra is set up for failover.
We'd heard rumblings before — multi-region support, CDNs optimized for specific markets, requests for "poly-cloud" delivery — but this one stuck. The problem wasn't just performance. It was complexity.
Setting this up manually meant duplicate CI jobs, custom scripts, and a spaghetti of domain mappings. Zephyr was already built to simplify bundling and deployment. Why not take it further?
🔧 The Technical Bit (Without the Brain Melt)
Here's how it works:
- Add the Zephyr Plugin to your bundler of choice (we support Vite, webpack, Rspack, Rollup, Parcel, Rolldown… yes, really).
- Build your app — Zephyr sends it to the primary configured cloud provider.
- From there, Zephyr propagates the deployment to your other configured CDNs using our own Edge Workers and smart storage replication.
Each cloud provider receives a versioned snapshot of the app — same assets, same metadata, same power. We intentionally keep the bundler plugin light so that this propagation doesn't slow down your build. The heavy lifting is handled post-build, using storage-layer operations.
🌍 Poly-Cloud, Versioned, and Under Control
Versioning is Zephyr's bread and butter. Multi-CDN doesn't change that.
Each build generates a unique, immutable version URL. You can test it, tag it, assign it to an environment, and now, with multi-CDN support, Zephyr ensures that the version propagates consistently across your providers.
Fastly gets version v42.
Cloudflare gets version v42.
Netlify gets version v42.
You get peace of mind.
All version metadata lives in Zephyr, and assets are distributed via edge storage like Cloudflare KV or similar systems. No matter how many clouds you use, your versioning remains centralized, visible, and rollbackable.
🧑💻 Developer Experience: Clean, Clickable, Done
Once you've integrated with Zephyr, using this feature is as simple as:
- Configure which clouds to propagate to (in the Application Settings).
- Build.
- Deploy to your default provider.
- Done.
If a deployment fails on one CDN? We've got retries and failure logs coming in hot. You'll be able to see per-provider status right in the dashboard — no need to dig through logs or guess what happened.
Selective deployment per version isn't the current model — we propagate to all active providers — but you can toggle providers on or off anytime. Want to stop deploying to Netlify? One click. Future builds will skip it.
🕵️ Real-World Uses (A.K.A. "Why This Exists")
Some actual (or plausible) ways customers use this:
✅ A fintech company needs EU-region domains to comply with local laws.
✅ A content-heavy app wants blazing-fast delivery in Southeast Asia.
✅ A dev team prefers Vercel, but their infra team wants AWS for backup.
✅ A company uses .com for global traffic and .co.uk for UK legal compliance.
They all want the same thing: One app. Multiple clouds. One source of truth.
Zephyr makes that possible, without the usual mess of duplicating pipelines, managing multiple versioning systems, or introducing new failure points.
🔭 Our Vision (With Slightly Fewer Buzzwords)
At Zephyr, our mission is to make the cloud feel more like a platform — and less like a choose-your-own-infrastructure maze.
We're building towards a world where you can serve your app from wherever makes sense — legally, regionally, operationally — with complete visibility and control. And without being locked into one provider or a patchwork of DevOps glue.
We want to be the universal versioned delivery layer for modern web applications.
This is a step in that direction.
🔮 What's Next?
We're already working on native integrations with AWS and Vercel, aiming to give you: Simplified setup;
- Resource usage tracking;
- Cost visibility per deployment;
- And just enough magic to avoid YAML fatigue;
And while we don't support region-aware routing or programmable rules yet, who knows what the next customer request might spark?