How to Deploy a FastAPI + SvelteKit App: Your Options
A FastAPI backend with a SvelteKit single-page app (SPA) isn’t one thing to deploy. It’s three, and that works in your favor: each piece can go wherever suits it best, and you can move one without touching the others.
This post covers where each piece can live and the common ways to combine them. Each setup links to a full step-by-step guide. If you’re still deciding on the architecture itself, start with SvelteKit vs FastAPI.
1. What you’re deploying
| Piece | What it is | Address |
|---|---|---|
| API | FastAPI container | api.example.com |
| App | Static SPA files | app.example.com |
| Database | PostgreSQL | Private |
A marketing site, if you have one, is a fourth piece: more static files, usually at example.com.
Keep the app and the API under the same domain, as in the table. That’s what lets the browser send your session cookie to the API.
2. The frontend
This is the easy part. npm run build gives you a folder of static files, and almost anything can serve them:
- Vercel
- Cloudflare Pages
- Netlify
- Azure Static Web Apps
- AWS S3 with CloudFront
- DigitalOcean
- Plain Nginx on your own server
Many of these have a free tier, and switching later mostly means uploading the same folder somewhere else.
3. The API
This is the only piece that needs a running server, so it’s where your choice matters most.
Most FastAPI apps run in a container, and you have plenty of places to host it:
- Railway
- DigitalOcean
- Fly.io
- Azure Container Apps
- Your own VPS
- FastAPI Cloud (in beta), from the team behind FastAPI
Anything that runs Docker can run the same image, which makes moving between hosts straightforward. We’d skip function-style serverless like AWS Lambda for a full API, because a container is simpler to run and gives you the same app everywhere.
4. The database
Use managed Postgres unless you have a good reason not to. Backups and updates become someone else’s job, which is a bad thing to get wrong by yourself.
Any Postgres will work, so you have plenty of choices:
- Neon
- Supabase
- Railway
- DigitalOcean Managed Databases
- Azure Database for PostgreSQL
- AWS RDS
- Your own VPS, if you’re happy to handle backups yourself
Wherever it lives, keep it in the same region as your API, because nearly every API request talks to the database.
5. Common setups
Each of these reaches the same result. Pick the one that matches how much you want to manage.
- Railway puts everything in one place. It’s the simplest of the five and the quickest way to get live.
- DigitalOcean App Platform runs the container and static sites next to managed Postgres, all with one provider.
- Fly.io + Neon + Vercel picks a specialist for each piece. You get three dashboards instead of one.
- Azure uses Container Apps, PostgreSQL Flexible Server and Static Web Apps. It makes most sense if your company is already on Azure.
- Docker Compose on a VPS runs everything on one server. You get full control, and TLS, backups and updates become your job.
6. What every setup needs
Whichever you pick, the same list applies:
- Environment variables for the API, like the database URL and secrets.
- The API’s address set before you build the frontend, because it ends up inside the static files.
- Migrations run against the production database as their own step, before the new code goes live.
- HTTPS. Most platforms handle it, and on a VPS your reverse proxy does.
- CORS on the API, allowing your app’s exact address with credentials turned on.
Our production guide covers the config, cookies and CORS in detail.
7. How to choose
If you want to be live today, use Railway. If your company already runs on a cloud, stay there. If you want control and don’t mind the upkeep, take a VPS. For a side project, try FastAPI Cloud’s free plan with a static host and a free Postgres tier, knowing that free apps sleep when idle.
The choice isn’t permanent. The API is a container, the frontend is static files and the database is plain Postgres, so you can move one piece at a time as your needs change.
FastSvelte is a SvelteKit SaaS boilerplate built this way, with a Dockerfile for the API and a guide for each of the five setups above.
