INFRASTRUCTURE

What it needs

• 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

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

TESTED CONFIGURATION

Exactly what was tested

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

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

LIMITATIONS

Know the limits

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

COST

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.

EVIDENCE

Verification evidence

• canary_run on 2026-09-21T03:06:43Z at revision 49962bc-dirty (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.