Archivematica: a preservation pipeline with evidence attached

What Archivematica is: a standards-based preservation pipeline, not a storage system

Archivematica is a web- and standards-based, open-source application which allows your institution to preserve long-term access to trustworthy, authentic and reliable digital content. The stated target users are archivists, librarians, and anyone working to preserve digital objects.

That last clause decides who this is for. This is not a backup tool, not a document management system, and not a repository. The repository description calls it a digital preservation system designed to maintain standards-based, long-term access to collections of digital objects, and the vocabulary in the description is all about provenance and fixity rather than about storage.

The distinction is worth holding onto when you evaluate it, because the two overlap in the vendor's language. A preservation system is one that takes a set of digital objects and produces, alongside the objects, a package of evidence about them: a fixity manifest so you can prove later that nothing changed, metadata records extracted from the files themselves, and a structured submission information package that describes the transfer as well as the content.

The system is maintained by Artefactual, and the licensing is AGPL-3.0. The README states the grant plainly: you are free to copy, modify, and distribute Archivematica with attribution under the terms of the AGPLv3 license, and the LICENSE file holds the details.

The project is not archived, the last push to the tree was on 2026-10-20, and the release history is v1.18.0 from 2025-09-26, v1.17.1 from 2025-05-20 and v1.17.0 from 2024-12-06. The default branch name is `qa/1.x`, which tells you something about how the team branches, and the repository carries a RELEASENOTES.md with release notes going back to version 0.6.

Three repositories that have to work together

The single most useful thing in the README is the section on related projects, because it stops you from treating this as one application.

Archivematica consists of several projects working together. This repository, the main one, contains the user-facing dashboard, the task manager, an MCPServer and client scripts for the MCPClient. The Storage Service is responsible for moving files to Archivematica for processing, and from Archivematica into long-term storage. The Format Policy Registry is a submodule shared between Archivematica and the Format Policy Registry server that displays and updates FPR rules and commands.

The Storage Service is the part that trips people up. Archivematica on its own cannot pull files from an object store, and it cannot write to one. The Storage Service is what connects the pipeline to whatever holds the bytes, whether that is a disk, a tape, or a cloud repository. A deployment therefore has at least two services to install, monitor and upgrade, and the failure modes are separate ones.

The Format Policy Registry is the other half, and it is a subtler idea. Preserving a digital object means knowing how to validate it, how to extract metadata from it, and how to decide whether it should be kept at all. Those rules are data, and the FPR is where they live, versioned and shared between the server that displays them and the pipeline that applies them. The repository carries the FPR as a submodule, which means the rules travel with the code rather than being fetched at runtime.

The README also points to the Contributors Portal for the list of other projects in the ecosystem, and to the Architectural Decisions Record at adr.archivematica.org for the reasoning behind how the pieces fit together. For anyone about to modify the pipeline, that ADR is likely the more valuable of the two.

The dependency list tells you what a preservation pipeline actually needs

The pyproject.toml in the repository root is the closest thing to an architecture summary, because the dependencies of a preservation system are its requirements in explicit form.

The base is Django, pinned to `>=5.2,<6`, and the package requires Python 3.11 or newer. The build backend is setuptools with wheel.

[project]
name="archivematica"
requires-python = ">=3.11"
dependencies = [
  "Django>=5.2,<6",
  "elasticsearch>=8.0.0,<9.0.0",
  "gunicorn",
  "gevent",

Beyond the web framework, the list splits into groups that map onto the job.

Preservation and packaging accounts for bagit, a git pinned dependency on the Library of Congress bagit-python project, and for metsrw, which reads and writes METS, the XML metadata standard that describes a transfer. Those two are the archival formats proper. amclient and ammcpc are the clients for those formats, and agentarchives is the library that does the actual archiving.

Virus checking and validation accounts for clamav-client and opf-fido, a git pinned dependency on the artefactual-labs fido project. FIDO is the identifier and format tool, and the README's reference to the Format Policy Registry explains where its rules are administered.

Search and delivery accounts for elasticsearch, pinned to the 8.x series below version 9, django-tastypie for the API layer, and django-prometheus with prometheus_client for metrics. The brotli and orjson dependencies are compression and fast JSON, and gevent with gunicorn is the serving stack.

Authentication is the part that surprises people, because a preservation system in an institutional setting has to support whatever the campus already runs. The dependencies include django-shibboleth-remoteuser from a git pin, django-auth-ldap with python-ldap for LDAP, django-cas-ng for CAS, and mozilla-django-oidc for OpenID Connect. The source even comments each group, marking which are required by LDAP authentication, by CAS authentication and by OpenID Connect authentication.

Two of the dependencies are git pins rather than released versions, django-shibboleth-remoteuser and bagit, both pinned to a specific commit. That is a signal about the project's dependency hygiene, and it is worth knowing before you plan an upgrade.

Working on the code: the uv workflow and the check target

The repository uses uv for dependency management, and the Makefile exposes the workflow as named targets with a description comment on each, which makes the intended developer loop readable at a glance.

The lock target updates the lockfile without upgrading the locked dependencies, and lock-check verifies that the lockfile is up to date.

.PHONY: lock
lock:  # Update the lockfile without upgrading locked dependencies
	$(UV) lock

.PHONY: lock-check
lock-check:  # Verify that the lockfile is up to date
	$(UV) lock --check

The sync targets install from the lockfile, one for the project and development dependencies and one for the project and runtime dependencies only. The check target is the gate: it runs lock-check and then lint.

.PHONY: sync
sync:  # Sync the project and development dependencies
	$(UV) sync --locked

.PHONY: check
check: lock-check lint  # Verify the lockfile and run all checks

The lint target delegates to the hack directory, running the pre-commit checks through Compose. The repository has a `.pre-commit-config.yaml` at the root, a `hack/` directory that holds the developer tooling, a `Makefile` of its own inside it, and a `uv.lock` file. The Makefile also carries a `UV ?= uv` variable at the top, so the tool can be pointed at a different binary without editing the file.

The separation between `sync` and `sync-runtime` is a production concern rather than a convenience. A deployment image wants the runtime dependencies and nothing else, and uv's `--no-dev` flag is what makes that possible without a hand-maintained requirements file.

Two other things in the tree tell you how the project is run rather than only built. The `typings/` directory holds type stubs, which matters for a codebase of this size that a lot of organisations will type check against. The `.python-version` file pins the interpreter, which pairs with the `requires-python` floor in the metadata.

The CI badge in the README points at a GitHub Actions workflow named test, and there is a codecov badge alongside it, so coverage is measured on every run.

What the documentation and support structure looks like

Archivematica separates its documentation into audiences, and the README indexes each one rather than trying to be a manual itself.

For people using the system there is the website for the user and administrator documentation, a presentations repository and a YouTube channel for previous trainings and talks, a case studies repository for resources about working on and with Archivematica, and a User Group forum and mailing list for user questions, both technical and end-user. Paid support is offered by Artefactual for support, hosting, training, consulting and software development contracts.

For developers there is the API documentation, the developer guide for requirements analysis and community resources, the Issues repository used for tracking issues and feature and enhancement ideas, and a roadmap with current release information and potential future works.

Two details are worth flagging for anyone planning to contribute. The README asks you to read about the guidelines for making pull requests, including the contribution standards, and to make any documentation updates reflecting the changes your contribution introduces, with the documentation updates living in a separate wiki repository. So a change to the pipeline that alters behaviour is expected to come with a documentation change in another repository.

The second is the Architectural Decisions Record. The README suggests you might have questions about the history of development decisions and points you at adr.archivematica.org. For a system that has accumulated a documented history of design decisions, that is the first place to look before proposing a change, and it is more useful than the issue tracker for understanding why something is the way it is.

For reporting problems, issues related to Archivematica, the Storage Service, or any related repository are filed in the Issues repository, and the README points at a guide about issue reporting. Security concerns go through the SECURITY file, which describes how to safely report vulnerabilities, and there is a CODE_OF_CONDUCT.md and a CONTRIBUTING.md alongside a TRADEMARK file.

Where Archivematica does not fit, and what to weigh instead

Three limitations are visible in the repository, and the first is structural.

Archivematica is a system of several parts, and the pieces have different release cadences. The Storage Service is a separate repository with its own versions, the Format Policy Registry is a submodule shared with a separate server, and this repository carries its own. A deployment therefore has an upgrade matrix rather than a single version, and an institution that cannot tolerate that coordination is looking at the wrong product.

The second is that the AGPL-3.0 licence is a real constraint for a specific kind of organisation. The README's grant covers copying, modifying and distributing with attribution, which is generous for internal use and for institutions that publish their modifications. For a vendor who wants to build a hosted service on top of the pipeline without releasing the corresponding source, the copyleft terms are the thing to examine, and that is a question for whoever handles licensing rather than a technical one.

The third is scope. This is a preservation system for digital objects, with provenance and fixity at its centre. It is not a collaboration suite, not a DAM for active editing, and it does not do access control for end users reading the content. If the requirement is to let people browse, annotate and redistribute a collection, that is a different problem with different tools.

The alternative approach is worth describing precisely, because the difference is in what is preserved. A preservation system packages objects with evidence: fixity manifests so later alteration is detectable, metadata records extracted from the files, a structured submission information package describing the transfer. A general file repository or an object store with versioning gives you durable storage and, in some configurations, a version history. The difference in approach is that one produces an evidentiary record that a third party can verify years later, and the other produces a copy.

A second alternative is to do the archiving with the format tools directly. BagIt and METS are published standards, and a script that packages a directory, writes a fixity manifest and a metadata file can do the core of what Archivematica does for a well behaved collection. The trade is where the rules live. A script encodes one institution's decisions. Archivematica encodes the decisions in the Format Policy Registry, with the rules shared and updatable, and gives you the workflow, the dashboard and the audit trail around them.

Editorial conclusion

Adopt Archivematica if your institution needs a verifiable preservation record, with fixity, extracted metadata and a submission information package, and you can operate a multi-service system and live with the AGPL-3.0 terms. Do not adopt it as a general file repository, and do not adopt it if a single release and a single upgrade path is a hard requirement, because the Storage Service and the Format Policy Registry version separately. Before you install, read the Architectural Decisions Record at adr.archivematica.org to understand how the pieces divide the work, check the AGPL-3.0 licence in the repository root against your organisation's policies, and plan the upgrade of the Storage Service alongside the dashboard rather than treating them as one artefact.

Frequently asked questions

Official sources

1. artefactual/archivematica on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases