# Diagnose deployment failures for Rails

## Summary

Deployment diagnostics for a Rails app on Ample. Verified on Rails: the same app deployed with a deliberate boot failure (CANARY_FAIL=boot): `ample deploy` exited 1 with a coded failure (health_check_failed when the process dies at boot, public_ingress_failed when the framework boots but every request answers 500) and the app's own error line was readable with `ample logs <deployment_id> --kind runtime`, so the cause is read from the framework's output rather than guessed. Build and start: 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.

## Infrastructure requirements

- [Compute](/discover/primitive/compute): verified (Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.)

## Prerequisites

- A Rails project (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)
- An Ample account token with servers:write

## Exact tested configuration

- template: `ruby-3.4`
- runtime: `ruby`
- size: `s-1vcpu-1gb`
- install: `bundle config set --local path vendor/bundle && bundle config set --local without 'development test' && bundle install`
- start: `bundle exec rails server -b 0.0.0.0 -p $PORT`

## Steps

1. **Read the failure code.** Deploy is synchronous. Exit 1 with build_failed means the isolated build failed; health_check_failed means the app built but never answered on PORT (it crashed at boot or bound the wrong port); public_ingress_failed means it answered on PORT but the public URL returned an error status (a request handler or bootstrap failed); exit 2 means a required preflight action is blocking.
2. **Read the build log.** The last lines name the failing command and its output.

```
   ample logs <deployment_id> --kind build
   ```
3. **Read the runtime log.** For health_check_failed the runtime log carries the Rails process output: in the verified run the deliberate boot failure's own error line was there, followed by the platform's health-check verdict and the start command it ran.

```
   ample logs <deployment_id> --kind runtime
   ```
4. **Fix and redeploy once.** Change the source, the environment or the command override, then run ample deploy again. Do not loop deploys to poll status; an unchanged redeploy is a no-op.
5. **Verify.** Fetch the live URL on the example; on failure read the build and runtime logs.

```
   ample logs <deployment_id> --kind build
   ```

## Tested examples

- **Rails pattern fixture** (tests/deploy-canaries/rails-patterns): Verified deployment diagnostics on Rails.

## Success checks

- failed deploy reports health_check_failed synchronously
- runtime log carries the app's own error line

## Limitations

- Verified on the ruby-3.4 template at s-1vcpu-1gb; other sizes and Rails major versions are not verified.
- Region, compliance attestations and request-duration limits are unknown and not claimed.

## Cost estimate

Estimated 5.00 USD per month (size prices from pricing.toml at build revision a1b8c38919e59cd035ebabaced73cf84ece24371).
- app server x1 `s-1vcpu-1gb`: 5.00 USD

Always-on monthly price of the tested sizes; apps auto-pause when idle. Buckets are allocation-priced per quota and not included.

## Verification evidence

- canary_run on 2026-09-21T03:15:51Z at revision `49962bc-dirty (CLI 0.1.21)`: Rails pattern fixture deployed on Ample with CANARY_FAIL=boot (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); the same app deployed with a deliberate boot failure (CANARY_FAIL=boot): `ample deploy` exited 1 with a coded failure (health_check_failed when the process dies at boot, public_ingress_failed when the framework boots but every request answers 500) and the app's own error line was readable with `ample logs <deployment_id> --kind runtime`, so the cause is read from the framework's output rather than guessed. (expires 2027-03-20T03:15:51Z)

## Execution binding

No execution binding. This recipe is documentation only; nothing is executed automatically.