La Suite Docs: A Self-Hosted Collaborative Editor with a Licensing Catch
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.
At a glance
- What is it?
- La Suite Docs is an open-source, web-native collaborative editor built with Django and React. It targets teams wanting Notion-like features with full data ownership, but its optional AI and PDF features come with a GPL licensing wrinkle.
- Who is it for?
- Adopt La Suite Docs if you need a self-hosted, real-time collaborative editor with structured documents and sub-documents, and you are comfortable with Django and Docker. Avoid it if you require full MIT purity out of the box; the default build includes GPL-licensed Blocknote XL packages for features like PDF export, and you must build with PUBLISH_AS_MIT=true to strip them.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Notion-Like Collaboration Without Cloud Lock-In
Teams that want real-time collaborative editing usually end up on Google Docs or Notion. Those services are convenient, but they hold your documents on someone else's infrastructure. La Suite Docs addresses that by offering a web-native editor you can self-host. It is built for public organizations, companies, and open communities that need data ownership. The README positions it as an open-source alternative to Notion and Google Docs, with a focus on real-time collaboration, structured documents, and knowledge organization. If your team already runs Django or React, this project fits your stack. If you are a small group that just wants a hosted editor, the self-hosting requirement is a barrier.
How It Works: Django Backend, React Frontend, Block-Based Editing
The architecture is a classic split: Django Rest Framework on the backend, Next.js on the frontend. The editor itself is block-based, similar to Notion, with slash commands and a block system. Collaboration is handled through live cursors and presence, plus comments and sharing. The document model supports subpages and hierarchy, so you can organize knowledge into nested structures. The README mentions a resource server API and a server-to-server API, which enable integrations like pushing meeting transcripts from the Meet project. That API design is a concrete mechanism for external systems to write into Docs. The frontend uses Blocknote, which is a React-based block editor, and the AI features are built on Blocknote's AI integration.
Getting It Running: Docker Compose and Make Commands
The quickest path is Docker Compose with GNU Make. You run `make bootstrap FLUSH_ARGS='--no-input'` to build the app-dev and frontend-dev containers, install dependencies, run migrations, and compile translations. Then `make run` starts everything, and you open https://localhost:3000. Default development credentials are username `impress` and password `impress`. For frontend work, you can run outside Docker with `make frontend-development-install` and `make run-frontend-development`. Backend tests can run without Docker, but you must override some URL and port values from `env.d/development/common` with those in `env.d/development/common.test`. The README warns this setup is for development only, using Minio as an S3-compatible storage backend. For production, the documentation points to Kubernetes and Docker Compose, with community methods like Nix and YunoHost.
The GPL Catch: PDF Export and Other Features Are Not MIT
The README carries a clear warning: some advanced features, including `Export as PDF`, rely on XL packages from Blocknote that are licensed under GPL and are not MIT-compatible. This is a genuine licensing trap for teams that assume an MIT-licensed project means every part is MIT. The default build includes those packages. If you need to avoid GPL, you can build with `PUBLISH_AS_MIT=true`, which produces an image without non-MIT features. That flag is a real config key, but it means you lose PDF export and possibly other advanced capabilities. Before adopting, you must decide whether the GPL components are acceptable for your distribution model. If you are shipping a proprietary product, this is a hard constraint. If you are an internal team, it may be irrelevant.
AI Features: Optional, Model-Agnostic, but with Two Different Versions
Docs includes optional AI writing helpers like rewrite, summarize, translate, and fix typos. The configuration is simple: an API key and a URL, and it is model-agnostic and gateway-agnostic. There are two versions. V1 is a select-and-replace workflow where your selection is the context and instruction, and the AI output replaces it. V2, which is beta, uses Blocknote's AI integration and adds an AI toolbar and an AI cursor that interacts with the document like another collaborator. V2 also uses document context beyond the selection. The trade-off is that V2 is more powerful but relies on Blocknote's AI integration, which may carry the same GPL concerns as the XL packages. The documentation does not specify which AI providers are supported, so you need to verify compatibility with your chosen provider.
Interoperability and a Concrete Example: Meet Transcriptions
The resource server API and server-to-server API are the main integration points. The README gives a concrete example: if you run a Meet instance, you can configure `DJANGO_SERVER_TO_SERVER_API_TOKENS` to push meeting transcripts into Docs and give access to the requesting user. That is a real data flow: external service to Docs via an authenticated API. This is a differentiator compared to editors that only offer a web UI. For teams building automation, this API is a practical hook. However, the documentation for these APIs is referenced but not included in the README, so you will need to read the `documentation/resource_server.md` and the environment variable docs to understand the exact endpoints and authentication. The README does not list the endpoints, so that is a gap you must fill.
Maintenance and Upgrade Cost: Active Releases and Make-Based Workflow
The project shows recent activity with releases v5.5.0 in August 2026, v5.4.1 in July 2026, and v5.4.0 in July 2026. The README recommends running `make bootstrap` after pulling new code, which suggests that upgrades involve rebuilding containers and running migrations. That is a standard Django workflow, but it is not zero-touch. The Make targets for tests and linting (`make frontend-test`, `make frontend-lint`) indicate a CI-friendly setup. The license is MIT for the project itself, but the GPL caveat means you must track which optional packages you enable. The maintainers invite contributions and have a public roadmap, which is a positive sign for long-term support. Still, self-hosting means you own the upgrade burden, including any breaking changes in Django or React dependencies.
Alternatives: Notion and Google Docs vs. Self-Hosted Options
The obvious alternatives are Notion and Google Docs, which are hosted and require no setup. They are easier to start with, but you give up data ownership. On the self-hosted side, the README does not name competitors, but common options include Etherpad, which is simpler and focused on plain text collaboration, and Nextcloud with its built-in editor, which offers file sync and collaboration but is not a block-based knowledge management tool. The key difference is that Docs offers a Notion-like block structure with sub-documents, which Etherpad does not. If you need hierarchical knowledge organization, Docs is closer to Notion. If you only need real-time text editing, Etherpad is lighter. The choice depends on whether you value structured documents over simplicity.
Editorial conclusion
Adopt La Suite Docs if you need a self-hosted, real-time collaborative editor with structured documents and sub-documents, and you are comfortable with Django and Docker. Avoid it if you require full MIT purity out of the box; the default build includes GPL-licensed Blocknote XL packages for features like PDF export, and you must build with PUBLISH_AS_MIT=true to strip them. Before deploying, verify which advanced features you depend on and whether the GPL components are acceptable for your use case. Also check the resource server API and server-to-server API documentation to ensure your integration needs are met. The project is actively maintained with recent releases, but the licensing nuance is a real decision point.
Community notes