Choosing Your Deployment Stack: A Framework for Modern Web Apps

The Deployment Scale

"Should I use Vercel or Cloudflare Workers?" is the wrong question. The real ones: how much control do you actually want? And what happens to costs as you scale?

Building your own edge network is expensive - we're talking millions just for the infrastructure. These platforms let you buy into that capability at a fraction of the cost.

The right choice depends on: product stage, team size, budget, how much you want to invest in infrastructure, and honestly - how much you enjoy infra work.

What is Edge Runtime?

If you've used Vercel, Netlify, or even Lovable - your code runs somewhere. But where? And does it matter?

Traditional deployment looks like this: your app runs on a server somewhere (let's say us-east-1 in Virginia). Every request from Tokyo, São Paulo, or Berlin travels across the ocean to that single location, processes, then travels back. Latency adds up - sometimes 200-300ms just in network travel.

Edge runtime inverts this. Instead of one server handling global traffic, your code runs in 200+ locations simultaneously. When a user in Tokyo makes a request, it's handled by a server in Tokyo. Berlin hits Berlin. São Paulo hits São Paulo.

Where Do Apps Actually Deploy?

Following up on the CI/CD pipeline post, this answers the question: where are applications actually being deployed?

The short answer: Cloudflare Workers for the frontend and server-side rendering, Convex for backend logic and database.

The Stack

Cloudflare Workers

Every Woltex app runs on Cloudflare Workers - serverless functions that execute at the edge, close to users worldwide.

Apps Deployed

Build Flow

pnpm --filter waitlist build

npx wrangler deploy

Convex BaaS

Convex handles the backend - database, server functions, and real-time sync. BaaS (Backend as a Service) means you write your backend logic, but they handle the database, scaling, and infrastructure.

Why Convex?

Edge Functions vs Database Location

Here's a common gotcha: having edge functions doesn't mean your data is at the edge. If your database lives in a single region (say, us-east-1), every query from Tokyo still has to cross the Pacific.

Convex addresses this with their edge-optimized architecture:

• Query functions run close to your users (read replicas at the edge)
• Mutations are routed to the primary database (writes go to one place for consistency)
• Real-time subscriptions use intelligent caching - they track which queries are affected by mutations and push updates only when needed

Deployment

Convex deploys happen alongside app deployments when backend code changes:

deploy-convex:
  if: needs.detect-changes.outputs.convex == 'true'
  steps:
    - name: Deploy to Convex (production)
      if: github.ref == 'refs/heads/main'
      run: pnpm --filter @woltex/convex run deploy
      env:
        CONVEX_DEPLOY_KEY: ${{ secrets.CONVEX_DEPLOY_KEY }}

Azure VM (n8n + Monitoring)

Not everything fits the edge model. Long-running workflows, persistent services, and self-hosted analytics need a traditional VM.

Why a VM for these?

• n8n needs persistent connections, queue workers, and runs workflows that can take minutes
• Analytics (Rybbit) requires a database and shouldn't run on edge functions
• Monitoring needs to store time-series data and run 24/7

For a full walkthrough of the n8n setup, see Production n8n: Queue Workers, Metrics & Monitoring.

Full Deployment Flow

From local development to production:

Why This Stack?

Pros

Tradeoffs

Conclusion

This is what works for Woltex - an AI workspace that needs low latency globally, real-time data sync, and fast iteration cycles. Your optimal stack might look completely different.

Building a fintech app? You might prioritize compliance and auditability over edge performance. Running a content-heavy site? A simpler platform-managed solution might be all you need. Shipping a game or collaborative tool? Real-time latency becomes everything.

The framework matters more than the specific choices: understand where you sit on the control-complexity spectrum, know your cost model at scale, and pick tools that match your current stage - not where you hope to be in three years.

Start simple. Migrate when it hurts. Optimize for shipping.

Next Steps