Deploy hooks

Deploy hooks let you run a small piece of JavaScript at two points in a deploy — to gate it, or to verify it — without adding a sidecar or CI step. They run in a sandbox on the platform, with a small heli API for talking to your services.

The two hooks

• Pre-deploy hook — runs before anything starts building or rolling out. Use it as a gate: check a condition, call an external API, assert an invariant. If it throws (or you call heli.fail(...), or an assertion fails), the deploy is aborted and nothing is touched.
• Post-deploy hook — runs after the new version is up and healthy on an internal port, but before traffic switches to it. Use it to smoke-test the new release. If it fails, the candidate is discarded and the old version keeps serving — a bad deploy never reaches your users.

Writing a hook

Each service has a Hooks tab with an in-app code editor (syntax highlighting, autocomplete, and a Test-run button so you can try a hook without deploying).

The heli API available inside a hook includes:

• heli.env.get(key) / heli.env.set(key, value) — read and set the service’s variables.
• heli.services — look up other services in the project.
• heli.http(...) — make outbound HTTP calls (subject to the allow-list, below).
• heli.notify.slack(url, message) / heli.notify.webhook(url, payload) — send a notification.
• heli.test(name, fn) and heli.expect(value) — write assertions that fail the hook.
• heli.fail(message) — abort the deploy with a message.

Outbound HTTP allow-list

By default a hook can call any host. You can set an allow-list (comma-separated hosts; exact or subdomain match) so hooks — and their notifications — can only reach approved destinations. An empty list means unrestricted.

Next

• Pair hooks with Health checks for verify-before-promote plus automatic restart.
• See Deploys & rollback for where hooks sit in the pipeline.