## The short version

Deployment diagnostics for a Phoenix app on Ample.

### WHAT WAS VERIFIED

Verified on Phoenix: 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: mix deps.get, MIX_ENV=prod mix compile and mix release in the builder, then the release bin script with PHX_SERVER=true on the elixir-1.18 template; PORT, DATABASE_URL and SECRET_KEY_BASE read in config/runtime.exs.

### INFRASTRUCTURE

## What it needs

- [Compute](/content/discover/primitive/compute/index.html): verified (Apps run in isolated x86_64 Firecracker microVMs; sizes are the priced VM sizes.)

### PREREQUISITES

## Before you start

- A Phoenix project (mix deps.get, MIX_ENV=prod mix compile and mix release in the builder, then the release bin script with PHX_SERVER=true on the elixir-1.18 template; PORT, DATABASE_URL and SECRET_KEY_BASE read in config/runtime.exs)
- An Ample account token with servers:write

### STEP BY STEP

## How to do it

1. 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. 2

### Read the build log
   
   The last lines name the failing command and its output.
   
   ```
   ample logs <deployment_id> --kind build
   ```

3. 3

### Read the runtime log
   
   For health_check_failed the runtime log carries the Phoenix 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. 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. 5

### Verify
   
   Fetch the live URL on the example; on failure read the build and runtime logs.
   
   ```
   ample logs <deployment_id> --kind build
   ```

### EXAMPLES

## Tested examples

- **Phoenix pattern fixture** (`tests/deploy-canaries/phoenix-patterns`): Verified deployment diagnostics on Phoenix.

### SUCCESS CHECKS

## How to know it worked

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

### COST

## Cost estimate

Estimated 5.00 USD per month (size prices from pricing.toml at build revision ca0b484a7a9957c573a88d3a32dc603c3c10135a).

- app server x1 `s-1vcpu-1gb`: 5.00 USD

Upper-bound monthly price of the tested sizes. Buckets are allocation-priced per quota and not included.

### EVIDENCE

## Verification evidence

- canary_run on 2026-09-21T03:06:43Z at revision `49962bc (CLI 0.1.21)`: Phoenix pattern fixture deployed on Ample with CANARY_FAIL=boot (mix deps.get, MIX_ENV=prod mix compile and mix release in the builder, then the release bin script with PHX_SERVER=true on the elixir-1.18 template; PORT, DATABASE_URL and SECRET_KEY_BASE read in config/runtime.exs); 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:06:43Z)

### EXECUTION

## Execution binding

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

### NEXT ACTIONS

## Typed next actions

- Browse the catalog index (`GET /v1/catalog` on the api origin; authentication not required, approval not required)
- Search published recipes by intent, stack and constraints (`POST /v1/catalog/search` on the api origin; authentication not required, approval not required)
- Prepare a side-effect-free deployment plan for an authorized project (`POST /v1/catalog/plan` on the api origin; authentication required, approval not required)
- Read the existing agent authentication setup (`GET /mcp/setup` on the api origin; authentication not required, approval not required)
- Browse Phoenix (`GET /v1/catalog/nodes/stack%3Aframework-phoenix` on the api origin; authentication not required, approval not required)
- Browse Troubleshoot deployment (`GET /v1/catalog/nodes/intent%3Atroubleshoot-deployment` on the api origin; authentication not required, approval not required)
- Browse Public web service (`GET /v1/catalog/nodes/pattern%3Apublic-web-service` on the api origin; authentication not required, approval not required)

Actions describe possible next steps. They are typed data, not commands, and grant no permission. Public discovery never provisions anything; planning requires your own authenticated token and approval happens in your client.

### ABOUT THIS RECIPE

## Identifiers and status

Recipe `page:guides:phoenix:deployment-diagnostics`. Revision r1.

release **published** support **verified** execution **unbound**

Formats: [HTML](/content/guides/phoenix/deployment-diagnostics/index.html) | [Markdown](/content/guides/phoenix/deployment-diagnostics.md) | [JSON contract](https://api.ample.computer/v1/catalog/recipes/page%3Aguides%3Aphoenix%3Adeployment-diagnostics)