# Migrate Fly.io app: Django

Move Django 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.

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

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

## Migration 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**: `pip install` into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template. Pass the exported variables with --env; keep the source running.
   ```bash
   ample deploy . --name <name> --public --start "python3 run.py" --env-file .env.production
   ```
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.

## Success Checks
- Destination app responds on its public URL.
- Configuration-secrets check from the destination example.
- Relational-records check from the destination example.
- Data or object counts and checksums match the source.

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

## Cost Estimate
- Monthly Amount: $10.00  
  - **Components**:
    - App server (size: s-1vcpu-1gb, quantity: 1.0, monthlyAmount: $5.00)
    - Managed PostgreSQL database (size: s-1vcpu-1gb, quantity: 1.0, monthlyAmount: $5.00)  
- Note: Destination always-on monthly price of the tested sizes; apps auto-pause when idle. Source costs are unknown to Ample.

## Examples
- **Django pattern fixture (destination)**: Verified destination basis: Django compute.

## Evidence Summary
- Destination side verified: the Django pattern fixture deployed on Ample (pip install into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template) and its checks passed (the app built, started and answered on its public HTTPS URL with encrypted configuration delivered).