How do I choose a hosting platform for my app?

Match the platform to what you built. A static site or JAMstack front end goes on a static host like Netlify, Vercel, or Cloudflare Pages. An app with a server and background work fits a PaaS like Railway, Render, or Fly. Reach for raw AWS or GCP only when you have a real reason and someone to run it. Choose by app type, ops appetite, and cost at scale — not by whatever the agent scaffolded first.

What's the difference between staging and production?

Staging is a separate environment that mirrors production so you can test a change against real infrastructure before users see it. Production is the live environment real traffic hits. Keeping them separate — separate URLs, separate databases, separate secrets — means a broken deploy lands on staging first, not on your customers.

Should I set up CI/CD or just deploy manually?

Set up CI/CD. A pipeline that builds, tests, and deploys on every push to your main branch is repeatable, logged, and can roll back. Manual drag-and-drop deploys skip your tests, have no record of what shipped, and are the fastest way to push a broken build to production by accident.

Vibe Coding a Deploy: How to Choose a Hosting Platform

The short answer: when you vibe code, the agent picks a deploy target by default — usually whatever its scaffold templates reach for — and will happily ship straight to prod with no pipeline if you let it. Choose the platform deliberately instead, matched to what you actually built: a static host (Netlify, Vercel, Cloudflare Pages) for a static or JAMstack site, a PaaS (Railway, Render, Fly) for a real backend with background work, serverless for spiky event-driven work, and full IaaS (AWS, GCP) only when you have a reason and someone to run it. Then protect the deploy: a staging environment separate from prod, secrets managed on the platform rather than in the repo, HTTPS on a custom domain, and a CI/CD pipeline that builds and tests before it ships. The platform is reversible; a secret leaked to a public repo and a Friday drag-drop to prod are not.

The agent gets your app running locally and then, asked to "deploy it," reaches for the single deploy path that appears most in its training data. Sometimes that's right. Often it's a static host for an app that needs a server, or a hand-rolled script that uploads a build folder with no tests between you and your users. The deploy is where a vibe-coded project stops being a demo and starts being something real people hit, so it's worth slowing down for twice: once to choose where it runs, once to make the act of shipping safe.

Choose the platform from what you built

Hosting falls into four buckets, and the right one is decided mostly by your app's shape — not by which logo you've seen most:

| Your app is | Best fit | Why | |-------------|----------|-----| | A static site or JAMstack front end (no server, or data at build time) | Static host — Netlify, Vercel, Cloudflare Pages, even static cPanel | Global CDN, free or near-free, HTTPS and deploys built in. Nothing to run or patch. | | An SSR app or a real backend with a database and background jobs | PaaS — Railway, Render, Fly, Heroku-likes | Give it a repo, it builds and runs it. Managed databases, logs, rollbacks, little ops. | | Spiky, event-driven, or request-per-invocation work | Serverless — Lambda, Cloudflare Workers, Vercel Functions | Scale to zero, pay per request. Great for webhooks and bursty APIs; awkward for long-lived connections. | | You need specific infra, compliance, or serious scale — and have someone to run it | Full IaaS — AWS, GCP, Azure | Total control and the lowest unit cost at scale. Also the most ops, the most ways to misconfigure, and the biggest bills if you get it wrong. |

The honest default for a vibe-coded app is: a static host if it's a front end, a PaaS if it has a backend. Both give you HTTPS, a pipeline, and rollbacks for free, which are exactly the precautions below that you'd otherwise have to build. Reaching for raw AWS because it's "what real companies use" is the deploy-layer version of picking NoSQL for a vague scaling vibe — you take on a mountain of ops to solve a problem you don't have yet. The question that decides it isn't "what's most powerful," it's "how much do I want to operate, and what does this cost at 10x my traffic?"

Then make the act of shipping safe

Choosing the platform is half of it. The other half is what the agent skips entirely unless you ask: the guardrails around the deploy. These are where the real damage happens.

Separate staging from production. The agent will wire everything to one environment because that's simplest. Stand up a staging environment that mirrors prod — its own URL, its own database, its own secrets — and let every change land there first. A broken migration on staging is a Tuesday; the same migration on prod is an incident.

Keep secrets on the platform, never in the repo. This is the most common and most expensive vibe-coding mistake at deploy time: the agent hardcodes an API key or commits a .env file to get things working. Every hosting platform has an environment-variables or secrets panel — put your keys there, add .env to .gitignore, and treat any key that ever touched a commit as compromised. This overlaps directly with the networking and credential precautions in security and networking for vibe-coded apps.

HTTPS and a custom domain, from day one. Every platform above gives you free TLS and a domain attachment flow. There's no excuse for shipping plain HTTP, and wiring the domain early means links and cookies don't break when you flip it on later.

A pipeline, not a drag-drop. Manual deploys skip your tests, leave no record of what shipped, and make rollback a guess. Wire CI/CD so a push to your main branch builds, runs the tests, and only then deploys — and so a bad release can be rolled back to the previous build with one click or one command.

Don't ship untested to prod. The pipeline enforces this, but the mindset matters more than the YAML: the deploy is the one step where "it worked in the demo" isn't good enough, because the blast radius is every user at once. Shipping fast and shipping safe aren't opposites — I wrote the whole method for keeping both in shipping fast without breaking things.

Use agents and skills deliberately

A security-and-hardening skill aimed at the deploy config — ask it specifically "where are my secrets, and is anything sensitive in the repo or the build output?" It catches the committed .env and the hardcoded key before they reach a public remote.
A backend-patterns / backend-architecture skill to sanity-check that the platform matches the app — especially the serverless-vs-server call for anything with background jobs or live connections.
A performance-optimization skill once you're live, pointed at cold starts, caching headers, and CDN behavior — the choices that decide whether the deploy feels fast.

The move that de-risks the deploy is the same one that de-risks the backend: have a specialized agent review the generalist's output for the mistakes vibe coding introduces. A generalist agent optimizes for "it deployed"; a security-focused one asks "what did we just expose?" — and that's the question that matters the moment a URL is public.

Your deploy target is more forgiving than your backend — you can usually move hosts — but the habits around it are not. A leaked secret is leaked forever, and a Friday-afternoon drag-drop to prod with no tests is how a good weekend becomes a bad one. Choose the platform from what you built, keep staging and prod apart, manage secrets on the platform, and let a pipeline do the shipping.

This is one of the vibe-coding deep-dives — start from the vibe-coding precautions overview. It pairs closely with how to choose a backend, architecture by user scale, shipping fast without breaking things, and security and networking precautions.