How BYOB's Deployment Pipeline Works — Edge Network, SSL, and CDN

BYOB's deployment infrastructure runs entirely on Cloudflare — specifically Cloudflare Pages for static hosting and Cloudflare Workers for Platforms for dynamic server logic. Cloudflare operates 300+ edge locations across 100+ countries, serving sites with sub-50ms latency globally.

When you publish a site, BYOB compiles your SvelteKit project, deploys static assets to Cloudflare Pages, deploys server functions as Cloudflare Workers, and provisions SSL certificates — Google-issued as primary, Cloudflare-issued as backup.

Key facts

•BYOB static sites run on Cloudflare Pages with 300+ global edge locations.
•BYOB server logic runs as Cloudflare Workers via Workers for Platforms.
•BYOB uses Google SSL certificates (primary) and Cloudflare SSL certificates (backup).

Cloudflare Pages and the edge network

Traditional hosting runs on centralized servers. A user in Sydney accessing a site hosted in Virginia waits 250-300ms for the round-trip across the Pacific.

Cloudflare solves this by running your site from data centers worldwide. BYOB uses Cloudflare Pages, which sits on top of Cloudflare's network — the same infrastructure that handles 20%+ of global internet traffic daily.

graph TB A[BYOB Build System
SvelteKit Compilation] --> B[Cloudflare Pages
Deployment API] B --> C[North America
100+ Locations] B --> D[Europe
80+ Locations] B --> E[Asia Pacific
70+ Locations] B --> F[Latin America
20+ Locations] B --> G[Africa & Middle East
30+ Locations] C --> C1[User in NYC
~20ms latency] D --> D1[User in Berlin
~25ms latency] E --> E1[User in Mumbai
~30ms latency] F --> F1[User in São Paulo
~35ms latency] H[Static Assets
HTML, CSS, JS, Images] --> I[Cloudflare Pages
Edge Cache] J[Dynamic Requests
Forms, APIs, SSR] --> K[Cloudflare Workers
V8 Isolates] I --> C I --> D I --> E I --> F K --> C K --> D K --> E K --> F style A fill:#3b82f6,color:#fff style B fill:#f6821f,color:#fff style C fill:#22c55e style D fill:#22c55e style E fill:#22c55e style F fill:#22c55e style I fill:#f59e0b style K fill:#8b5cf6,color:#fff

Cloudflare's edge locations:

•North America: 100+ cities including major metros and regional hubs
•Europe: 80+ locations covering EU, UK, and Eastern Europe
•Asia Pacific: 70+ locations including India, Japan, Singapore, Australia
•Latin America: 20+ locations across Brazil, Mexico, Argentina
•Africa & Middle East: 30+ locations with rapidly expanding coverage

A user in Bangalore connects to Cloudflare's Bangalore or Chennai data center. A user in Berlin connects to Frankfurt or Berlin. Round-trip latency drops to 20-50ms versus 200-300ms from a single-region host. Key facts

•Cloudflare Pages runs on Cloudflare's 300+ global data centers.
•Cloudflare's network handles 20%+ of global internet traffic.
•Users automatically route to the nearest Cloudflare location.

How assets distribute via Cloudflare Pages

When you click Publish, BYOB's build system compiles your SvelteKit project and pushes it to Cloudflare Pages:

Static assets:

•HTML files (pre-rendered pages)
•JavaScript bundles (code-split by route)
•CSS files (purged and minified)
•Images (optimized and converted to modern formats)
•Fonts (subsetted to reduce file size)

Cloudflare Workers (dynamic functions):

•API routes (+server.ts files) → deployed as Workers via Workers for Platforms
•Server-side rendering functions → executed at the edge in V8 isolates
•Form handlers (SvelteKit form actions) → run at the nearest Cloudflare location

Distribution process:

1.Build upload: Compiled assets upload to Cloudflare Pages via the Pages deployment API

2.Global propagation: Cloudflare distributes assets to all 300+ edge locations. Pages builds propagate across Cloudflare's network in seconds.

3.Workers deployment: Server functions deploy to Cloudflare Workers for Platforms — BYOB's tenant namespace on Cloudflare's multi-tenant Worker infrastructure. Each BYOB project gets isolated Worker execution.

4.Atomic cutover: Cloudflare Pages uses atomic deployments. The new version goes live everywhere simultaneously — users never see a partial deploy.

The entire process completes within the 30-second deployment window. Key facts

•Cloudflare Pages handles static asset distribution globally.
•Cloudflare Workers for Platforms runs BYOB's dynamic server logic.
•Deployments are atomic — all locations update simultaneously.

CDN caching strategy

BYOB configures cache behavior automatically based on file type:

flowchart TB A[User Request] --> B{Request Type?} B -->|Static Asset
JS, CSS, Images| C[Check Edge Cache] C -->|Cache Hit| D[Serve from RAM
~5ms response] C -->|Cache Miss| E[Fetch from Origin] E --> F[Cache for 1 Year
Content Hash = Immutable] F --> D B -->|HTML Page| G[Check Edge Cache] G -->|Cache Hit
< 5 min old| H[Serve Cached HTML
~20ms response] G -->|Cache Miss
or Expired| I[Fetch from Origin] I --> J[Cache for 5 Minutes
Revalidate] J --> H B -->|API Request
Dynamic Data| K[No Cache] K --> L[Execute Edge Function] L --> M[Fresh Response
~50ms response] style D fill:#22c55e style H fill:#3b82f6,color:#fff style M fill:#f59e0b

Static assets (JS, CSS, images, fonts):

•Cache duration: 1 year
•Immutable: Yes (content hashing prevents stale versions)
•Edge cache: Aggressive (served from RAM when possible)

These files have content hashes in filenames: main-a3f8d2.js. The hash changes when content changes. Old versions never serve incorrectly because the filename is different. HTML pages:

•Cache duration: 5 minutes
•Revalidate: Check origin after expiration
•Edge cache: Short-lived (balance freshness with speed)

HTML caches briefly so content updates appear quickly but repeated visits within 5 minutes hit cache. API responses:

•Cache duration: None (dynamic content)
•Edge cache: Not cached
•Goes directly to server functions

API routes and server-side logic never cache. Every request executes fresh. Key facts

•Static assets cache for 1 year (content hashing prevents staleness).
•HTML pages cache for 5 minutes (balance speed and freshness).
•API routes don't cache (always fresh data).

SSL certificate system: Google primary, Cloudflare backup

Every BYOB site uses HTTPS with a two-layer certificate system for maximum reliability:

Primary: Google-issued SSL certificates

Sites deployed under byob.studio use Google-issued certificates as the primary SSL layer. Google's certificate authority provisions certificates for BYOB's managed domains with broad browser compatibility and trusted root certificates across all major browsers and operating systems.

Backup: Cloudflare SSL certificates

Cloudflare-issued certificates act as automatic backup on every BYOB deployment. If the primary Google certificate encounters any issue — renewal failure, validation error, or temporary CA outage — Cloudflare's certificate takes over without any downtime or manual intervention.

For custom domains:

1.You connect yourcompany.com in BYOB settings
2.BYOB provisions a Google-issued certificate via Cloudflare for SaaS
3.Cloudflare's hostname validation confirms domain ownership automatically
4.Cloudflare's own certificate activates as backup
5.Both certificates renew automatically before expiration

Why two certificates? Redundancy. A single-certificate setup means any CA issue causes downtime. Two independent certificate authorities (Google + Cloudflare) means your HTTPS never fails even if one CA has a problem. Key facts

•Google-issued certificates serve as the primary SSL layer on all BYOB sites.
•Cloudflare certificates activate automatically as backup if primary has issues.
•Both certificates renew automatically — zero manual management required.

Cloudflare Workers for dynamic content

Static assets serve from Cloudflare Pages cache. Dynamic content (forms, authentication, API calls, server-side rendering) runs as Cloudflare Workers.

Workers for Platforms is Cloudflare's multi-tenant Worker infrastructure. BYOB uses it to run each project's server-side SvelteKit code in isolated Worker execution environments. Every BYOB project gets its own isolated Worker — your code can't interfere with other BYOB users' code. How it works for a contact form submission:

1.User in Tokyo submits the contact form
2.Request hits Cloudflare's Tokyo data center
3.BYOB's Worker executes in a V8 isolate at that location
4.Form validation and email API call run locally in Tokyo
5.Response returns to user in ~50ms total

No round-trip to a central server. Cloudflare Workers use V8 isolates (the same JavaScript engine as Chrome) — startup time is sub-millisecond, not the seconds you'd see with container-based serverless. SvelteKit server functions → Cloudflare Workers:

Every +server.ts and +page.server.ts file in your BYOB project deploys as a Cloudflare Worker function. SvelteKit's server logic (API routes, form actions, load functions) runs at the edge automatically.

Key facts

•BYOB deploys server functions as Cloudflare Workers via Workers for Platforms.
•Each BYOB project runs in an isolated Worker (no cross-tenant interference).
•V8 isolate startup is sub-millisecond (no cold start delay).

Load balancing and traffic handling

BYOB's infrastructure scales automatically to handle traffic:

Load balancing: Incoming requests distribute across multiple edge servers in each region. No single server becomes a bottleneck. Auto-scaling: Edge servers scale up during traffic spikes. A viral post that drives 10,000 simultaneous visitors automatically provisions more capacity. Failover: If an edge server fails, requests route to backup servers in the same or adjacent regions. Users experience no downtime. DDoS protection: The CDN includes DDoS mitigation. Malicious traffic filters out before reaching your edge functions. Rate limiting prevents abuse. Key facts

•Traffic distributes across multiple servers per region.
•Capacity scales automatically during traffic spikes.
•Built-in DDoS protection and rate limiting.

Deployment rollout strategy

BYOB uses canary deployments for large sites:

Standard deployment (small sites):

•New version uploads to all edge servers
•Cache invalidates globally
•New version goes live everywhere simultaneously

Canary deployment (large/critical sites):

•New version deploys to 5% of edge servers first
•Monitors error rates for 2-3 minutes
•If stable, deploys to remaining 95%
•If errors detected, rolls back automatically

Canary deployments protect against bad deploys. Most users never notice this system (it's automatic). Key facts

•Small sites deploy simultaneously to all edges.
•Large sites use canary rollout (5% → 100%).
•Automatic rollback if canary shows errors.

Custom domain DNS configuration

Adding a custom domain requires DNS changes at your registrar:

Root domains (example.com):

Add A records pointing to BYOB's IP addresses:

A    @    192.0.2.1
A    @    192.0.2.2
A    @    192.0.2.3

BYOB provides exact IP addresses when you add the domain.

Subdomains (app.example.com, www.example.com):

Add CNAME record pointing to BYOB:

CNAME    app    yourproject.byob.site

DNS propagation:

DNS changes take 5 minutes to 48 hours to propagate globally. Common registrars (Namecheap, GoDaddy, Cloudflare) typically propagate in 5-30 minutes.

BYOB shows "Waiting for DNS" status until it detects the configuration. Once detected, SSL provisioning begins automatically.

Key facts

•Root domains use A records to BYOB IPs.
•Subdomains use CNAME to yourproject.byob.site.
•DNS propagation takes 5 minutes to 48 hours.

Monitoring and uptime

BYOB monitors deployment health continuously:

Uptime monitoring: Pings deployed sites every 60 seconds from multiple regions. Detects downtime within 1-2 minutes. Error tracking: Monitors HTTP error rates (4xx, 5xx responses). Spikes in errors trigger alerts. Performance monitoring: Tracks response times from each edge location. Slow responses indicate problems. Automatic remediation: If an edge server fails health checks repeatedly, traffic routes around it automatically. Failed servers restart and rejoin when healthy. Status page: BYOB maintains a public status page (status.byob.site) showing current system health and incident history. Key facts

•Uptime monitoring checks sites every 60 seconds.
•Failed edge servers route around automatically.
•Public status page shows infrastructure health.

Geographic performance

Real-world performance metrics from BYOB sites:

North America:

•Time to First Byte (TTFB): 20-40ms
•First Contentful Paint (FCP): 400-600ms
•Largest Contentful Paint (LCP): 800-1200ms

Europe:

•TTFB: 25-45ms
•FCP: 450-650ms
•LCP: 850-1300ms

Asia:

•TTFB: 30-60ms
•FCP: 500-700ms
•LCP: 900-1400ms

Australia:

•TTFB: 35-65ms
•FCP: 550-750ms
•LCP: 1000-1500ms

These metrics are for optimized SvelteKit sites built with BYOB. Actual performance varies by page complexity and user connection speed. Key facts

•Global TTFB averages under 50ms.
•Most pages achieve LCP under 1.5 seconds (Google's "Good" threshold).
•Performance is consistent across all continents.

Bandwidth and fair use

BYOB includes bandwidth in credit pricing:

Fair use policy: Normal websites use 1-100GB bandwidth monthly. This is included at no extra cost beyond deployment credits. Excessive use: Sites serving 1TB+ monthly bandwidth (video streaming, file hosting, massive image galleries) may need custom plans. BYOB contacts you if bandwidth becomes excessive. No bandwidth charges: Standard websites never see bandwidth charges. Deployment credits cover normal traffic. Key facts

•Bandwidth included in deployment credits (no extra charges).
•Fair use covers 99% of websites (1-100GB/month).
•High-bandwidth sites (1TB+) need custom plans.

Infrastructure vs traditional hosting

BYOB (Cloudflare Pages + Workers):

•Deploy in 30 seconds
•Cloudflare's 300+ location global network
•Google SSL (primary) + Cloudflare SSL (backup)
•Auto-scales via Cloudflare's infrastructure
•Zero configuration

Traditional hosting (DigitalOcean, AWS):

•Hours to configure servers
•Single region unless you build multi-region yourself
•SSL requires manual setup (Let's Encrypt or paid)
•Manual scaling (resize servers, load balancers)
•Requires Linux and networking knowledge

Managed platforms (Vercel, Netlify):

•Similar edge network approach
•More framework flexibility than BYOB
•Both use Cloudflare or equivalent CDN infrastructure
•Require Git workflow for deployment

BYOB wraps Cloudflare's enterprise-grade infrastructure into a single-button workflow. The underlying network is the same Cloudflare that powers Shopify, Discord, and millions of production sites. Key facts

•Cloudflare Pages infrastructure powers BYOB (same as Shopify, Discord, and others).
•Vercel/Netlify offer similar CDN capability but require Git setup.
•Traditional hosting requires significant infrastructure expertise.

Frequently Asked Questions

Can I choose which edge locations serve my site?

No. BYOB automatically serves from all edge locations. Users route to the nearest server based on geography. You can't restrict deployment to specific regions.

What happens if an entire region goes down?

Traffic automatically routes to the next nearest region. If the entire Europe region fails, European users route to Middle East or North America edge servers. Latency increases but the site stays online.

Do I pay more for traffic from different continents?

No. Credits cover global deployment. Traffic costs are the same whether users are in India, USA, or Australia.

Can I see bandwidth usage per deployment?

Not currently. BYOB shows total bandwidth usage across all projects in account settings. Per-project bandwidth metrics are planned for future updates.

How does BYOB compare to Cloudflare?

BYOB uses a CDN similar to Cloudflare's edge network. The difference: BYOB integrates build, deployment, and hosting in one platform. Cloudflare is a standalone CDN you configure separately.

Deploy to a global edge network in 30 seconds. Try BYOB →

How BYOB's Deployment Pipeline Works — Edge Network, SSL, and CDN