# La Suite Docs: a self-hosted collaborative editor built on Django and React

> La Suite Docs is an MIT-licensed, web-native text editor with real-time collaboration, sub-pages and optional AI helpers. It self-hosts with Docker Compose, but PDF export pulls in GPL packages that break MIT-only builds unless you compile with PUBLISH_AS_MIT=true.

**suitenumerique/docs** — Docs is an open-source text editor: web-native, made for real-time collaboration, cleanly structured documents and sub-documents with full ownership of your data. Built to scale with Django and React.

- Repository: https://github.com/suitenumerique/docs
- Website: https://docs.la-suite.eu/
- Stars: 16,879 · Forks: 649
- Language: Python
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/suitenumerique-docs

## What La Suite Docs solves, and for whom

The README positions Docs as an open-source alternative to Notion or Google Docs, aimed at public organizations, companies and open communities. The organising idea is ownership: you run the backend, you keep the documents, and you decide who sees them. The README states it plainly under What is Docs, listing data ownership and self-hosting alongside real-time collaboration and knowledge organization.

The feature set splits into four areas. Writing covers rich-text and Markdown editing, slash commands, a block system and offline editing. Collaboration covers live cursors, presence, comments, sharing and granular access control. Knowledge management is subpages, hierarchy and searchable content. Presentations are generated from a `---` delimiter, with a full-screen option, PDF exports and keyboard navigation. There is also an optional AI layer that the README describes as model agnostic and gateway agnostic, needing only an API key and a URL.

That combination is the pitch: a document tool where the hierarchy is a first-class structure rather than folders bolted onto a list of files. If your team already lives in a wiki-style tool and wants to stop paying per seat, the target is clear. If you only need a scratchpad for one person, the deployment surface is disproportionate.

## How Docs is put together: Django, React and a resource server API

The repository layout tells most of the story. There is a `src/` tree, a `Dockerfile` with distinct build stages, a `compose.yml`, and `env.d/` directories holding environment files per service. The Dockerfile starts from `python:3.14.6-alpine`, installs `uv` from `ghcr.io/astral-sh/uv:0.11.10`, and syncs the backend from `src/backend/uv.lock` and `src/backend/pyproject.toml` with `uv sync --locked --no-dev`. A separate `mail-builder` stage runs `node:24` and builds `src/mail` with Yarn. A `link-collector` stage runs `python manage.py collectstatic` under `DJANGO_CONFIGURATION=Build` and then collapses duplicate static files with `rdfind`.

So the backend is Django, and the README names Django Rest Framework explicitly in the credits. The frontend is React, and the README credits Next.js. The compose file confirms the supporting cast: `postgres:16`, `redis:5`, `sj26/mailcatcher`, and MinIO with a `createbuckets` job that creates `impress-media-storage` and enables versioning on it.

Two APIs matter for integration. The README points to a resource server API and a server-to-server API. The concrete example given is Meet: with `DJANGO_SERVER_TO_SERVER_API_TOKENS` configured, a Meet instance can push a meeting transcript into Docs and grant access to the user who requested it. That is a narrow but real integration path, and it is the part of the project most likely to matter to a platform team stitching internal tools together.

The development compose file maps Postgres to host port 15432, MinIO to 9000 and 9001, and mailcatcher to 1081. Those are development conveniences, not production defaults.

## Installing Docs locally with make bootstrap and make run

The README gives a local development path rather than a production install recipe, and it warns that the setup is intended for development and testing only. Prerequisites are Docker, Docker Compose and GNU Make. The README suggests verifying the first two:

```bash
docker -v
docker compose version
```

If those print versions, the next step bootstraps everything. According to the README, this builds the `app-dev` and `frontend-dev` containers, installs dependencies, runs database migrations and compiles translations, and it is worth re-running after pulling new code:

```bash
make bootstrap FLUSH_ARGS='--no-input'
```

Then start the stack and open the app:

```bash
make run
```

The README says to open https://localhost:3000, and gives development-only credentials of `impress` for both username and password. That is a local login, not something to carry into any shared environment.

For frontend work the README recommends running outside Docker, which avoids rebuilding the frontend container on every change:

```bash
make frontend-development-install
make run-frontend-development
```

If you only need the API, `make run-backend` starts everything except the frontend container. `make demo` creates a basic demo site, `make superuser` creates a Django admin user, and the admin UI is at http://localhost:8071/admin. To see every target, run `make help`.

## The MIT licence does not cover every feature you can switch on

This is the part of the README most likely to surprise an adopter, and it is stated in a warning block rather than buried. Some advanced features, with `Export as PDF` named as the example, rely on XL packages from Blocknote. The README says those packages are licensed under GPL and are not MIT-compatible.

The escape hatch is a build flag. Building with `PUBLISH_AS_MIT=true` produces an image of Docs without the non-MIT features. So there are effectively two artefacts: the full build, which is convenient but carries GPL components, and the MIT-only build, which is cleanly licensed but loses the features those packages provide. The README points to the environment variables documentation for more detail.

For a company with a strict licence review process, this is a decision you make before deployment, not after. The project's own framing is that the MIT choice is an invitation for private sector actors to use, sell and contribute. That is a genuine commitment, but it does not extend to the GPL packages, and no amount of reading the top-level LICENSE file will tell you that. The warning block is the source of truth here. Anyone evaluating Docs for a commercial product should read `documentation/env.md` alongside this warning rather than assuming a single MIT label covers the whole binary.

## Where Docs is the wrong tool

The Makefile opens with a block of warning symbols and a plain statement: it is only meant to be used for development purposes, and the reader is told not to use it for CI, production or anything else. That is unusually blunt, and it should shape how you read every `make` command above. The compose file it drives runs MinIO for storage, mailcatcher for mail, and binds Postgres to 15432. None of that is a production topology, and the README repeats the point: the local setup is for development and testing only.

The README does list Kubernetes, Docker Compose and community methods such as Nix and YunoHost for self-hosting, and points to an installation guide for those. So production deployment exists as a documented path, but it is a different path from the developer workflow, and the repository does not present the Makefile as a shortcut to it.

There is a second boundary. Docs is a collaborative editor with a hierarchical page model. If your problem is structured data, a database-backed app or a spreadsheet with formulas, the block and subpage model is the wrong shape. The README's presentation feature, built from a `---` delimiter, is a nice touch for slide-like documents, but it is a document convention rather than a presentation tool. And the AI features, while described as optional and gateway agnostic, still need an API key and a URL, which means an external dependency unless you host a model yourself.

## How Docs differs from Etherpad and ONLYOFFICE Docs

The obvious comparison is Etherpad, and the difference is structural rather than cosmetic. Etherpad is a pad: you open a URL, everyone types, and the artefact is a flat document. Docs adds a hierarchy of subpages, comments, granular access control and search on top of the editing surface. The README's knowledge management section is the part Etherpad does not attempt. If your use case is a single shared scratch buffer for a meeting, Etherpad's model is simpler and its operational footprint is smaller.

The other comparison is ONLYOFFICE Docs, and there the difference is in what the editor is for. ONLYOFFICE is built around office document formats, with the word processor, spreadsheet and presentation editors as the centre of gravity. La Suite Docs is built around blocks and pages, with import from `.docx` and `.md` and export to `.docx`, `.odt` and `.pdf` as a bridge to those formats rather than the native representation. The README's export list is telling: no `.xlsx`, because a spreadsheet is not the point.

Against Google Docs the difference is ownership and deployment, which is the whole reason the project exists. The trade is that you take on Postgres, Redis, an S3-compatible store and the Django application, plus whatever your organisation requires around backups and upgrades. The README does not claim this is free of operational cost, and it should not be read that way.

## Versioning, upgrade cost and the maintenance picture

The repository has an `UPGRADE.md` at the top level, which is where upgrade instructions live, and a `CHANGELOG.md` alongside it. Recent releases are v5.4.0 and v5.4.1 in July 2026, and v5.5.0 on 2026-08-24. The last push to the default branch was on 2026-08-24, three weeks before this article, and the repository is not archived. That is a recent release cadence, but the presence of an `UPGRADE.md` is the signal that matters for operators: it implies that moving between versions is not always a matter of pulling a new image.

There are other operational files worth knowing about before you commit. `renovate.json` means dependency updates arrive as automated pull requests. `.sops.yaml` indicates encrypted secrets in the repository. `secu-audit.md` sits at the top level. `compose-e2e.yml` exists for end-to-end tests, and the Makefile defines a `COMPOSE_E2E` variable that layers it over the base compose file. `publiccode.yml` is present, which fits the public-sector framing.

On licence implications, and without giving legal advice: the MIT licence covers the project, but the README's warning about GPL Blocknote XL packages means the licence of the deployed artefact depends on how you build it. If you need a purely MIT image, `PUBLISH_AS_MIT=true` is the build argument that gets you there, and the cost is the features those packages provide. Confirm with your own counsel which build your organisation can ship.

## Conclusion

Adopt La Suite Docs if you need a self-hosted collaborative editor with sub-pages, comments and an API you can push content into, and if your team can run Django, Postgres, Redis and an S3-compatible store. Do not adopt it if you want a pure-MIT binary with PDF export included, or if you expect the Makefile targets to be production deployment tooling, because the Makefile states they are development-only. Before committing, verify the PUBLISH_AS_MIT build path and the UPGRADE.md instructions against your target version, and check whether DJANGO_SERVER_TO_SERVER_API_TOKENS is something you actually need.

## FAQ

### Is there a self-hosted version of La Suite Docs?

Yes. The README describes Docs as open source and focused on data ownership and self-hosting, and states that it supports Kubernetes, Docker Compose, and community-provided methods such as Nix and YunoHost, with an installation guide linked from the repository.

### Is La Suite Docs totally free?

The project is released under the MIT License, but the README warns that some advanced features, such as Export as PDF, rely on Blocknote XL packages licensed under GPL that are not MIT-compatible. Building with PUBLISH_AS_MIT=true produces an image without those non-MIT features.

### What are three disadvantages of La Suite Docs?

The Makefile states it is for development only and should not be used for production. The local setup uses MinIO and mailcatcher and is described as development and testing only. And the GPL-licensed Blocknote XL packages mean a full-feature build is not MIT-only.

## Sources

- [Official documentation](https://docs.la-suite.eu/)
- [Official README](https://github.com/suitenumerique/docs#readme)
- [Project repository](https://github.com/suitenumerique/docs)
- [Release notes](https://github.com/suitenumerique/docs/releases)

---

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