page:guides:hono:deployment diagnostics

Diagnose Deployment Failures for Hono

Summary

Deployment diagnostics for a Hono app on Ample. Verified on Hono: 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 --kind runtime, so the cause is read from the framework's output rather than guessed. Build and start: npm install and npm run start with @hono/node-server on the node-22 template.

Prerequisites

• A Hono project (npm install and npm run start with @hono/node-server on the node-22 template)
• An Ample account token with servers:write

Framework and Workload

• Framework: Hono
• Workload: Diagnose deployment failures

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.

Execution Status

• Release Status: Published
• Support Status: Verified
• Execution Status: Unbound

Workflow 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.
   Command: ample logs --kind build
3. Read the runtime log
   For health_check_failed the runtime log carries the Hono 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.
   Command: ample logs --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.
   Command: ample logs --kind build

Limitations

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

Cost Estimate

• Currency: USD
• Monthly Amount: 5.0
• Basis: size prices from pricing.toml (loaded by the API) at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty
• Components:
  • App server (s-1vcpu-1gb) - $5.0

Evidence Summary

• Kind: canary_run
• Summary: Hono pattern fixture deployed on Ample with CANARY_FAIL=boot (npm install and npm run start with @hono/node-server on the node-22 template); 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 --kind runtime, so the cause is read from the framework's output rather than guessed.

Next Actions

• Browse the catalog index: Browse the catalog index
• Search published recipes by intent, stack and constraints: Search published recipes
• Prepare a side-effect-free deployment plan for an authorized project: Prepare deployment plan
• Read the existing agent authentication setup: Read agent setup
• Browse Hono: Browse Hono
• Browse Troubleshoot deployment: Browse troubleshoot deployment
• Browse Public web service: Browse public web service

Examples

• Title: Hono pattern fixture
  Description: Verified deployment diagnostics on Hono.
  Source Ref: tests/deploy-canaries/hono-patterns

Success Checks

• Description: failed deploy reports health_check_failed synchronously
  Kind: manual
  Expect: ample deploy exits 1 with error.code health_check_failed
• Description: runtime log carries the app's own error line
  Kind: manual
  Expect: ample logs --kind runtime shows the framework's error output before the health-check verdict

Last Verified At

• 2026-09-21T02:23:07Z