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.