---
title: How it works
description: "The build and deploy pipeline: from a JavaScript file to a running sprout behind Caddy."
---

For the build and runtime components behind these steps, see [Architecture](/docs/concepts/architecture).

1. **Write the handler**

    `src/index.js` or `src/index.ts`: `export default { fetch(request) { ... } }`. See [The handler](/docs/concepts/handler).

2. **Build**

    `sproutboat build` runs Porffor + Zig on your machine and produces a single `linux-x86_64` executable (the "sprout"). Your source never leaves the machine.

3. **Deploy**

    `sproutboat deploy` uploads the executable plus `sproutboat.jsonc`-derived sidecars (`bindings.json`, static assets) to the control plane.

4. **The control plane starts it**

    The control plane stores the artifact, starts the sprout behind Caddy, and issues a TLS cert on the first request.

5. **Bindings come online**

    If the deployment declares bindings, the control plane also starts a broker process next to the sprout. The sprout reaches it over loopback for every `env.*` call.

## Cold start and lifetime

Cold start is a process exec plus a socket bind: tens of milliseconds. The process then stays warm. An HTTP-only sprout is stopped after ten minutes idle and started again on the next request; a sprout with cron, queues or alarms stays running.

:::note
This is the deployed-sprout lifecycle. A [standalone binary](/docs/get-started/standalone) skips the control plane, Caddy, and the broker entirely.
:::