In the Allure CLI, how do `allure open`, `allure serve` and `allure watch` differ, and why is none of them a way to host a report for your team?

## Three commands, three jobs | Command | Input it takes | What it does | Survives the process? | |---|---|---|---| | `open` | a generated report directory | starts a local server on it, opens a browser | yes -- the directory was already on disk | | `serve` | results directories | generates into a temporary directory, then serves it | no -- the temporary tree is deleted on exit | | `watch` (Allure 3) | results directories | regenerates continuously as new results land | no -- it clears its output at start | `open` defaults its report directory to `allure-report`; `serve` defaults its results directories to `allure-results`. Both take `-p/--port` and `-h/--host` in Allure 2. ## `serve` is a shortcut, not a product Allure 2's `serve` is literally the other two commands glued together: it creates a temporary directory, generates the report into it, and then runs the same code path as `open` on it. Because the directory is temporary, a shutdown hook walks and deletes it when the process ends. That is the right behaviour for what the command is for -- looking at a run once, locally, without leaving a report directory behind -- and it is exactly why it is the wrong tool for anything a second person needs to see. Note also that `serve` never trips the "directory already in use" guard, since the destination it generates into is new every time. Allure 3 keeps the same idea and makes the relationship explicit: `open` and `serve` are **two invocation paths on one command**. Given a path that already holds a report, it serves it; given results patterns, it generates into a temporary directory, serves that, and cleans up when interrupted. ## A correction worth carrying A widespread claim is that `allure serve` was dropped in the newer major and that `watch` replaced it. That is wrong on both halves: - `serve` exists in **both** majors. In Allure 3 it is an alias of `open` on the same command. - `watch` is an **additional** command with a different job. It watches results directories and updates the report in real time while a suite is still running, and by default it ignores whatever results were already on disk when it started, reacting to files written afterwards. It also clears its output directory when it starts, so it is not a way to look at a finished run. If you want the one-shot "generate and show me" behaviour, `serve` is still it. ## Why none of these is hosting The server the CLI starts is a **preview** server, and Allure 2 enforces that rather than merely documenting it: 1. It binds only a loopback host. Ask it for any other `--host` and it refuses, with a message telling you to generate the report and serve the static files with a production web server. 2. It rejects requests whose `Host` header is not local, so tunnelling or proxying to it does not turn it into a shared endpoint either. 3. It blocks the calling thread until you interrupt it. It is a foreground command, not a service with a lifecycle. 4. In the `serve` case the content is in a temporary directory that disappears with the process. None of this is arbitrary. A preview server has no access control, no TLS, no caching story and no deployment story, and a report often contains screenshots, logs and stack traces that are not public. Hardening it into a hosting server would be a rewrite; refusing the role is the honest design. ## The shape that actually works 1. **Generate** the report to a directory as a step in the run. 2. **Publish** that directory -- all of it -- to whatever serves static files for your organisation. 3. **Link** the resulting URL from wherever people look for build results. 4. Keep `open`, `serve` and `watch` for the laptop: `serve` after a local run, `open` on a report someone handed you, `watch` while you are iterating on a failing suite. The tell that a team has skipped step two is a CI job that runs `allure serve` and then finishes: the command blocks until the job is killed, and the report it generated is deleted with the temporary directory. What gets published in that pipeline is nothing at all.