Why a build failed, and what to do about it

A failed build always shows a real, evidence-based reason and the one action that actually addresses it, never just “something went wrong.” Here’s what each category means.

“This project needs X to install its dependencies”

The project declares a package manager (npm, yarn, pnpm, or bun) that isn’t installed on your computer. FLY8HT never installs software on your behalf. Click Install {tool} to open its real, official install page, or Use Local Configuration to switch to one you do have.

“Docker is required”

The project ships its own Dockerfile and needs Docker to build it. Click Get Docker Desktop for the official download, or switch to a manual commands-based configuration if the project also supports running without Docker. See Docker, isolation, and why FLY8HT asks for it.

A missing environment variable

The application needs a configuration value FLY8HT detected but isn’t set yet. Click Configure environment to jump straight to the Environment tab and add it. See Environment variables and secrets.

A detected service dependency

The project appears to need a database or another backing service (Postgres, Redis, and so on) that isn’t running. FLY8HT detects these but doesn’t start them automatically. Start the service yourself, then retry.

A plain build-command failure

The command itself exited with an error. The cause is usually a real bug in the project, a genuinely broken dependency, or a typo in a manually-configured command. Expand View full logs for the real output from the tool that actually failed.