Coming from Fly.io

Fly.io runs applications as individually configurable Machines. Encore starts from the APIs, services, and infrastructure declared with its TypeScript or Go SDK, using them to build an application model. Machine-level settings in fly.toml therefore map either to environment configuration or to workloads that remain outside Encore.

How the concepts map

Fly.io	Encore
Fly App	Encore application or environment, depending on how the Fly Apps are divided
Machine / process group	No direct equivalent; Encore deploys services from the application model
http_service or services	Encore API gateway and API endpoints
Fly Postgres (unmanaged) or Managed Postgres	SQL database, external Postgres, or a migrated database
Volume	No direct primitive; choose a database, object storage, or externally managed disk
Secret	Encore secret
Scheduled Machine	Cron job when the task can be exposed as an API endpoint
Private network and Flycast	Service-to-service APIs or separately configured private connectivity
Region and Machine size	Per-environment infrastructure configuration

These primitives are declared in application code using TypeScript or Go.

A Fly Machine is an independently controllable VM. An Encore service is a logical boundary in the source code, so Machine lifecycle operations, process groups, and per-Machine placement do not translate directly.

Migrate applications and processes

Move HTTP handlers to Encore API endpoints. Existing TypeScript or Go logic can remain behind the endpoints, and an existing router can initially be wrapped with a catch-all handler; see Migrating an existing system.

For each process group, identify its trigger and lifecycle. Use Pub/Sub for event consumers and cron for scheduled endpoint invocations. Keep workloads that require SSH access, custom Machine lifecycle control, special kernels, attached GPUs, or an indefinite non-HTTP process outside Encore unless they are redesigned.

For each process group, identify its trigger and lifecycle. Use Pub/Sub for event consumers and cron for scheduled endpoint invocations. Keep workloads that require SSH access, custom Machine lifecycle control, special kernels, attached GPUs, or an indefinite non-HTTP process outside Encore unless they are redesigned.

Do not copy fly.toml settings directly. For HTTP services, ports and handlers become Encore API definitions; CPU, memory, regions, and scaling are deployment settings. Fly health checks, concurrency settings, autostop/autostart behavior, and Machine restart policy need to be reconsidered for the target deployment.

Migrate Postgres, volumes, and secrets

Encore Cloud does not directly import Fly Postgres (unmanaged) or Fly.io Managed Postgres. Create a target Postgres database and transfer the schema and data, or keep the existing database temporarily as an external dependency. Reachability differs between the two. Fly Postgres (unmanaged) runs as a Fly App that can be given a public IP and a TLS-terminated Postgres service, so an external consumer can connect to it directly, and it remains your operational responsibility. Fly.io Managed Postgres runs inside your Fly.io private network and is not reachable over the public internet, so an external consumer needs WireGuard or fly mpg proxy. Preserve the appropriate backup, failover, and monitoring plan until migration is complete.

Volumes are local to a server and tied to a region. Encore has no equivalent disk primitive. Move files to object storage, structured data to a database, or keep an external storage system. Applications using multiple volumes must already account for replication or partitioning; preserve those semantics during transfer.

Volumes are local to a server and tied to a region. Encore has no equivalent disk primitive. Move files to object storage, structured data to a database, or keep an external storage system. Applications using multiple volumes must already account for replication or partitioning; preserve those semantics during transfer.

Copy sensitive values from Fly secrets into Encore secrets and set them per environment. fly.toml environment values that are not secret should become constants or external configuration where appropriate.

Networking, domains, and coexistence

Fly private networking names, Flycast addresses, Anycast services, and WireGuard connectivity do not carry over automatically. Replace internal calls between migrated components with Encore service APIs. For components that remain on Fly.io, establish a reachable, authenticated endpoint or private connection supported by the target cloud; do not assume .internal Fly DNS is available outside the Fly organization network.

Deploy and verify Encore using its environment URL before changing DNS. Add the hostname as an Encore custom domain, then update DNS. Geographic routing and data residency may change, so confirm target regions and latency before cutover.

Migration plan

1. Inventory Fly Apps, process groups, Machines, regions, volumes, Postgres clusters, secrets, and private-network dependencies.
2. Move one stateless HTTP component to Encore and keep its external API stable.
3. Redesign workers and scheduled Machines according to their triggers.
4. Establish connectivity to components that remain on Fly.io.
5. Rehearse database and volume transfers, including the final write freeze or replication cutover.
6. Verify regions, domains, health, and latency before shifting traffic.
7. Retain Fly Machines and volumes until data and rollback requirements are satisfied.

For shared PaaS guidance, see Coming from a PaaS. Fly.io behavior referenced here is documented in Machines, scheduled Machines, Volumes, Private Networking, Fly Postgres (unmanaged), and Managed Postgres.