# Vercel, your own server, or a big cloud: where to host an early product

> How platforms, VPSs and clouds like AWS differ, where vendor lock-in really comes from, and how to think about costs before the first big bill.

Published: 2025-02-13 · Source: https://subxcat.com/articles/choosing-hosting · Author: SUBXCAT

Hosting for an early product is usually chosen once and by accident: wherever "Deploy" was easiest to click is where the project lives. That isn't necessarily bad. But six months later it turns out background jobs have nowhere to run, the bill grew along with traffic, and moving would take a month. Here are the three main options and what the choice depends on.

## Platforms: Vercel, Netlify and similar

You hand over the repository; the platform builds and deploys. Branch previews, HTTPS, a CDN and one-click rollback come out of the box. For a frontend and a light API, this is almost always the best start: zero ops and a fast loop.

The limits appear when the product stops being "a page plus a quick request":

- long-running work hits the function execution time limit;
- persistent connections like WebSockets are supported only partially or need a separate service;
- background workers and scheduled jobs have to live somewhere else;
- you pay for usage: bandwidth, invocations, execution time. Cheap at the start, hard to predict as you grow.

## Your own server

A virtual server for a flat monthly fee. You can run anything on it: the API, a background worker, a queue, the database. Costs are predictable, and one modest server lasts an early product a long time.

The price is that you're the sysadmin now. OS updates, certificates, the firewall, backups, monitoring, restarting crashed processes: all yours. If nobody on the team has done this before, the server becomes a quiet source of risk. Everything works until someone finds the database port open to the internet.

Container platforms take some of this off your plate and sit between a VPS and Vercel: you hand over a Docker image, they run it and restart it.

## A big cloud

AWS, Google Cloud, Azure. Everything you might need is there, plus a great deal you won't. It's a sensible choice when there's a concrete reason:

- customer or regulatory requirements about data location and certification;
- a managed service you can't get elsewhere: a specific database, queues, machine learning;
- the team already has experience and proven infrastructure templates;
- you have startup credits and know what happens when they run out.

Without a reason like that, a cloud mostly gives an early product complexity: permissions, networking, dozens of services with their own settings, and plenty of ways to misconfigure something so your data ends up public.

## Where lock-in actually comes from

Lock-in rarely comes from where your container runs. It comes from the platform's own APIs that your code depends on:

- a proprietary database or key-value store without a standard protocol;
- functions written for one specific edge runtime;
- built-in auth that won't let you export users with their passwords;
- queues and triggers with their own format.

To keep moving possible, stick to the standard: Postgres, S3-compatible storage, config through environment variables, a build that runs on any machine. Use the platform's conveniences by all means; just know which ones you'd have to rewrite later.

## How to think about costs

Exact prices change; the principles don't:

- a flat fee is predictable, while usage-based pricing grows with success and with mistakes, since a script stuck in a loop is also usage;
- outbound bandwidth often costs more than you expect, especially for images and video;
- the managed database is usually the biggest line on the bill, and the worst place to save money;
- turn on a spending cap, or at least a spending alert, on day one.

## The mixed setup

For many early products the sensible answer isn't one option but a combination: the frontend on a platform for previews and the CDN, the API and background jobs on a server or container platform, and a managed database with the provider's backups. Each part lives where it's most comfortable, and none of them holds the others hostage.

SUBXCAT can look at your product and propose a hosting setup that fits it, rather than whatever was easiest to click on day one.