How to deploy a FastAPI app

The dev server is not your deployment

uvicorn main:app --reload is perfect for local work and wrong for production. To deploy, you containerise the app, run it under a real ASGI server bound to all interfaces, and put it somewhere that stays up and terminates HTTPS for you. Sinkron handles that last part: you hand it the container, it runs your API across independent machines behind one load-balanced HTTPS URL, restarts it if it crashes, and bills by the second of runtime.

Deploy it in four steps

1. Run uvicorn for real, on 0.0.0.0

Bind to 0.0.0.0 (not 127.0.0.1) and a fixed port so traffic can reach it, and drop --reload. For a single small instance, uvicorn alone is fine:

• uvicorn main:app --host 0.0.0.0 --port 8000

You don't need to run many worker processes per container — instead, run more runners and let Sinkron load-balance across them. That keeps each container simple and lets the platform handle scaling and failover.

2. Containerise it

A short Dockerfile does it: a Python base, install from requirements.txt (include uvicorn and fastapi), copy your code, and set the start command:

• FROM python:3.12-slim
• COPY requirements.txt . && RUN pip install -r requirements.txt
• COPY . .
• CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

New to building images? The quickstart covers it, and the deploy-a-container guide has the general version.

3. Deploy and get your URL

Point Sinkron at your image, tell it the port (8000 above), pick a CPU/RAM footprint, and choose your runners. It comes up at https://<your-slug>.apps.sinkron.network with TLS, load balancing, and restarts handled — no reverse proxy, no certificates to manage. Top up a balance by card or USDC first; there's no subscription or minimum.

4. Pay only while it runs

Billing is by the second. If your balance runs low we email you first; if it hits zero the app stops so you never go past your deposit. Stop it yourself any time and the cost drops to zero.

FastAPI-specific things worth getting right

• Keep state external. Treat the container filesystem as disposable. Your database, file uploads, and anything you need to persist belong in an external store (a managed DB, or object storage with your own S3 keys) so a restart or a move between machines doesn't lose data.
• Add a health endpoint. A trivial GET /health that returns 200 makes restarts and load-balancing decisions cleaner.
• Set config via environment variables. Read secrets and connection strings from the environment, set them on the session — don't bake them into the image.
• Async stays async. Nothing about running it this way changes your code; your async def routes work exactly as they do locally.

What it costs

A small API's footprint is light, so it runs for pennies an hour and you only pay while it's running. It's free to sign up and look around. Because you're billed for runtime by the second rather than a flat monthly box, a low-traffic API usually comes out cheaper than the standard $5 VPS that bills around the clock. See how pricing works or the comparison with a $5 VPS.

When a plain VPS is the better call

Straight answer: choose a VPS or dedicated box if your API needs persistent local disk you won't move to external storage, full OS-level control, or it's a heavy, always-busy service run as fixed infrastructure. For the common case — a small-to-medium API you want online, on HTTPS, and not babysat — this is the cheaper, lower-effort path. Building in another stack? See the guides for Flask and Node.js.