---
title: "SvelteKit hosting on Fly.io: from repo to running app with one command"
description: "SvelteKit hosting on Fly.io. Deploy a SvelteKit app with flyctl, add Managed Postgres with one command, and pay per second for the Machines that run."
---

# SvelteKit hosting on Fly.io: from repo to running app with one command

Fly.io is a developer-focused public cloud with all the right features to make your SvelteKit app just work.

[Launch Now](https://fly.io/speedrun)

Ready, Set, Go!

## Speedrun Your SvelteKit App Onto Fly.io

Deploy your SvelteKit app, batteries included, on Fly.io with just a few commands.

[Get Started](https://docs.fly.io/js/frameworks/svelte)

```
> Install flyctl on GNU/Linux
$ curl -L https://fly.io/install.sh | sh

> Create a SvelteKit app
$ npm create svelte@latest fly-speedrun

> Switch to the node adapter
$ npm i -D @sveltejs/adapter-node
$ sed -i '' 's/auto/node/g' svelte.config.js

> From the root of your app
$ fly launch

> Scale outwards and upwards
$ fly scale
```

Not on GNU/Linux? [Install flyctl for your platform.](https://docs.fly.io/flyctl/install)

## Just Works Deployment for Your SvelteKit App

SvelteKit comes out of the box with SSR, CORS, CSRF and XSS protection. Fly.io comes out of the box with HTTP/2, TLS and load balancing. A match made in heaven?

## Server Rendering That Stops When Nobody Is Asking

SvelteKit's SSR needs a running Node server. Fly Proxy stops your Machines when traffic goes quiet and starts them again on the next request. A stopped Machine is not billed for CPU or RAM, and a running one bills per second.

NEW!

## Managed Postgres That Just Works

Add a fully-managed database to your Sveltekit project. Fly.io will take care of:

- Automatic backups and recovery
- High availability with automatic failover
- Performance monitoring and metrics
- Resource scaling (CPU, RAM, storage)
- Automatic encryption of data at rest and in transit

[Learn More](https://fly.io/mpg/)

## Trusted by teams at

- **S3-Compatible Storage With Tigris**
  Working with files? Tigris is S3-compatible object storage run on Fly.io. `fly storage create` makes a bucket and sets its credentials on your app as secrets, so your S3 client reads them from the environment.
- **Supabase Managed PostgreSQL**
  Need a database? No problem. You can use your favourite ORM to plug into Supabase’s managed PostgreSQL right from your Fly.io app.
- **Metrics, Redis & More**
  Fly.io also bundles Grafana for metrics and integrates with Upstash for Redis.

## Ready to Take Flight?

Fly.io is great for SvelteKit developers who want fast, production ready deployments without the hassle of managing the underlying infrastructure. Launch your SvelteKit app in just a few minutes and show it to the world.

[Get Started](https://fly.io/app/sign-up)

## Attach Managed Postgres to your SvelteKit app

Managed Postgres is the supported path. Fly.io runs the cluster for you, handling automatic backups and recovery, high availability with automatic failover, performance monitoring, resource scaling, and encryption of data at rest and in transit. Provision it as part of the launch:

```
fly launch --db mpg
```

Or add one to an app that already exists, in two commands:

```
fly mpg create
fly mpg attach <clusterID> -a your-app-name
```

`fly mpg attach` writes the connection string onto the app as a secret named `DATABASE_URL` and triggers a deploy so the app comes up holding it. The string is the pooled connection URL, which goes through PgBouncer. You never see the password. Your app needs `@sveltejs/adapter-node` either way, because the auto adapter does not produce a server build that can be run directly.

To use it, read it through `$env/dynamic/private`, which resolves at runtime, rather than `$env/static/private`, which is inlined at build time when the secret is not there yet.

Migrations run on every deploy through `release_command`, which whichever migration command your ORM uses:

```
[deploy]
  release_command = "npm run migrate"
```

It runs in a temporary Machine built from the new image, with your secrets loaded, before any Machine takes traffic. A non-zero exit fails the deploy and the previous version keeps serving.

## What you didn't have to set up

Look back at what actually happened. You ran `fly launch`, and either took the database with it or added it with `fly mpg create` and `fly mpg attach`. A standard SvelteKit app with a Postgres database in one region is the ordinary case Fly.io is built for, not a stretch. Here is the work that never appeared:

**A hosting service for your code.** `fly launch` and `fly deploy` build from the directory you are standing in. A SvelteKit project with no git remote at all deploys fine.

**A Dockerfile.** `fly launch` detects SvelteKit and writes the Dockerfile. It lands in your repository where you can read it, edit it, and see it in a diff.

**A connection string.** Attaching writes `DATABASE_URL` onto the app as a secret. The password never lands in your clipboard or your shell history.

**A migration step in a deploy pipeline.** `release_command` runs migrations on a throwaway Machine before any Machine takes traffic. A migration that fails fails the deploy, instead of half migrating production.

**TLS and a hostname.** The app answers on `<app>.fly.dev` with HTTPS from the first request, and the certificate is issued and renewed for you.

**A load balancer or a VPC.** Fly Proxy is already in front of your Machines, and your app reaches Postgres over your organization's private network as soon as the cluster is attached.

None of that work is missing. It is done, and the record of it is a `fly.toml` you can read in one screen, diff in a pull request, and revert with git.