Deploy Like You Have Done It for Decades

The Vibe Guide, Part 4 of 6 — Hosting compared honestly, by people who remember racking servers

The Unfair Advantage Nobody Sells

Every hosted AI builder leads with the same pitch: "one-click deploy!" And for their audience, that's genuinely valuable — deployment is scary if you've never done it.

But if you've deployed large applications for decades, one-click deploy isn't a feature. It's a ceiling. You already know how to run things at scale; what you want from 2026's platform landscape is to keep that control while shedding the toil you've already proven you can do. This part is the honest map.

The through-line: the vibe workflow from Parts 1–3 produces standard, portable projects — so every deploy target on this page is available to you. That optionality is itself the strategy. Platform users deploy where the platform deploys. You deploy where the workload wants to live.

The Decision Framework First

Before the vendor tour, the three questions that actually decide it:

1. What's the compute shape? Static assets? Edge functions? Long-lived processes? WebSockets? GPU?
2. What's the failure cost? A game demo going down is a shrug. A revenue system going down is a pager.
3. Who maintains it in year two? (Foreshadowing: Part 5's answer is "partly, your autonomous agents.")

The Contenders

Cloudflare Pages / Workers — the static-and-edge workhorse

This is where Abyss Drift lives (abyssdrift.pages.dev), and for that workload it's close to unbeatable.

• Strengths: absurdly generous free tier (unlimited static requests), global CDN by default, Workers for edge logic, wrangler pages deploy dist is a one-liner from any CI or laptop. No cold-start drama for static. Great for games, landing pages, docs, SPAs.
• Honest limits: Workers' runtime is not Node — it's a V8 isolate environment with its own compatibility layer. Long-running or heavy-compute tasks don't fit. The platform is opinionated about what "server" means.
• Veteran's take: default choice for anything static-plus-sprinkles. The free tier means side projects never generate a bill, which matters more than people admit — billing anxiety kills side projects as surely as bit rot.

Vercel — the framework-native option

• Strengths: if the project is Next.js, nothing matches the integration — preview deployments per branch, edge/serverless functions, image optimization, analytics. Preview URLs per PR quietly become your review workflow. First-class DX end to end.
• Honest limits: pricing scales with usage in ways you should model before success, not after. The more you use its proprietary primitives (specific caching, middleware behaviors), the more the app shape assumes Vercel.
• Veteran's take: pick it when you're deep in the Next.js ecosystem and preview-deploy velocity matters to a team. Keep an exit path in mind: standard Next.js output remains reasonably portable if you avoid the deepest platform hooks.

Self-hosted (VPS / dedicated / your own metal) — the veteran's home turf

• Strengths: total control. Any runtime, any daemon, any port, any weird protocol. Predictable flat cost. WebSockets, GPU workloads, long-lived processes, cron jobs, databases co-located with compute — all trivially yours. A $10–20/mo VPS with Docker Compose and Caddy runs an astonishing amount of software. And it's where your autonomous agents (Part 5) will live, since they're long-running containerized processes — exactly the shape serverless platforms hate.
• Honest limits: you own the pager. Patching, backups, TLS renewals (Caddy/Let's Encrypt make this nearly free now), capacity planning. The toil is real even when it's familiar.
• Veteran's take: this is where decades of ops experience converts directly into money saved and capability gained. The trick in 2026 is that AI agents change the maintenance math — Claude Code writes your Compose files and systemd units, and Part 5's autonomous layer watches the logs.

The hosted-builder deploys (Lovable Cloud and friends) — for completeness

• Strengths: zero-knowledge deployment, integrated backend, fine for validating an idea.
• Honest limits: your app lives inside someone's product decisions and pricing changes. Migrating out later is a project. For anyone reading this series, it solves a problem you don't have.

The Table

The Portfolio Approach

Veterans don't pick one. The realistic steady state for an active builder:

• Cloudflare Pages for the static fleet — games, demos, landing pages, docs. Free, fast, forgettable in the best way.
• Vercel (or Pages + Workers) for framework-heavy apps where preview deploys earn their cost.
• A self-hosted box for everything with a pulse: databases, WebSocket servers, background workers, internal tools — and your autonomous agent layer.

Each project's CLAUDE.md (Part 3) should state its deploy target and command, so both you and your agents always know how a given repo ships.

Deployment as a Prompt

One genuinely new thing about 2026: deployment knowledge is now legible to your agents. A concrete example — infrastructure work as a Claude Code task:

Add a GitHub Actions workflow: on push to main, run tests, build, and deploy dist/ to Cloudflare Pages with wrangler. Use repository secrets for the API token. Fail loudly, deploy atomically.

That's a correct, reviewable CI pipeline in one prompt — because you knew precisely what to ask for. The decades didn't get obsoleted; they got compressed into better prompts. A newcomer gets a pipeline that works; you get the pipeline you would have built, in 2% of the time, and you can smell it when the agent gets it wrong.

What You Should Take Away

1. Portability is the strategy. The open source workflow means every deploy target is on the menu — choose per workload, not per platform allegiance.
2. Static → Cloudflare Pages, framework-native → Vercel, anything with a pulse → your own box.
3. Model platform pricing before success, not during it.
4. Ops experience compounds with AI — you write better infrastructure prompts and catch worse infrastructure mistakes.
5. Keep a self-hosted box. You're about to need it.

Because now the app is built, engineered, and deployed. The next problem is the oldest one in software: who maintains it?

Next: Part 5 — Your Autonomous Twin, where NanoClaw and PicoClaw take over PM triage, bug fixes, feature branches, and testing — while you're doing literally anything else.