# Migrate Railway app: Rails

Move Rails compute from Railway 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 variables from the Railway service (Variables tab or `railway variables`) into an env file kept out of the repository.

Not migrated automatically: Railway cron schedules, volumes and private networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.

## Prerequisites
- Authorized access to the Railway 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

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

## Workflow Steps
1. **Inventory the source**: List what Railway app provides beyond the component you are moving. Out of scope here: Railway cron schedules, volumes and private networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.
2. **Source step 1**: Export variables from the Railway service (Variables tab or `railway variables`) into an env file kept out of the repository.
3. **Source step 2**: Translate `railway.json`/Nixpacks settings into the repository's build and start commands; Ample detects Node and Python builds itself.
4. **Source step 3**: Note Railway-only features in use: cron schedules, volumes, private networking, templates.
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 Railway target, keep the Railway service until verified, then remove 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.

## Limitations
- Documentation only: nothing is executed automatically and no execution binding is offered.
- No full source-product parity is claimed: Railway cron schedules, volumes and private networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.

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

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

## Cost Estimate
- **Currency**: USD
- **Monthly Amount**: 10.0
- **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
  
## Evidence Summary
- Destination side verified: the Rails pattern fixture deployed on Ample with all checks passed and verified with the pattern fixture.

## Last Verified
- **Date**: 2026-09-20T21:55:28Z