## Migrate Heroku app: Rails

Move Rails compute from Heroku 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 config vars with `heroku config -s -a ` into an env file kept out of the repository. 
- Not migrated automatically: Heroku add-ons other than Postgres, release-phase scheduling, dyno autoscaling and Heroku Scheduler are not migrated; use `--release-command` for release tasks.

### Cutover:
- Add the custom domain with `ample domain add`, update DNS from the Heroku DNS target, keep the Heroku app until verified, then scale it down.

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

### Workflow Steps
1. **Inventory the source**: List what Heroku app provides beyond the component you are moving. Out of scope here: Heroku add-ons other than Postgres, release-phase scheduling, dyno autoscaling and Heroku Scheduler are not migrated; use `--release-command` for release tasks.
2. **Source step 1**: Export config vars with `heroku config -s -a ` into an env file kept out of the repository.
3. **Source step 2**: Translate the `Procfile` web process into the start command (`--start` or the package manifest's start script); worker processes need a separate `--kind worker` service.
4. **Source step 3**: Note buildpacks and add-ons in use; managed databases replace Heroku Postgres, other add-ons need their own plan.
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.
   - Command: `ample deploy . --name <your-app-name> --public --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 Heroku DNS target, keep the Heroku app until verified, then scale it down.
8. **Rollback**: Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

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

### 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 Heroku 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: Heroku add-ons other than Postgres, release-phase scheduling, dyno autoscaling and Heroku Scheduler are not migrated; use `--release-command` for release tasks.
- 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.

### Cost Estimate
- Currency: USD
- Monthly Amount: 10.0
- Basis: Size prices from pricing.toml at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty
- Components:
  - App server: s-1vcpu-1gb (Quantity: 1.0, Monthly Amount: 5.0)
  - Managed PostgreSQL database: s-1vcpu-1gb (Quantity: 1.0, Monthly Amount: 5.0)
- Note: Destination always-on monthly price of the tested sizes; apps auto-pause when idle. Source costs are unknown to Ample.