# Allure Docker Service watches a results folder and republishes the report

> Allure Docker Service packages the Allure 2 server in a container that polls a mounted results directory and regenerates the report when new files land. It suits local and CI teams that want live Allure reports without installing the server by hand.

**fescobar/allure-docker-service** — This docker container allows you to see up to date reports simply mounting your "allure-results" directory in the container (for a Single Project) or your "projects" directory (for Multiple Projects). Every time appears new results (generated for your tests), Allure Docker Service will detect those changes and it will generate a new report automatically (optional: send results / generate report through API), what you will see refreshing your browser.

- Repository: https://github.com/fescobar/allure-docker-service
- Stars: 754 · Forks: 208
- Language: Python
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/fescobar-allure-docker-service

## The container renders results it did not produce

The starting point for anyone reading this project is the caveat the README puts first under usage: this container only generates reports based on results, and the Allure results themselves have to be generated by your own testing technology. That division shapes the whole deployment. Allure Docker Service is not a test runner and it is not an adapter for any particular language or framework. It is a report server with a filesystem watcher and an HTTP API bolted onto it.

The problem it solves is narrow and real. Generating good looking Allure reports normally means installing a server, and the README names the two common options as running that server on Jenkins or running commands on your own machine to see reports locally, describing both as tedious. The container removes that setup step. You mount the results folder, the service detects when new files appear, regenerates the report, and you refresh the browser to see the updated run.

Two audiences are named explicitly in the README: developers who run tests locally and want to inspect what broke during regressions, and teams that want to check the test status of every project from one place. The second audience is the reason the project supports multiple projects rather than a single report.

The project is written in Python and released under the Apache 2.0 license, with the container images published on Docker Hub as frankescobar/allure-docker-service.

## Mounting allure-results for one project or a projects directory for many

The container supports two distinct directory layouts, and choosing between them is the first decision you make when you deploy it.

For a single project you mount your allure-results directory. The container reads the result files written there by the test run, and each time new results appear it regenerates the report automatically. This is the mode for the local developer who just ran a suite and wants the breakdown of failures.

For multiple projects you mount a projects directory instead. This mode exists because the README positions the service as a place where a team can check the status of every project, not just one. The upstream documentation separates this into its own section with dedicated instructions for Docker on Unix and Mac, Docker on Windows under Git Bash, and Docker Compose, and it includes a step for creating the first project before results start arriving.

Both modes support the same two ways of feeding the container. You can let the watcher pick up files from disk, or you can push results over the HTTP API. The README notes the API route as optional in the feature description, which is a hint about the intended default: filesystem first, API when the layout requires it.

One deprecation is flagged in the documentation index: port 4040 is marked as deprecated, and separate options exist for switching the port and for switching the version.

## Image tags follow Allure 2 releases across three CPU architectures

Container versions are based on the binary Allure 2 releases, so the version numbers line up with upstream Allure releases rather than with an independent scheme. The published images are tagged frankescobar/allure-docker-service with the version and the architecture appended, for example the 2.44.0 line exists as an amd64 tag, an armv7 tag and an arm64 tag, and the latest tag points at that same 2.44.0 build. The tags are listed on Docker Hub.

Architecture coverage is one of the more useful things the README is explicit about. The service supports amd64, arm32v7 and arm64v8. The table of base images lists eclipse-temurin 11 JRE noble builds on Ubuntu for each of the three architectures, with the base image repositories differing by architecture so that the correct manifest can be pulled on the target machine. The separate manifest list table shows that each release is published as a multi-arch set rather than as three unrelated images, which means a plain pull resolves to the right variant for the host.

The release history is short but steady. Tags v2.44.0 on 2026-07-12, v2.38.1 on 2026-03-23 and v2.35.1 on 2025-10-29 show a project that ships every few months, and the last push to the repository was on 2026-07-12, so the current state of the code matches the current release rather than trailing it.

## A new open source rewrite is announced while the current image keeps shipping

The most important paragraph on the page is the announcement banner, and any evaluation of this project has to start there. The maintainers state that they are developing a new open source version designed to resolve known issues and introduce significant enhancements related to UI, functionality and data processing, that the transition will take time, and that they are prioritizing development to get a build ready for their testers.

This is an unusual position for a released tool. The current image line is actively versioned and published, yet the team describes the code base as being replaced by a new open source version. The README index reinforces the transition by listing separate sections for known issues and for a new user interface, and the announcement asks for testers to try the new build first.

Practically, that means two questions deserve attention before you commit. First, whether the enhancements you are considering the container for, in particular the user interface, exist in the published 2.44.0 image or only in the incoming build. Second, how long the current line will keep receiving images. The release cadence suggests the container is not abandoned, but the wording of the announcement says the significant changes are ahead of it rather than behind it.

## Sending results over HTTP instead of writing them to disk

The optional API path covers three groups of endpoints, described in the documentation index as info endpoints, action endpoints and project endpoints. Info endpoints cover status and version style queries, action endpoints cover operations that change state such as triggering report generation, and project endpoints cover the projects in a multiple project deployment.

Results can be submitted in two content types. One path uses Content-Type application/json, the other uses Content-Type multipart/form-data, which is what you need if the result payloads carry file attachments such as screenshots or logs captured as binary. There is also a force project creation option for the case where you push results for a project name the service does not know yet, and an option that makes the API response less verbose when you script against it.

The API matters most in CI, where the test job and the report viewer often live on different machines and a bind mount is awkward. A container on a shared network can receive results over HTTP instead, and the multi-instance setup and custom URL prefix options in the index suggest the service is meant to sit behind a reverse proxy in that scenario. The API response less verbose switch is a small thing worth noticing: it exists because the default response is chatty enough to slow down scripted polling.

## Login, roles and TLS turn a shared viewer into a protected one

A report server that displays test names, failure stacks and log attachments is not something most teams want open on an internal network by default. The documentation index lists an enable security section with a login flow, an X-CSRF-TOKEN requirement, a refresh access token mechanism, a logout action and roles, which indicates that the container implements its own authentication rather than delegating it entirely to a proxy. There is also a make viewer endpoints public option, so the report reading endpoints can be exposed while the administrative ones stay protected, and a scripts entry for automating access.

TLS is a separate toggle from security, so a deployment behind a reverse proxy can terminate TLS at the proxy while still enabling the in-container authentication, or enable TLS in the container itself.

Two other options in the same index matter for everyday use. Keep history and trends determines whether past runs are retained alongside the current one, and optimize storage addresses the disk growth that follows from keeping them. Export native full report produces the self-contained static Allure report that can be archived or attached to a build artifact, which is often what a team actually needs in addition to the live view.

## Docker Compose, Kubernetes and the developer generation path

The deployment options in the index run from the simplest case upward. For a single project the README lists Docker on Unix and Mac, Docker on Windows under Git Bash, and Docker Compose. For multiple projects it lists the same three variants plus a first project creation step. Deploying under Kubernetes is documented as well, and the topic tags on the repository include kubernetes and docker-compose, so both are first class in the project's own framing.

Configuration is exposed as a set of options rather than a single file: switching the version and the port, updating the seconds the service waits between checks for Allure results, keeping history and trends, overriding the user container, and starting in dev mode. The dev mode entry pairs with the docker-compose-dev.yml file at the top level of the repository, and the docker directory holds the image build context.

The repository is also laid out for people who want to work on the service itself. There is an allure-docker-api directory, an allure-docker-api-usage directory, an allure-docker-scripts directory, and a tests directory. The section titled Docker Generation, marked as usage for developers, indicates the images are produced from the tree rather than only from a release pipeline. For an adoption decision, that layout is the signal that the container is meant to be inspected and extended rather than treated as an opaque binary.

## Emailable reports and custom plugins cover the shared distribution step

Beyond the live web view, the project documents a customizable emailable report, which is the format teams send to people who will not log into a report server. The customization points are deliberately narrow: override the CSS, override the title, override the server link, and develop a new template. Overriding the server link is the detail worth understanding, because it points the emailed copy at wherever your instance lives, so a shared server can be referenced from a mailed report without pointing at localhost.

A separate section covers Allure customized plugins, and another covers Allure options generally. These sit alongside the export of the native full report, and together they define what a team can change without forking the container: the appearance of the distributed report, the plugins that run inside it, and the option set of the service itself.

The remaining choice in the index is the emailable report format itself, which is the natural counterpart to the native full report. One is a self-contained archive you attach to a build, the other is a formatted message you can send. The project supports both from the same running instance, which is a reasonable middle ground between a bare static export and a full CI reporting platform.

## Conclusion

Allure Docker Service is the right pick for developers who want an Allure report that updates itself during a regression run, and the wrong pick for anyone who needs the container to produce Allure results, since the container only renders results generated by your own test framework. Before adopting it, confirm the container can reach the directory your build writes into, decide whether you need the login and role options or the public viewer endpoints, and check the announced rewrite of the project, because the maintainers state that a new open source version addressing UI, functionality and data processing is in development while the last release, v2.44.0, shipped on 2026-07-12.

## FAQ

### Does the Allure Docker Service container generate the Allure results for me?

No. The README states that this container only generates reports based on results, so you must generate the allure-results files yourself using the testing technology you use.

### How do I get a live Allure report with Allure Docker Service?

Mount your allure-results directory for a single project or your projects directory for multiple projects, and the service detects new result files and regenerates the report automatically. You can also send results through the API instead of writing them to disk.

### Which CPU architectures does the Allure Docker Service image support?

The README lists amd64, arm32v7 and arm64v8, with each release published as a manifest list of tags such as 2.44.0-amd64, 2.44.0-armv7 and 2.44.0-arm64 on Docker Hub, built on eclipse-temurin 11 JRE noble base images for Ubuntu.

### Can I protect the Allure report served by the container?

Yes. The documentation lists an enable security option with login, X-CSRF-TOKEN, refresh access token, logout and roles, plus an enable TLS option and a choice to make the viewer endpoints public while keeping the administrative ones restricted.

### What license is Allure Docker Service released under?

The project is licensed under the Apache 2.0 license.

## Sources

- [fescobar/allure-docker-service on GitHub](https://github.com/fescobar/allure-docker-service)
- [Issues](https://github.com/fescobar/allure-docker-service/issues)
- [License: Apache-2.0](https://github.com/fescobar/allure-docker-service/blob/master/LICENSE)
- [README](https://github.com/fescobar/allure-docker-service/blob/master/README.md)
- [Releases](https://github.com/fescobar/allure-docker-service/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fescobar-allure-docker-service