There are many ways to put your app on the internet. The landscape can feel overwhelming, so let's break it down — starting with what we recommend.
The simplest options are PaaS (Platform as a Service) — you push code, they handle infrastructure. PaaS comes in two flavors: serverless (scales to zero, pay per use) and always-on (runs 24/7, fixed cost).
You push code, they run it as functions. Your app scales to zero when nobody's visiting — you don’t pay for idle servers. No servers to manage.
The tradeoffs: cold starts when scaling back up, request timeouts that limit long-running work like WebSockets or background jobs, and higher costs at scale compared to always-on platforms.
| Platform | Notes |
|---|---|
| Vercel | Auto-detects frameworks, great free tier, easy region control |
| Netlify | Similar to Vercel, strong for static sites and JAMstack |
Vercel is what we recommend and officially support. It auto-detects React Router, has a generous free tier, and lets you pick a region close to your database — which is the thing that matters most for performance.
?Why Vercel?You push code, they run it as a server that stays on 24/7 — like the old Heroku model. No Docker needed. More predictable than serverless — no cold starts, no request timeouts — but you pay for the server even when nobody's visiting.
| Platform | Notes |
|---|---|
| Render.com | Simple UI, free tier for static sites, easy deploys from GitHub |
| Railway | Similar to Render, developer-friendly, good DX |
Render.com is our second officially supported platform. It's a great fit when you need an always-on server — useful for background jobs, WebSocket connections, or apps with steady traffic where cold starts would be annoying.
These platforms run your code at locations around the world, close to your users. Sounds great — but for full-stack apps that talk to a database, there are caveats.
Cloudflare Workers is the main platform here — V8 isolates, not full Node.js, 128 MB memory limit, but a massive global network. By default, your Worker runs near the user, which can make database queries slower, not faster. Region placement fixes this by pinning to a specific region.
?Why your code and database should live close togetherEdge computing shines for static sites, APIs that don't need a database, and middleware (like auth checks or redirects). For full-stack apps with a database, the platforms above are a simpler starting point.
You bring a Dockerfile instead of just pushing code. Useful when you need non-Node.js dependencies, precise runtime control, or long-running processes like WebSocket servers or queue workers.
| Platform | Notes |
|---|---|
| Google Cloud Run | Scales to zero, pay-per-request, deep Google Cloud integration |
| Fly.io | Global deploys, machines API, can also run always-on containers |
If you already know Docker and want fine-grained control over your runtime environment, these are powerful options. But for most Gista.js users, the serverless or app platform categories above are a simpler starting point.
A VPS gives you a virtual machine in the cloud — you get root access to a Linux server and manage everything yourself. Cheaper than PaaS for always-on workloads, but you're responsible for everything: setup, deployments, updates, backups, monitoring, and incident response.
| Provider | Notes |
|---|---|
| DigitalOcean | Simple UI, great docs, popular with indie developers |
| Hetzner | Best price-to-performance ratio, European data centers |
| Linode (Akamai) | Long-running, reliable, recently acquired by Akamai |
| Vultr | Global regions, competitive pricing, bare metal options |
VPS is a good middle ground if PaaS feels too limiting but full IaaS feels like overkill. You'll need to set up Node.js, a process manager (like PM2), a reverse proxy (like Nginx or Caddy), SSL certificates, and your own deployment pipeline. It's more work than Render or Railway, but you get predictable pricing and full control over the server.
With IaaS, you rent raw infrastructure — VMs, networking, storage — and build everything on top. Full control, full responsibility.
| Platform | Notes |
|---|---|
| AWS | The biggest, most options, steepest learning curve |
| Google Cloud | Strong if you're already in the Google ecosystem |
| Azure | Common in enterprise, Microsoft-heavy shops |
This is what engineering teams at larger companies use. The flexibility is real — but so is the operational overhead. You'll spend time on things that have nothing to do with your product: security patches, load balancers, container orchestration, log aggregation.
Unless you have a specific reason (compliance, data residency, extreme scale), PaaS is a better starting point.
You can also run your app on a physical server you own — in a data center, a closet, or under your desk. This is how the internet worked before cloud computing existed, and it still works.
It's the ultimate in control: you own the hardware, the network, and every layer of the stack. But it's also the most work — hardware failures, power outages, network configuration, and security are all on you.
For most people building web apps today, this is overkill. But it's worth knowing it exists — if only to appreciate how much PaaS platforms handle for you.
Start with Vercel (serverless PaaS) or Render.com (always-on PaaS). Both are free to start, deploy straight from GitHub, and require zero infrastructure knowledge. You push code, you get a URL — that's the entire workflow.
You can always migrate later — when the bill grows, move to an always-on platform. Your Gista.js app runs anywhere Node.js runs, so you're never locked in.