Understanding the build pipeline

Every build FLY8HT runs is the same real pipeline, shown as a live stage list with real elapsed time per stage, never a spinner with no detail behind it.

The stages

• Analyse: detects the framework, package manager, and Node version this project actually declares.
• Prepare: sets up an isolated workspace (a fresh Docker container when available, a workspace-confined local process otherwise).
• Install: runs the real install command for the detected package manager.
• Build: runs a build step, when the project has one.
• Test: runs tests, if you’ve enabled “run tests when available” in Settings → Builds.
• Start: launches the application and waits for it to actually respond before calling it “Running.”

Local process vs. Docker

When Docker is installed and running, a build executes inside its own disposable container for stronger isolation, since the project’s own code never touches your real environment directly. Without Docker, FLY8HT falls back to a real local process instead, confined to the project’s own workspace folder. You can force either one (or leave it on Automatic) in Settings → Builds. See Docker, isolation, and why FLY8HT asks for it.

While it’s running

“View technical details” expands the real, live log stream from whichever tool is actually running (npm, a Docker daemon, etc.), never FLY8HT’s own paraphrase of it. You can cancel an in-progress build at any point; FLY8HT makes sure the underlying process is actually terminated, not just abandoned in the background.

If it fails

FLY8HT classifies a real failure into one of a few honest categories and gives you the one action that actually addresses it, rather than a generic “something went wrong.” See Why a build failed, and what to do about it.