Documize Community: self-hosted docs on a single binary and your own database

What Documize Community is for

Documize Community is a self-hosted knowledge management system aimed at teams that need one place for documentation that faces customers and documentation that stays internal. The README frames it that way directly: it is "designed to unify both customer-facing and internal documentation." Organization happens through labels, spaces and categories, which is the vocabulary you will use throughout the UI.

The intended audience is mixed. The project says it is built for technical and non-technical users, which matters because the people writing support articles are rarely the people writing API notes. A single binary serving both groups removes the usual split where engineering keeps a wiki and support keeps a separate help center.

What it is not: a hosted service. You supply the database, you run the process, and you own the backups. That is the trade. In exchange you get no per-seat ceiling from the software itself and no data leaving your network.

How the Go binary and EmberJS front end fit together

The architecture is visible in the repository layout. The Go side lives in core/, server/, domain/ and model/, and the EmberJS application lives in gui/. The Dockerfile builds the front end first with Node, then copies the compiled assets into edition/static/public/ before the Go build runs. That is why the README can describe the result as a single executable: the Ember app is compiled and embedded rather than served from a separate web server.

The dependency list in go.mod confirms the shape of the backend. gorilla/mux handles routing, jmoiron/sqlx sits over the database drivers (lib/pq for PostgreSQL, go-sql-driver/mysql for MySQL, microsoft/go-mssqldb for SQL Server), go-ldap/ldap/v3 covers directory authentication, and gopkg.in/cas.v2 covers CAS. There is also documize/blackfriday, a fork of a Markdown renderer, and microcosm-cc/bluemonday, an HTML sanitizer, which tells you content is stored and rendered as HTML derived from Markdown with sanitization in the pipeline.

Data flow is conventional: the browser talks to the Go server, the server reads and writes your database, and full-text search is delegated to the database engine rather than implemented in Go. That last point drives most of the operational constraints below.

Installing Documize Community with Docker Compose

The repository ships a docker-compose.yaml that starts PostgreSQL 12 and the application together. Note that the compose file as written pulls the Community+ binary from a public Amazon S3 bucket; the comments state you can swap the filename to documize-community-linux-amd64 for the Community edition, and that you can move between editions without data loss because the schema is shared.

services:
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: documize
      POSTGRES_PASSWORD: Passw0rd
      POSTGRES_DB: documize
  app:
    image: debian:latest
    ports:
      - 5001:5001
    environment:
      DOCUMIZEPORT: 5001
      DOCUMIZEDB: host=db port=5432 dbname=documize user=documize password=Passw0rd sslmode=disable
      DOCUMIZEDBTYPE: postgresql
      DOCUMIZESALT: hsk3Acndky8cdTNx3
      DOCUMIZELOCATION: selfhost

Those environment variables are the whole configuration surface shown here. DOCUMIZEDB is a connection string, DOCUMIZEDBTYPE selects the engine, DOCUMIZEPORT is the listening port, and DOCUMIZESALT is a value you should not leave at the sample setting on a real deployment. DOCUMIZELOCATION is set to selfhost.

docker-compose up

After the containers start, the application listens on port 5001. The compose file mounts a named volume for the PostgreSQL data directory, so the database survives a restart of the stack. The comments also warn that the application container installs wget and downloads the binary at startup, which means the first run needs outbound network access to downloads.documize.com.

If you would rather build from source, the Dockerfile shows the two stages: an npm install and npm run build inside gui/, then a Go build that copies the compiled assets into edition/static/public/. The README states the toolchain versions as Go v1.25.1 and Ember JS v3.12.0, while the Dockerfile itself pins golang:1.21-alpine and node:16-alpine.

Full-text search is mandatory, and that is a real constraint

The README is blunt about this: "For all database types, Full-Text Search (FTS) support is mandatory." This is the single most likely reason an otherwise fine deployment fails. PostgreSQL needs the FTS machinery available in the instance you point at, MySQL needs the InnoDB full-text indexes that arrive at v5.7.10 and again at v8.0.12, and SQL Server needs the Full-Text Search feature installed, which is a separate component in the installer and is not always present on managed instances.

The version floors are equally specific: PostgreSQL v9.6+, SQL Server 2016+ with FTS, SQL Azure v12+, MySQL v5.7.10+ and v8.0.12+, Percona v5.7.16-10+, MariaDB v10.3.0+. If your managed database provider gives you MariaDB below 10.3, or a MySQL build without the full-text index support, the application has nowhere to go. There is no fallback search engine bundled in the Go code, based on the dependency list.

A second limitation sits in the edition split. Content approval workflows, version management, lifecycle management, feedback capture, PDF export, analytics and reporting, activity streams, audit logs and actions assignments are listed in the README as Community+ capabilities, not Community ones. If your compliance process depends on audit logs or approval gates, the Community edition is the wrong tool and the README points you at the paid edition instead.

Authentication, localization and what the README leaves open

Beyond email and password, the README lists LDAP, Active Directory, Red Hat Keycloak and CAS. It notes that with LDAP or Active Directory you can enable dual authentication alongside email and password, which is useful during a migration when some accounts have not been moved yet. The go.mod file backs this up with go-ldap/ldap/v3 and gopkg.in/cas.v2, and the repository topics include keycloak.

Localization ships for English, German, French, Chinese, Portuguese (Brazil), Japanese, Italian, Spanish Argentinian and Polish, with pull requests invited for more. Browser support covers Firefox, Chrome, Safari, Microsoft Edge, Brave, Vivaldi and Opera. OS support covers Linux, Windows, macOS and Raspberry Pi via an ARM build, with both AMD and ARM 64-bit architectures supported.

What the README does not document is as telling as what it does. There is no rollback procedure, no backup guidance beyond the database you supply, no migration path between database engines, and no documented upgrade sequence between releases. The release cadence visible in the release list is uneven: v5.12.0 in June 2024, v5.13.0 in December 2024, v5.14.0 in September 2025. The last push to the repository was on 2026-05-18. Those are the only maintenance signals available, and they say the project moves in bursts rather than continuously.

Documize Community against Confluence and plain wikis

The README positions this as a "Modern Confluence alternative," and the practical difference is deployment model. Confluence is a Java application you host or buy as a cloud service, with its own database requirements and its own licensing tiers. Documize Community compiles to a single Go executable, and the only external service it needs is a database you probably already run. That is a meaningfully smaller operational footprint: one process, one connection string, no JVM tuning.

The difference against a plain wiki (a Markdown repository, a lightweight wiki engine) is the structure. Labels, spaces and categories are first-class, and the project targets both internal and customer-facing documentation from the same instance. A flat wiki gives you pages and search; Documize gives you an organizing model plus dashboards and reporting, though the README lists reporting and analytics under Community+ rather than Community.

Against the paid edition the difference is purely feature scope, not format. The compose file comments state you can move between editions at any time without data loss because the schema is common. That is an unusually clean upgrade path and worth weighing if you expect to grow into approval workflows later.

Licence and the cost of staying current

Documize Community edition is licensed under GNU AGPL v3. The AGPL's distinguishing feature is the network clause: if you run modified software and let users interact with it over a network, the licence expects you to offer those users the corresponding source. Running the unmodified binary internally is a different situation from shipping a modified Documize as part of a product. This is not legal advice, and if your organization redistributes software, the licence text at gnu.org is the thing to read, not this paragraph.

The README also acknowledges third-party components in a NOTICES.md file at the repository root, which is where you would look for the licences of the bundled front-end libraries.

Upgrade cost is hard to estimate. Three releases appear in the list over roughly fifteen months, and the README documents no upgrade procedure, no schema migration command and no rollback. The compose file's shared-schema claim between editions is the only migration statement present. In practice that means treating the database as the thing you back up, and testing an upgrade on a copy before touching production, because the project does not tell you how to undo one.

Editorial conclusion

Adopt Documize Community if you want a self-hosted knowledge base that runs as one binary against a database you already operate, and if full-text search on that database is something you can enable today. Do not adopt it if you cannot turn on FTS, if you need the approval workflows, version management, audit logs or PDF export that the README lists only for Community+, or if AGPL-3.0 obligations do not fit how you distribute software. Verify three things before committing: that your database version meets the stated minimum, that FTS is actually enabled on the instance you plan to use, and which edition the binary you download corresponds to.

Frequently asked questions

Official sources

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