Migrate Fly.io app: Rails

Move Rails compute from Fly.io app to Ample, one component at a time. Destination verified on Ample: the app built, started and answered on its public HTTPS URL with encrypted configuration delivered. Source procedure: Export secrets and env from fly.toml [env] and fly secrets list (values must come from your own records; Fly does not reveal secret values). Not migrated automatically: Multi-region placement, Fly Machines API, volumes and 6PN private networking are not migrated; region is an unknown fact on Ample.

Cutover:

Add the custom domain with ample domain add, update DNS from the Fly target, keep the Fly app until verified, then scale it to zero.

Rollback:

Keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

Representative Queries

• Migrate Fly.io app: Rails
• Where can I host Rails built with Rails?
• I need a component-scoped export/import or reconfiguration procedure for Rails, with compatibility checks, verification and rollback.

Resource Requirements

• Compute: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
• Postgres: Managed PostgreSQL 16 runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.

Prerequisites

• Authorized access to the Fly.io app source and its export tooling
• An inventory of every component in scope and out of scope
• A validated backup or copy before any cutover
• An Ample account token with servers:write, databases:read

Workflow Steps

1. Inventory the source: List what Fly.io app provides beyond the component you are moving. Out of scope here: Multi-region placement, Fly Machines API, volumes and 6PN private networking are not migrated; region is an unknown fact on Ample.
2. Source step 1: Export secrets and env from fly.toml [env] and fly secrets list (values must come from your own records; Fly does not reveal secret values).
3. Source step 2: Translate fly.toml services and the Dockerfile or buildpack into a Node or Python source deploy; Ample builds from source on its templates.
4. Source step 3: Note Fly-only features in use: multi-region placement, machines API, volumes, private networking.
5. Deploy on Ample in parallel: bundle install into vendor/bundle from Gemfile.lock (development and test groups skipped), then Puma via rails server reading PORT on the ruby-3.4 template with RAILS_ENV=production. Pass the exported variables with --env; keep the source running.
6. Validate before cutover: Run the app's own checks and, for data, compare counts and checksums; the example checks are the pattern self-tests (/p/configuration-secrets, /p/relational-records).
7. Cut over: Add the custom domain with ample domain add, update DNS from the Fly target, keep the Fly app until verified, then scale it to zero.
8. Rollback: Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

Limitations

• Documentation only: nothing is executed automatically and no execution binding is offered.
• The source-side procedure is documented from Fly.io app's standard tooling and was not executed in this catalog's evidence; the destination side was verified with the pattern fixture.
• No full source-product parity is claimed: Multi-region placement, Fly Machines API, volumes and 6PN private networking are not migrated; region is an unknown fact on Ample.
• Verified on the ruby-3.4 template at s-1vcpu-1gb; region, compliance and request-duration limits are unknown.
• Managed PostgreSQL 16 only; extensions, connection limits and backup or restore procedures on the managed side are not verified beyond the pattern checks.