Conifer web archiving: Docker deployment and WARC replay

Conifer's capture and collection workflow

Conifer addresses a specific gap between saving a page and operating a web archive. A simple download may produce one file and no usable way to revisit the captured site. Conifer instead provides an interface for collecting pages, organizing them as personal collections, making captures public or private, replaying archived content, and downloading collections as WARC files. The format matters because the README identifies WARC as the ISO standard file format for web archives. It also separates the hosted service at `https://conifer.rhizome.org/` from the repository version that can run on a local machine.

The intended users range from nontechnical visitors who want to preserve a page temporarily to developers and organizations that want to run their own instance. The hosted service supports account-based collections and anonymous sessions. Account owners can keep collections public or private and download captured content as WARC. Anonymous users can record during a temporary session and download the capture at its end. This makes Conifer relevant to personal research, source preservation, and organizational collection work, although the documentation does not define retention limits for the hosted service.

Conifer is an application around pywb. According to the README, pywb provides the core recording and replay functionality, while Conifer supplies the integrated service and user interface. That division is a useful adoption criterion. A team that needs a complete collection interface should evaluate Conifer; a team that only needs a replay service can consider pywb without adopting Conifer's surrounding services.

Inside Conifer's Docker service architecture

Based on `docker-compose.yml`, Conifer is not a single Python process. The application container runs uwsgi with `/code/apps/apiapp.ini`, while a separate `recorder` service runs `/code/apps/rec.ini` and a `warcserver` service runs `/code/apps/load.ini`. The recorder depends on the WARC service and Redis, while the application also depends on the data service and a service named `shepherd`. This separation suggests distinct runtime roles for API handling, recording, WARC loading, coordination, and storage.

The `frontend` service supplies the browser interface and exposes port 8096 for development hot module replacement. It mounts the repository's `frontend/` directory and creates `/code/node_modules` inside the container. The `dat` service exposes port 3282 over TCP and UDP, mounts `./data` at `/data`, and stores data under `/data/storage`. Both application and recorder containers mount `./data`, making shared persistent storage part of the local arrangement rather than an anonymous container filesystem.

Redis appears as a required dependency for recording and the main application, while the Compose file also references search-related files at repository level, including `search-compose.yml` and `search-driver/`. It is enough to say that a deployment is operational infrastructure, not merely a Python package installation. Operators must account for container startup order, shared data, browser images, and multiple listening ports.

Running Conifer locally for the first collection

The README requires Docker and Docker Compose. It gives a four-command startup path, beginning with a clone and initialization script. The initialization step copies `webrecorder/webrecorder/config/wr_sample.env` to `wr.env` and creates session encryption keys, so it should not be replaced with an unexplained manual configuration.

The following commands are reproduced from the local deployment instructions. They clone the default repository, initialize configuration, build the images, and start the services:

git clone https://github.com/rhizome-conifer/conifer
cd conifer; bash init-default.sh
docker-compose build
docker-compose up -d

After Compose finishes starting the stack, open `http://localhost:8089/`. The README notes that a maintenance message may appear briefly while Conifer starts; it instructs the reader to refresh after a few seconds and look for the Conifer home page. This first use verifies container startup and the UI, not the complete archive workflow.

Conifer also offers optional Remote Browsers, which are containerized Chrome or Firefox images published under the `oldweb-today/` organization. The README says they can improve capture and archive access in many cases and are launched as needed. The supported installation route is the repository's `install-browsers.sh` script. The documentation does not supply the script's contents or individual image commands, so this review does not invent them. Remote browser installation should therefore be treated as a separate step after the base stack works.

Conifer host separation and anonymous capture settings

Conifer's default deployment separates the application interface from archived content by using different ports, and the README describes that arrangement as a security measure. Its purpose is to prevent an archived site from gaining unwanted access to or interaction with the Conifer interface. For a deployment on separate domains, the documented variables are `APP_HOST`, `CONTENT_HOST`, and `SCHEME`. The README recommends two HTTPS-enabled subdomains and explicitly says to set `SCHEME=https` when deploying over HTTPS.

Anonymous recording is disabled by default. The documented way to enable it is to add the following setting to `wr.env`, then restart Conifer:

ANON_DISABLED=false

This is a configuration value rather than a shell command, but the code block preserves its exact spelling. Enabling anonymous capture changes the service boundary and should be considered alongside the host configuration. The README does not document rate limits, abuse controls, storage quotas, or retention policy for anonymous sessions, so those details require verification in the user guide or an operator's own configuration.

Conifer reads deployment-specific values from `wr.env` and less frequently changed system settings from `wr.yaml`. The documentation excerpt does not show the full contents of either file. That omission limits how precisely an evaluator can assess authentication, upload limits, external service dependencies, or production hardening from the README alone.

Conifer maintenance, licensing, and upgrade boundaries

The repository is not archived, and its last push was on 2026-07-22. That is recent enough not to trigger the repository's stale-push condition, but the project has no GitHub releases. Consequently, the absence of versioned release artifacts means operators cannot infer upgrade cadence from a published GitHub release list. The README itself refers to the 5.x version and says it was released in June 2020, which makes the documentation's age especially relevant when checking commands, Compose syntax, and dependency compatibility.

Users of a 3.x installation are directed to `migrating-4.0.md` for migration instructions. The README does not explain a complete upgrade path from every possible deployment, database layout, WARC collection, or environment file to the version represented here. It also points users to the `legacy` branch for the previous interface. This separation adds maintenance work: an operator must identify which branch and migration assumptions match the installation.

The project uses the Apache-2.0 license. That identifies the stated licensing model, but it does not answer operational questions about bundled browser images, third-party services, data ownership, or obligations applying to a particular hosted archive. No legal interpretation is needed to note that local WARC files and captured content remain separate from the source-code license question.

Conifer versus standalone pywb

Conifer and pywb overlap at the recording and replay layer, but they target different scopes. The README calls Conifer an integrated platform with capture, archive access, collections, public or private sharing, downloads, and a user-friendly interface. It says pywb is the core replay system, includes very basic recording capabilities, and can operate as a standalone Python library with a Docker image.

The practical difference is scope. pywb is the relevant choice when the goal is to deploy a web archive access service without needing Conifer's collection-oriented UI and surrounding application stack. Conifer is the relevant choice when the browser workflow, collection ownership, sharing controls, and downloadable WARC collections are part of the requirement. Choosing Conifer adds at least the services visible in `docker-compose.yml`, including frontend, app, recorder, WARC handling, Redis, and data storage. pywb may reduce that deployment surface, although the README does not provide a resource comparison or a claim that it will always use fewer resources.

Conifer is therefore the wrong tool for a narrowly defined replay requirement. It is also a heavier starting point than a small Python library. The tradeoff is deliberate: the collection interface and managed hosted experience come with more moving parts.

Editorial conclusion

Conifer is appropriate for archivists, researchers, and organizations that need an interface for creating collections and sharing archived pages, especially when browser capture and replay must work together. It is a poor fit for a lightweight command-line archive or a server that has only basic replay needs; pywb offers a narrower alternative. Before adoption, verify that Docker Compose resources cover the separate app, recorder, WARC, Redis, data-sharing, frontend, and search-related services, then inspect the documented split between `APP_HOST` and `CONTENT_HOST` for the intended deployment. The repository's last push was on 2026-07-22, but it has no GitHub releases, so operators must plan upgrades from repository contents rather than assume a published release history.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. Rhizome-Conifer/conifer on GitHub