gramps-web is a frontend only: the Dockerfile copies dist into the API image

A frontend repository that ships inside the API image

The clearest signal of this project's scope is its Dockerfile:

FROM dmstraub/gramps-webapi:latest
COPY dist /app/static
LABEL org.opencontainers.image.source="https://github.com/gramps-project/gramps-web"

This image inherits the backend from the API image. It starts from the prebuilt Gramps Web API image and copies the compiled frontend into the static directory. So building and deploying this repository is really two operations: produce a `dist` directory with Rollup, then graft it onto a backend someone else maintains.

The README says the same thing in prose, with an instruction most contributors miss on first contact: issues about server-side code belong in the Gramps Web API repository, not here. A user filing a bug about data import will be sent elsewhere, which is correct but not obvious.

The repository layout backs this up. There are three Dockerfiles, a plain one plus Dockerfile.devel and Dockerfile.nginx, along with a default.conf.template, which is nginx configuration, and a.devcontainer folder. A devcontainer plus a separate development Dockerfile is the shape of a frontend project that has a backend developer workflow to support without owning the backend.

One file in the root tells you about the visualisation layer: graphvizlib.wasm, a WebAssembly build of Graphviz, sitting next to index.html and rollup.config.js.

Web components, Rollup and a dev server on port 8001

The primary language is listed as JavaScript and the build tooling is explicit in package.json.

The bundle step is Rollup with a typescript plugin, a node-resolve plugin, a terser plugin, a replace plugin, an html plugin and a polyfills loader, driven by rollup.config.js and preceded by a rimraf of the previous output:

npm run build

Development runs on @web/dev-server rather than a bundler CLI, bound to all interfaces on port 8001:

npm start

and there is a `start:build` script that builds first and then serves the `dist` directory with no browser compatibility shims, which is the closer approximation of production.

The component model is web components. The topics include lit and web-components, the stylesheets at the root are plain global.css, tippy.css and maplibre-gl.css, and the dev dependencies include eslint-plugin-lit, eslint-plugin-lit-a11y and eslint-plugin-wc alongside a TypeScript ESLint parser and tsconfig.json. The lit-a11y plugin in particular suggests accessibility linting is enforced rather than hoped for, which matters for a genealogy application used by people with widely varying technical confidence.

Map rendering pulls in MapLibre, and the interface has a lang/ directory plus manifest.json, which is where internationalisation and progressive web app metadata live.

Testing is Vitest with coverage, in both a `test` script using `--coverage` and a `test:watch` variant. Type checking is separate from linting, as `tsc --noEmit` under a `typecheck` script, so a type error fails before lint or test complains.

What the application actually does

Gramps Web is positioned as a companion to the Gramps desktop genealogy application rather than a replacement, and the interoperability claim runs both ways. The README lists bi-directional sync between the web app and Gramps Desktop as a headline feature, and data can be exported at any time, with Gramps XML and GEDCOM both named in the repository topics.

The tree views are the core visualisation. Ancestor, descendant, fan and hourglass charts are each listed separately, which tells you the chart types are first-class routes rather than a toggle. Places appear on interactive maps, including custom overlays for historical maps, which is the feature most genealogy-specific in the list and the one hardest to build without domain knowledge.

Search covers all record types with wildcards and logical operators. A blog stores research notes with images inside the Gramps database rather than beside it, which matters because it keeps one export path.

Two feature areas are worth reading twice. The DNA and chromosome tools view DNA matches and analyse chromosome data, so the application expects to hold genetic data alongside the tree. And an AI chat assistant lets you query your family tree in your own language. That is the feature to think hardest about before deploying, because it sends family data somewhere, and the README does not describe where that inference happens or whether it can be disabled.

The demo deployment is worth logging into before you install

There is a live demo, and it comes with credentials published in the README, which is unusual and useful:

Four named roles, each with the password identical to the username. That set is a small design lesson in itself: it shows the permission model has at least four tiers, from an owner down to a read-mostly member, and you can see what each role can do in about two minutes without installing anything.

The README also states plainly that some features are not available in the demo, naming AI chat as one. So the demo is a fair test of the tree, the charts, the map and the role model, and an incomplete test of anything involving external services.

For self-hosting, the documentation site splits the material into separate sections for features, install and setup, administration, a user guide, developer documentation, contributing and help. Setup and administration are separate documents, which is a good sign that operating an instance is treated as a real task rather than assumed.

Licence, cadence and where contributions go

The licence is AGPL-3.0, which is a deliberate choice for software whose most attractive use is hosting other people's family data. The AGPL's network clause means that if you modify this and serve it over a network, you must offer those modifications to your users. For a deployment where you operate the instance for a family group, that obligation is narrower than it sounds, and for anyone building a hosted genealogy service on top it is a real constraint worth reading rather than assuming.

Release cadence is steady and follows a date-based version scheme. v26.9.1 shipped on 2026-09-20, v26.10.0 on 2026-10-06 and v26.10.1 on 2026-10-11, so roughly weekly or better. The last push to the repository was on 2026-10-16, and the repository is not archived, so the frontend is actively being changed alongside those releases.

Planning is done on a development board rather than a fixed-date roadmap, and the README says explicitly that the board reflects current priorities of existing developers and is not a restriction on what can be contributed. That phrasing is unusual and worth noting: it invites work outside the listed priorities, which is what an open source project with no corporate sponsor needs.

The repository also carries AGENTS.md and CLAUDE.md, files aimed at coding assistants working in the tree, alongside a code of conduct and a contribution guide.

Editorial conclusion

Gramps Web fits a genealogist or a family group who wants to share and co-edit a tree from any browser and move that tree between the web app and Gramps Desktop without conversion loss. It does not fit a contributor looking for the server, because this repository holds only the frontend and issues belong in the API repository. Verify first by logging into the demo at demo.grampsweb.org with one of the documented accounts, and note that some features such as the AI chat assistant are absent there, so the demo is not a complete picture of a real deployment.

Frequently asked questions

Official sources

1. gramps-project/gramps-web on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases