---
title: "Diagnose deployment failures for Phoenix"
description: "Deployment diagnostics for a Phoenix app on Ample."
canonical_url: "https://ample.computer/guides/phoenix/deployment-diagnostics"
last_updated: "2026-09-21"
---

# Diagnose deployment failures for Phoenix

Canonical URL: https://ample.computer/guides/phoenix/deployment-diagnostics
Formats: [HTML](https://ample.computer/guides/phoenix/deployment-diagnostics) | [Markdown](https://ample.computer/guides/phoenix/deployment-diagnostics.md) | [JSON contract](https://api.ample.computer/v1/catalog/recipes/page%3Aguides%3Aphoenix%3Adeployment-diagnostics)
Recipe ID: `page:guides:phoenix:deployment-diagnostics` | Revision: `r1` | Catalog revision: `cat_f13ab9a494120b5e`

Status: release `published`, support `verified`, execution `unbound`

## Summary

Deployment diagnostics for a Phoenix app on Ample. 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.

Path: [Agent hosting discovery](/discover/discovery) / [Frameworks and execution targets](/discover/stack) / [Frameworks](/discover/stack/frameworks) / [Phoenix](/discover/stack/framework-phoenix) / [Diagnose deployment failures for Phoenix](/guides/phoenix/deployment-diagnostics)

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

## Exact tested configuration

- template: `elixir-1.18`
- runtime: `elixir`
- size: `s-1vcpu-1gb`
- install: `mix local.hex --force && mix local.rebar --force && MIX_ENV=prod mix deps.get --only prod`
- build: `MIX_ENV=prod mix compile && MIX_ENV=prod mix release --overwrite`
- start: `PHX_SERVER=true _build/prod/rel/$(ls _build/prod/rel | head -n 1)/bin/$(ls _build/prod/rel | head -n 1) start`

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

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

## Success checks

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


## Cost estimate

Estimated 5.00 USD per month (size prices from pricing.toml at build revision 515b7316fc6e5a81679407ae0c811146ceb2c5c7).
- 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: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)

Last verified: 2026-09-21T03:06:43Z


## Execution binding

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

## Next actions

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

Actions describe possible next steps. They are typed data, not commands, and grant no permission.