## Migrate DigitalOcean Droplet app: Rails

Move Rails compute from DigitalOcean Droplet 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:
Collect the process environment from the droplet (systemd unit, PM2 or supervisor config) into an env file kept out of the repository. 
Not migrated automatically: Cron jobs, local upload directories and firewall rules are not migrated; move uploads to a bucket and data to a managed database.

### Cutover:
Add the custom domain with `ample domain add`, update DNS from the droplet IP, keep the droplet until verified, then power it off.

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

### Prerequisites:
- Authorized access to the DigitalOcean Droplet 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 DigitalOcean Droplet app provides beyond the component you are moving. Out of scope here: Cron jobs, local upload directories and firewall rules are not migrated; move uploads to a bucket and data to a managed database.
2. **Source step 1**: Collect the process environment from the droplet (systemd unit, PM2 or supervisor config) into an env file kept out of the repository.
3. **Source step 2**: Replace the droplet's process manager and reverse proxy with the repository's start command; Ample provides HTTPS and supervision.
4. **Source step 3**: Inventory what else runs on the droplet: databases, cron, local uploads.
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 droplet IP, keep the droplet until verified, then power it off.
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.
- No full source-product parity is claimed: Cron jobs, local upload directories and firewall rules are not migrated; move uploads to a bucket and data to a managed database.
- Verified on the ruby-3.4 template at s-1vcpu-1gb; region, compliance and request-duration limits are unknown.

### Cost Estimate:
- **Monthly Amount**: $10.00
  - **App server**: 1 x s-1vcpu-1gb = $5.00
  - **Managed PostgreSQL database**: 1 x s-1vcpu-1gb = $5.00

### Evidence Summary:
Destination side verified: the Rails pattern fixture deployed on Ample (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) and its checks passed.

### References:
- [HTML Documentation](/content/migrate/digitalocean-droplet-app/rails/index.html)
- [Markdown Documentation](/content/migrate/digitalocean-droplet-app/rails.md)
- [JSON Documentation](https://api.ample.computer/v1/catalog/recipes/page%3Amigrate%3Adigitalocean-droplet-app%3Arails)