// Migration Guide · 2026

Migrate from Fly.io to Runsite

Fly.io is powerful, and it's also a lot of flyctl, TOML and Machines API. Runsite gives you the same Docker hosting in Frankfurt without the DevOps. Bring your Dockerfile and skip the fly.toml ceremony.

{ }
fly.toml
on Fly.io
git push → build
EU
live stack
Frankfurt · eu-central
Start the migration → See the 6 steps
~15 min
typical migration
Zero DevOps
keep your workflow
Keep Fly.io running
until you cut over
Zero DevOps Required
Frankfurt EU Data Center
100% GDPR Compliant
∞ Free Tier — Forever

// the mental model

Every Fly.io concept has a Runsite home

Fly.io gives you low-level control through fly.toml and the Machines API. Runsite trades that for simplicity, but every fly.toml concept still has a home. Bring your Dockerfile and we build it for you; the rest maps cleanly. Honest about what's automatic and what you handle once.

fly.toml 
app = "my-api"
primary_region = "fra"

[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 8080
  force_https = true

[[vm]]
  memory = "512mb"
  cpus = 1
  • flyctl deploy
    fly.io
    →
    git push → build auto
    No CLI, no Machines API — just push
  • [build] dockerfile
    fly.io
    →
    Any Dockerfile, built for you auto
    Your existing Dockerfile works unchanged
  • [http_service] internal_port
    fly.io
    →
    Web service port auto
    force_https is on by default
  • primary_region = "fra"
    fly.io
    →
    Frankfurt (eu-central) auto
    Already where Runsite runs — EU residency
  • Fly Postgres
    fly.io
    →
    Managed PostgreSQL you do
    Provision in Frankfurt, then pg_dump → restore
  • fly secrets
    fly.io
    →
    Environment variables you do
    fly secrets list → paste once, encrypted

// step by step

From Fly.io to live in the EU

Six steps. Most of them take seconds. Fly.io keeps serving traffic until you flip your DNS.

  1. 1

    Create a Runsite project

    ~30 sec

    Sign in at runsite.app and create an empty project. No flyctl install, no Machines API to learn.

  2. 2

    Connect your Git repo

    Any Dockerfile

    Authorize GitHub, GitLab or Bitbucket. Bring your existing Dockerfile and Runsite builds and runs it for you, no fly.toml required.

  3. 3

    Recreate Fly Postgres in Frankfurt

    Managed Postgres

    Provision a managed PostgreSQL with one click. It lives in the EU and comes with a connection string ready to wire into your env.

  4. 4

    Move your secrets

    fly secrets list

    Run fly secrets list to see your keys, then paste the values into Runsite. Secrets are encrypted at rest and never logged.

  5. 5

    Migrate your database

    pg_dump → pg_restore

    pg_dump from your Fly Postgres and restore into Runsite with pg_restore. Your DATABASE_URL is already wired to the new database.

  6. 6

    Deploy & cut over DNS

    Live in < 2 min

    git push, verify on your Runsite URL, then point your custom domain when ready. Fly.io keeps serving until you flip DNS, so you can roll back any time.

// no surprises

What moves on its own — and what you touch

Honest about the boundaries. The supported stack is recreated in one click; a short list needs a human, and Runsite flags every item.

✓

Imported automatically

  • ✓ git push deploys — bring any Dockerfile, built for you
  • ✓ internal_port / [http_service] → web service port with HTTPS
  • ✓ Always-on containers — no Machines API or flyctl
  • ✓ Custom domains & automatic TLS certificates
  • ✓ Frankfurt region — EU data residency by default
⚑

You handle once

  • → fly secrets → environment variables, paste once
  • → Fly Postgres data — move with pg_dump / pg_restore
  • → Volumes — map to a Runsite persistent disk
  • → Multi-region edge — consolidate to a single Frankfurt region

// fly.io problems → runsite solutions

Common Fly.io frustrations — sound familiar?

Every Fly.io frustration, solved.

Fly.io problem

"Fly.io has a steep learning curve"

Machines API, fly.toml, volumes, regions — Fly.io is powerful but requires significant DevOps knowledge.

Runsite solution

Git push and done

Connect your GitHub repo, pick a region, deploy. No config files, no CLI learning curve.

Fly.io problem

"Fly.io is a US company"

Even with EU regions, Fly.io is subject to US jurisdiction and the CLOUD Act.

Runsite solution

EU-registered entity

Runsite is an EU company. Your data is governed by European law, period.

Fly.io problem

"Usage-based billing is unpredictable"

Per-second VM billing and bandwidth charges make it hard to predict monthly costs.

Runsite solution

Fixed plans + hard caps

Know exactly what you'll pay. Set a spending limit that can't be exceeded.

// comparison

Runsite vs Fly.io

Side-by-side. No marketing fluff — just facts.

Feature Runsite Fly.io
Setup Complexity ✓ Git push deploy flyctl CLI + TOML config
EU Data Centers ✓ Frankfurt (eu-central) ✓ Multiple EU regions
GDPR Compliance ✓ EU entity, full compliance ✗ US company
Free Tier ✓ Permanent ✓ $5/mo free allowance
Managed PostgreSQL ✓ From €5/mo ✓ Fly Postgres
Docker Support ✓ Any Dockerfile ✓ Firecracker VMs
Spending Limits ✓ Hard cap + alerts ✗ Usage-based only
Learning Curve ✓ Minimal — connect GitHub, deploy Steep — Machines API, volumes, TOML

// migration questions

Migrating from Fly.io, answered

Do I have to keep maintaining fly.toml?

No. Runsite doesn't need a fly.toml. You bring your existing Dockerfile and Runsite builds and runs it, with runtime, port and HTTPS handled for you. No flyctl, no Machines API, no TOML to keep in sync.

Does my Dockerfile work as-is?

Yes. If Fly.io built your app from a Dockerfile, Runsite uses the same Dockerfile unchanged. Your internal_port maps to the web service port and HTTPS is on by default.

How do I move my Fly Postgres data?

Run pg_dump against your Fly Postgres and restore into a freshly provisioned Runsite PostgreSQL with pg_restore. The new connection string is auto-wired into DATABASE_URL, so your app picks it up on the next deploy.

Will there be downtime during the migration?

No. Your Fly.io app keeps serving traffic while you build and verify on Runsite. You cut over by switching DNS only once you're confident, and you can point DNS back at Fly.io to roll back.

I use Fly.io's multi-region edge. What happens to that?

Runsite runs in a single EU region, Frankfurt (eu-central). You trade global edge distribution for simplicity and guaranteed EU data residency. For most European-facing apps that's a win; if you genuinely need worldwide edge, Fly.io may still fit better.

Why migrate from Fly.io to Runsite?

Runsite removes the operational overhead: git push instead of flyctl, fixed pricing with hard spending caps instead of per-second usage billing, and an EU-registered entity for real GDPR compliance rather than just EU regions under a US company.

Leave Fly.io behind

Bring your fly.toml. We'll handle the rest — in Frankfurt.

Start your migration →
✓ No rewrites ✓ Zero downtime ✓ Deploy in 2 min ✓ EU servers