# Install flyctl on GNU/Linux

```bash
$ curl -L https://fly.io/install.sh | sh
```

# Create a SvelteKit app

```bash
$ npm create svelte@latest fly-speedrun
```

# Switch to the node adapter

```bash
$ npm i -D @sveltejs/adapter-node
$ sed -i '' 's/auto/node/g' svelte.config.js
```

# From the root of your app

```bash
$ fly launch
```

# Scale outwards and upwards

```bash
$ fly scale
```

## 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?

## Breaking the Speed of Light, for the Benefit of All

When using SSR with SvelteKit, the speed of light is the limit. Defeat that limit by locating your app near your users, and let them reap the benefits of low response times. Fly.io’s global proxy makes it easy.

## Build SvelteKit Apps with AI Agents

Choose from the leading AI agents for SvelteKit development. Each brings unique strengths to help you build faster and deploy seamlessly on Fly.io.

**Claude**  
Advanced reasoning for complex SvelteKit architectures and component patterns.](/content/sveltekit/agents/claude/index.html)  
  
**Cursor**  
Real-time code assistance with context-aware SvelteKit suggestions.](/content/sveltekit/agents/cursor/index.html)  
  
**GitHub Copilot**  
Seamless GitHub integration with proven SvelteKit development patterns.](/content/sveltekit/agents/copilot/index.html)  
  
**Gemini**  
Multimodal capabilities for SvelteKit apps with rich media processing.](/content/sveltekit/agents/gemini/index.html)

## 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)
- 24/7 support and incident response
- Automatic encryption of data at rest and in transit

## 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:

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

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

```bash
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:

```toml
[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.