Use Vercel when the app is primarily a Next.js or frontend project with request-driven functions. Use Netlify for a frontend-led application that benefits from its deploy workflow and integrated database branching. Use Railway when you need an always-on API, worker, WebSocket server, or several services without managing virtual machines. Use Fly.io when you already understand containers and need direct control over processes, regions, networking, or machine sizes.
That answer depends on the workload, not which logo appears in the AI builder’s deploy button. A host that fits a static frontend can be the wrong place for a long-running worker. A host that runs any container can also give a solo founder more infrastructure to operate than the app warrants.
This is a documentary comparison, not a hands-on benchmark. I did not deploy one controlled application to these platforms, so this article does not claim measured differences in cold starts, build reliability, support quality, or real-world cost. I checked the Vercel, Netlify, Railway, and Fly.io documentation on 2026-08-02, and the Cloudflare Pages, Render, and GitHub Pages documentation on 2026-08-16, then compared the capabilities that determine architecture. Limits, regions, and billing rules can change, so verify the linked documentation before committing production data or spend.
Vercel vs Netlify vs Railway vs Fly.io
| Decision | Vercel | Netlify | Railway | Fly.io | Cloudflare Pages | Render | GitHub Pages |
|---|---|---|---|---|---|---|---|
| Runtime model | Static/SSR deployments and request-driven Functions | Static/SSR deployments, Edge Functions, and request/background Functions | Persistent container services, cron jobs, and lightweight Functions | Fly Machines running container images and process groups | Static assets plus Pages Functions on the Workers runtime | Persistent instances built from a native runtime or your Dockerfile | Static files only; no server-side languages such as PHP, Ruby, or Python |
| Database | Connect a Marketplace or external data service | Netlify Database provides managed Postgres and preview branches; external services also work | One-click Postgres and other database containers, documented as unmanaged services | Managed Postgres or database software on Machines and volumes | D1, KV, R2, and Hyperdrive through bindings; no managed Postgres of its own | Fully managed Postgres, including restore to an earlier state | None; the browser calls an API hosted somewhere else |
| Background work | Cron Jobs, Queues, and durable Workflows | Scheduled Functions and 15-minute Background Functions | Always-on workers and cron services | Worker Machines and application-managed schedulers/queues | No Cron Triggers on Pages; a Function can send to a queue but cannot consume one | Cron jobs and background workers as their own service types | None on the site; a scheduled Actions workflow runs in CI |
| WebSocket server | Public beta for Node.js Functions; connections inherit Function duration and Fluid Compute rules | Request-oriented function model, not an owned always-on socket process | Supported by persistent services | Supported by Machines and Fly Proxy networking | A Durable Object cannot be created inside a Pages project; bind one from a separate Worker | Documented as supported on web services | Not possible on static hosting |
| Regions | Static delivery is global; Function placement and multi-region options depend on plan | Static delivery is global; each Function runs in one selected region | Services and replicas can be placed across supported regions | Machines can be placed across Fly.io regions | Assets and Functions run across Cloudflare’s network | Oregon, Ohio, Virginia, Frankfurt, and Singapore | No region setting |
| Pull-request preview | Automatic; data isolation remains separate configuration | Automatic; Netlify Database can create an isolated database branch | PR Environments can copy the project topology into an isolated environment | Review apps require a GitHub Actions workflow or equivalent automation | Automatic; each branch and pull request gets its own hash-prefixed preview URL | Preview environments need a Pro plan, bill like normal services, and start with empty datastores | None built in |
| Rollback | Reassign production to an earlier deployment; external state is separate | Publish an earlier atomic deploy; external state is separate | Redeploy an earlier image and variables while retained | Redeploy or roll back to a previous image; volume/data state is separate | Roll back to any production deployment that built successfully; previews are not valid targets | Roll back to a retained build artifact; disks keep their state | Republish an earlier commit or re-run its deployment |
| Built-in visibility | Deployment logs and Vercel Observability | Deploy/Function logs and plan-dependent Observability | Logs plus CPU, memory, disk, and network metrics | Logs and Prometheus-compatible platform/application metrics | Build and deployment logs; Workers Logs, Logpush, and Tail Workers are Workers-only | Logs plus email and Slack notifications for failed deploys and unhealthy services | The Actions run log; no application logs |
| Spend control | Hobby usage caps; Pro Spend Management can alert, webhook, or pause production | Credit-based Free has a hard limit; paid plans can auto-recharge credits | Alerts and a hard usage limit that takes workloads offline | Provisioned-resource billing; Fly.io says it does not provide billing alerts | Free plan caps builds at 500 a month; Function requests count against the Workers plan | Billed per paid instance and prorated by the second; the one documented monthly spend limit covers pipeline minutes, and notifications cover deploys and health, not spend | Free on public repositories, with soft limits in place of a bill |
Use the table to eliminate mismatches. A persistent Railway or Fly.io service is the clearer starting point for connections that may outlive a Function invocation. Netlify has a specific advantage when every preview needs an isolated Postgres branch. Fly.io fits an existing container that needs regional machine control; Railway fits several connected services in one project.
Vercel: strongest when the framework and runtime already fit
Vercel’s Functions model suits request-driven server code, especially Next.js. Preview deployments are automatic for non-production branches, and environment variables can be scoped to Preview, Production, and custom environments.
The boundary is the runtime. Vercel announced public-beta WebSocket server support for Node.js Functions on 22 June 2026. Those connections run on Fluid Compute and inherit Function duration and pricing rules. The announcement conflicts with an older limits page whose WebSocket section has not caught up, so confirm the beta’s current requirements. Queues and Workflows cover asynchronous jobs; an always-on daemon or connection that must outlive a Function invocation still needs a persistent service.
An external database is not part of the deployment artifact. A code rollback does not reverse schema or data changes, and preview isolation still depends on database credentials, as the separate preview vs production guide explains.
For cost control, Pro teams can configure Spend Management to notify, call a webhook, or pause production deployments. Pausing creates a 503, so the ceiling is also an availability decision. Hobby uses fixed included-usage caps. Choose Vercel when the app fits its managed request model.
Netlify: frontend deploy workflow plus an integrated Postgres option
Netlify combines atomic deploys with edge and request functions. Its Function configuration fixes synchronous execution at 60 seconds, scheduled execution at 30 seconds, and Background Functions at 15 minutes. A Function uses one configured region; static assets use the global network.
With Netlify Database, deploy previews receive their own database branch copied from production at creation time. Branch changes are isolated, but copied records may still be sensitive and require access controls.
Its rollback flow publishes an earlier successful deploy without rebuilding it. A later Git deploy can overwrite the rollback; databases and external services need separate recovery.
Billing uses credits across platform resources. The Free plan has a hard monthly credit limit; paid credit-based plans can enable auto-recharge. Choose Netlify when its frontend workflow, duration limits, and database branching fit. Put an always-on worker elsewhere.
Railway: persistent services without starting from raw infrastructure
Railway provides persistent web services and workers, cron jobs, and lightweight Functions. It detects common builds or uses the repository’s Dockerfile, making it a direct step up when a process must stay alive.
WebSockets and server-sent events work on persistent services without special platform configuration. APIs, workers, caches, and databases can share private networking. Railway’s database documentation explicitly classifies those templates as unmanaged: the customer owns backups, recovery, tuning, access, and maintenance.
PR Environments can reproduce a base environment’s services, networking, and variables for a pull request. They still need a safe data-seeding policy.
Railway’s deployment reference ties rollback availability to plan-specific retention. It restores a retained image and variables, not data. Built-in metrics cover resources; request and business signals need application telemetry.
Railway provides alerts and a hard usage limit. Its documentation warns that reaching the hard limit shuts workloads down. Choose it for connected services without owning machines directly.
Fly.io: machine and region control for teams ready to operate it
Fly.io runs container images as Fly Machines. Machines can stay running, auto-stop, attach volumes, expose HTTP or TCP services, and run in chosen regions. That fits WebSockets, workers, and custom processes.
Git deployment and pull-request review apps are workflows you configure, not the default project behavior. Fly.io’s guide uses GitHub Actions; multi-service apps need more workflow logic.
Fly.io offers Managed Postgres and permits databases on Machines with volumes. Volumes are regional resources, and a code rollback does not rewind one.
Fly.io’s rollback guide redeploys an earlier image and warns that data and current configuration do not travel back with it. Logs and Prometheus-compatible metrics are available; operators choose alerting and instrumentation.
Cost follows provisioned resources. Fly.io’s cost guide says it does not currently support billing alerts, and stopped Machines can still leave other billable resources. Choose it when process and region control justify more operational work.
Cloudflare Pages, Render, and GitHub Pages
Cloudflare Pages puts static assets and Pages Functions on the Workers runtime, with bindings to D1, KV, R2, Hyperdrive, and Workers AI. Two documented gaps decide whether it fits. A Pages Function can send to a queue but cannot consume one, and a Durable Object has to be created in a separate Worker, and Cloudflare’s own Workers-versus-Pages comparison lists Cron Triggers, Workers Logs, Logpush, and Tail Workers as Workers features that Pages does not have. Rollback targets any production deployment that built successfully, and preview deployments are not valid targets. The free ceiling is 500 builds a month, one at a time, and Function requests count against your Workers plan. A front end with request-driven endpoints fits here; scheduled and always-on work needs a Worker beside it.
Render is the closest match to Railway in this set. Its web services run as persistent instances built from a native runtime or your Dockerfile, WebSocket connections are documented as supported, and cron jobs and background workers are their own service types across five regions. The difference that matters against Railway is the data layer: Render’s Postgres is fully managed and can restore a database to an earlier state, where Railway’s documentation classifies its database templates as unmanaged. The preview story costs more than it looks. Preview environments require a Pro plan, bill like ordinary services, and create new datastores that copy no data, so a pull request starts against an empty database unless a deploy hook seeds it. Rollback reuses a retained build artifact, disks keep their state through it, and the documented notifications cover failed deploys and unhealthy services rather than spend. Render’s billing FAQ bills each paid instance prorated by the second, and the only monthly spend limit it documents applies to pipeline minutes rather than to the compute the app is actually running.
GitHub Pages is the one to rule out first if you plan to charge for the app. It does not support server-side languages such as PHP, Ruby, or Python, so everything past a static front end lives on another host. Its limits page sets a 1 GB published site, a soft 100 GB of bandwidth a month, and a soft 10 builds an hour, and states that Pages is not allowed to be used to run an online business, an e-commerce site, or commercial software as a service. Marketing pages and documentation belong there. The product you sell does not.
Where to deploy a web app: a requirements-first decision model
Write down these answers before opening any pricing calculator:
- Does the app need an always-on process, worker, TCP service, or connection that may outlive a Function invocation? If so, start with Railway or Fly.io; consider Vercel only when its duration-bounded WebSocket beta fits.
- Are backend operations request-driven and bounded? Vercel or Netlify may remove more operational work.
- Where is the database, and which compute region is nearest?
- Does every pull request need isolated data? A preview URL alone is insufficient.
- What rolls back: code, variables, schema, or data?
- Which logs, latency measures, error rates, and alerts exist without another vendor?
- Does the cost ceiling stop service, continue billing, or require cleanup?
A split deployment can put the frontend on Vercel or Netlify and an API or worker on Railway or Fly.io. Use that boundary only when its added network, credentials, monitoring, and failure modes are worthwhile.
What moving an AI-built app actually changes
Moving a Lovable app off its own hosting entirely is a bigger decision than swapping a deploy target. The exported repository may contain a static Vite frontend, a server-rendered framework, serverless endpoints, or assumptions about the builder’s own cloud services. Identify the runtime before connecting the repository to another host.
Environment variables do not migrate safely by copying an entire .env file without review. Public prefixes such as VITE_ and NEXT_PUBLIC_ are framework rules that can place values in browser JavaScript regardless of the host. The bill is the surprise you notice. The environment-variable behavior is the one you don’t, until someone opens dev tools. Whether the platform underneath covers any of it is a separate question, answered in is Vercel safe to deploy on.
Across the 21 third-party apps in the AxonBuild audit corpus, audited in June and July 2026, no pillar scored higher than Secrets & Credentials, at 84.4 out of 100 on average: the leaked-key stereotype is mostly wrong, and the keys mostly sit where they should. The exception that sticks with me was a spam classifier with no server behind it, 138 lines of plain JavaScript that got almost everything else right. Its paid LLM key rode along in a config script the deployed page pulls in, in plain view of anyone who opened dev tools. The app scored 71 and still landed in the red band, because that one architecture decision put an uncapped bill in a stranger’s hands. None of that is host-specific, and the moment a variable list gets copied into a new dashboard is exactly when a trust boundary that held on the old host gets copied somewhere it doesn’t.
You didn’t pick your host. A code generator did. The bill and the leak surface came bundled with it.
The database is a separate migration. Keeping an existing Supabase or other managed database while moving compute is smaller than exporting and restoring the database too. Rehearse schema and credential changes away from customer data, since a migration rehearsed directly against the one production database turns a routine host switch into an outage. A proper staging environment for that database is worth setting up once, deliberately, before the migration starts.
The host changes where code runs. It does not automatically repair authorization, query performance, secrets, backups, or recovery. Why your AI-built app stalls at 100 users covers application bottlenecks that move with the repository, while is your AI-built app ready to launch covers the broader release evidence.
Common questions about deployment targets
Which platform is best for a vibe-coded app?
There is no universal winner. Vercel fits Next.js and bounded requests; Netlify fits frontend-led deploys and Postgres branching; Railway fits persistent services; Fly.io fits containers needing machine and region control. Among the narrower options, Cloudflare Pages fits a front end with request-driven endpoints, Render fits an always-on service that wants managed Postgres, and GitHub Pages is static-only hosting whose terms rule out running a commercial product on it.
Should I choose Railway or Fly.io for a backend?
Choose Railway for a dashboard-first, multi-service workflow. Choose Fly.io for direct control of containers, processes, machine sizes, and regions when you can configure the deployment automation.
Can Vercel or Netlify host WebSockets?
Vercel added public-beta WebSocket server support for Node.js Functions in June 2026. Connections run on Fluid Compute and inherit Function duration and pricing rules, so confirm that beta status and bounded invocation model fit the application. Netlify’s primary backend model is request and event functions rather than an owned always-on socket process. For a persistent, generally available socket server, evaluate Railway, Fly.io, or another container platform.
Which platform has the safest previews?
Safety depends on data and credentials, not the preview URL. Netlify Database has automatic per-preview branches. Railway can reproduce service topology in PR Environments. Vercel and Netlify both scope environment variables by deploy context. Fly.io review apps can be isolated through workflow configuration. In every case, verify whether production data, payments, email, storage, and webhooks remain reachable.
Your builder got the app working. Can it keep working?
When more people rely on it, AxonBuild fixes broken workflows, finishes stuck features, and keeps releases moving without replacing what already works.
