How builds work

Every deployment is built on a fresh, isolated machine that exists for that build only. Nothing is reused between builds except files that didn't change, which aren't uploaded again.

The steps

1. Preparing

   The machine starts and fetches your source: the files the CLI uploaded, or a clone of your repository.

2. Installing

   Your dependencies are installed with the install command: by default, the package manager your lockfile names. A static site skips this step.

3. Building

   Your build command runs. For a backend (Hono, Futon) or a server-rendered Rasengan.js app, Hiraiship then bundles the server code into a single Worker module.

4. Packaging

   The output is collected and stored. Each file is stored by its content, so a file that didn't change since the previous deployment isn't stored or uploaded again.

5. Publish

   The output goes live on Cloudflare's network with your environment variables, and the environment's domains start serving it.

Each step is timed. Follow them live on the deployment's page in the dashboard, or in your terminal; see Build logs.

What a build can't do

• Reach any host on the internet. Only package registries, GitHub and nodejs.org are reachable. See Build environment.
• Read your environment variables. They're given to your app at runtime, not to the build. See Reading variables.
• Run past your plan's timeout, or start when your plan's build slots are all busy. See Build queue and Limits.

When a build fails

The deployment is marked Failed, the step that failed is highlighted, and its logs stay available. Your current deployment keeps serving traffic. See Troubleshooting.