Migrating from Fly.io

Fly.io and Atlasflow both run containers on microVMs, so your application image will feel right at home. The main differences are how you configure and deploy: Atlasflow is GitHub-driven and uses project settings instead of a fly.toml and CLI.

# What maps over

# Steps

1. Create a project from your GitHub repository and reuse your existing Dockerfile.
2. Set the internal port to 3000. Fly maps internal_port in fly.toml; Atlasflow forwards traffic to port 3000. Make sure your app listens on 0.0.0.0:3000.
3. Drop fly.toml. Atlasflow configures the root directory, Dockerfile path, and branch in project settings rather than a config file.
4. Move secrets to environment variables, split into build and runtime scopes.
5. Health check on /. Fly health checks are configurable; Atlasflow checks GET / for a 2xx response. See Container requirements.
6. Domains and TLS. Add a custom domain and verify DNS. Atlasflow issues certificates automatically, so you don't manage certs yourself.

# Things to know

• There's no Atlasflow CLI; deployments are driven by Git pushes and the dashboard.
• Multi-region is available on the Team plan.
• Persistent volumes and managed data services differ from Fly. Managed database, storage, and queues are coming soon.

# Next steps

• How Atlasflow works: the runtime model.
• Configuration: replace fly.toml.
• Custom domains: domains and automatic TLS.