# Migrate Render web service: Rails

Move Rails compute from Render web service 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: Copy environment variables and secret files from the Render dashboard into an env file kept out of the repository. Not migrated automatically: Render cron jobs, disks and private-service networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume. Cutover: Add the custom domain with `ample domain add`, update DNS from the Render target, keep the Render service until verified, then suspend it. Rollback: keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

## Representative Queries
- Migrate Render web service: 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
- primitive:compute
- primitive:postgres

## Infrastructure 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 Render web service provides beyond the component you are moving. Out of scope here: Render cron jobs, disks and private-service networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.
2. **Source step 1**: Copy environment variables and secret files from the Render dashboard into an env file kept out of the repository.
3. **Source step 2**: Translate the Render build and start commands (or `render.yaml`) into the repository's manifest or `--build-command`/`--start`.
4. **Source step 3**: Note Render-only features in use: background workers, cron jobs, disks, private services.
5. **Deploy on Ample in parallel**: `ample deploy . --name  --public --env-file .env.production`.
6. **Validate before cutover**: Run the app's own checks and 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 Render target, keep the Render service until verified, then suspend it.
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.
- Source Ref: `tests/deploy-canaries/rails-patterns`

## Success Checks
- **Destination app responds on its public URL**: `http_get` to `/`, expect: `ample canary rails patterns`
- **Configuration-secrets check**: `http_get` to `/p/configuration-secrets`, expect: `see the pattern fixture checks`
- **Relational-records check**: `http_get` to `/p/relational-records`, expect: `see the pattern fixture checks`
- **Data or object counts and checksums**: manual check before cutover.

## Limitations
- Documentation only: nothing is executed automatically and no execution binding is offered.
- The source-side procedure is documented from Render web service'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: Render cron jobs, disks and private-service networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.
- 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.