Documize Community on Ubuntu 24.04 on Azure User Guide

Overview

This guide covers the deployment and configuration of Documize Community 5.14.0 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Documize is a modern, open source, self-hosted knowledge base and documentation platform — a clean alternative to Confluence for internal and external docs. You organise content into spaces, build documents from reusable content blocks and templates, group them with categories, and find anything with full-text search, while Documize keeps a version history and enforces per-space, role-based access.

The image installs the official Documize v5.14.0 release binary (a single, statically-linked Go binary) verified by SHA-256 at install time, ships the AGPL-3.0 licence text alongside it, and backs it with MariaDB on the same VM. The Community edition is fully functional for all core knowledge-base features with no paid licence key.

Security model. Documize's own first-run setup wizard is unauthenticated (anyone who reaches an un-provisioned instance could seize the administrator account), so cloudimg completes setup at build time — a customer instance never enters setup mode and that endpoint is never exposed. The Documize server binds to 127.0.0.1:5001 only (pinned by an on-box nftables rule) and is fronted by nginx on port 80. Access is gated by Documize's own per-VM administrator login: no default, shared or blank credential ships in the image. On first boot a one-shot service mints a unique administrator password, database password and JWT signing salt, rotates the administrator before the Documize service is allowed to start, and writes the credentials to a root-only file. The only ports exposed are SSH (22) and the web UI (80, with 443 available for you to add TLS).

A note on the reverse proxy. Documize authenticates every request through the HTTP Authorization header (Basic for login, Bearer for the API). An nginx HTTP Basic Auth layer would consume that same header and break Documize's own login in a browser, so the reverse proxy deliberately adds no Basic Auth — the appliance relies on Documize's strong per-VM login plus the loopback pin (two non-conflicting layers: network isolation and application auth).

What is included:

• Documize Community 5.14.0 official release binary at /usr/local/bin/documize (SHA-256-verified)

• documize.service systemd unit running the server bound to 127.0.0.1:5001, gated on a first-boot marker

• documize-firewall.service (nftables) pinning port 5001 to loopback only

• nginx reverse proxy on port 80 in front of Documize

• MariaDB on 127.0.0.1:3306 holding the knowledge base, provisioned (schema + organisation + administrator) at build time

• documize-firstboot.service systemd oneshot that mints the per-VM administrator, database and JWT secrets on first boot

• A credential self-test at /usr/local/sbin/documize-credcheck.sh

• The AGPL-3.0 licence text at /usr/local/share/documize/LICENSE

• Ubuntu 24.04 LTS base with latest security patches applied at build time

• 24/7 cloudimg support with guaranteed 24 hour response SLA

Prerequisites

• An active Azure subscription

• A subscription to the Documize on Ubuntu 24.04 listing on Azure Marketplace

• An SSH public key for VM authentication

• A virtual network and subnet in the target region

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM). Documize is lightweight; scale up for larger teams, bigger knowledge bases or heavy concurrent editing.

Step 1: Deploy from the Azure Portal

Navigate to Marketplace in the Azure Portal, search for Documize, select the cloudimg publisher entry, and click Create.

On the Networking tab attach a network security group that allows inbound TCP 22 from your management IP range and TCP 80 from the client networks that will use the knowledge base. Add TLS (port 443) before putting anything sensitive in your knowledge base — see Step 9.

Click Review + create, wait for validation, then Create. Deployment takes around two minutes.

Step 2: Deploy from the Azure CLI

RG="documize-prod"
LOCATION="eastus"
az group create --name "$RG" --location "$LOCATION"

az vm create \
  --resource-group "$RG" \
  --name documize-01 \
  --image <publisher>:<offer>:<sku>:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

# Allow SSH (22) and the web UI (80) from your trusted ranges
az vm open-port --resource-group "$RG" --name documize-01 --port 22 --priority 1001
az vm open-port --resource-group "$RG" --name documize-01 --port 80 --priority 1002

Replace <publisher>:<offer>:<sku> with the URN shown on the Marketplace listing's Usage Information tab.

Step 3: Connect via SSH

ssh azureuser@<vm-public-ip>

Use the private key that matches the public key you supplied at deploy time. The login user for this image is azureuser.

Step 4: Verify the Documize Service

Confirm MariaDB, the Documize server and the nginx proxy are running, check the listening sockets, and confirm the AGPL-3.0 licence ships with the image. Documize binds to 127.0.0.1:5001 and MariaDB to 127.0.0.1:3306 — both are reachable only on loopback; nginx on port 80 is the single customer-facing surface.

documize -version
systemctl is-active mariadb documize nginx
sudo ss -ltn | grep -E ':80 |:5001 |:3306 '
head -2 /usr/local/share/documize/LICENSE

Expected output:

Documize Community v5.14.0 (build 1758297927)
active
active
active
LISTEN 0   511      0.0.0.0:80       0.0.0.0:*
LISTEN 0  4096          *:5001           *:*
LISTEN 0    80     127.0.0.1:3306      0.0.0.0:*
                    GNU AFFERO GENERAL PUBLIC LICENSE
                       Version 3, 19 November 2007

Step 5: Understand the Loopback Pin

Documize itself binds port 5001 on all interfaces, so an on-box nftables rule (documize-firewall.service) accepts only loopback-destined traffic to 5001 and drops everything else. nginx reaches Documize over loopback; nothing off the VM can talk to 5001 directly. Confirm both halves:

curl -s -o /dev/null -w 'loopback :5001 -> HTTP %{http_code}\n' http://127.0.0.1:5001/api/public/meta
curl -s -m 5 -o /dev/null -w '%{http_code}\n' "http://$(hostname -I | awk '{print $1}'):5001/" \
  || echo 'off-loopback :5001 dropped (nft pin)'
sudo nft list table inet documize_localonly | grep -E 'daddr|drop'

Expected output:

loopback :5001 -> HTTP 200
off-loopback :5001 dropped (nft pin)
        ip daddr 127.0.0.0/8 accept
        tcp dport 5001 drop

Step 6: Retrieve Your Per-VM Credentials

On the first boot of your virtual machine, documize-firstboot.service generated an administrator password, a database password and a JWT signing salt unique to your instance, rotated the administrator account, and wrote the credentials to a root-only file. Retrieve them with:

sudo cat /root/documize-credentials.txt

The file reports the URL and the Documize administrator login:

documize.url=http://<vm-public-ip>/
documize.admin.email=admin@documize.local
documize.admin.password=<generated-per-vm>
documize.db.name=documize
documize.db.user=documize
documize.db.password=<generated-per-vm>

A shipped self-test confirms the whole credential model without printing any secret — it proves Documize is up through nginx and on loopback, the per-VM administrator authenticates through the real login endpoint, and common guessable passwords are rejected:

sudo bash /usr/local/sbin/documize-credcheck.sh

Expected output:

OK

Step 7: Understand the Access Model

Everything Documize serves is behind its own login — there is no anonymous access by default. The administrator password is unique to your instance and the upstream default and common guesses are rejected. You can see this with curl against the login endpoint through nginx (port 80):

AE=$(sudo grep '^documize.admin.email=' /root/documize-credentials.txt | cut -d= -f2-)
AP=$(sudo grep '^documize.admin.password=' /root/documize-credentials.txt | cut -d= -f2-)
b64() { printf '%s' "$1" | base64 | tr -d '\n'; }
curl -s -o /dev/null -w 'per-VM admin -> HTTP %{http_code}\n' -X POST \
  -H "Authorization: Basic $(b64 ":$AE:$AP")" http://127.0.0.1/api/public/authenticate
curl -s -o /dev/null -w 'admin/password -> HTTP %{http_code}\n' -X POST \
  -H "Authorization: Basic $(b64 ":$AE:password")" http://127.0.0.1/api/public/authenticate

Expected output:

per-VM admin -> HTTP 200
admin/password -> HTTP 401

Step 8: Sign In

In a browser, go to http://<vm-public-ip>/. Documize shows its sign-in page. Enter the administrator email (admin@documize.local) and the documize.admin.password from Step 6:

Once signed in you land on the spaces dashboard. Change the administrator password immediately from the account menu (top right). Then click + SPACE to create your first space — a container for related documents, with its own membership and permissions:

Step 9: Create and Read Documents

Open a space and add a document. Documents are built from reusable content blocks (rich text, code, tables, diagrams and more), organised with a table of contents, versioned, and searchable across the whole knowledge base. A rendered document looks like this:

You can automate content with the Documize REST API. Authenticate to get a token, then create spaces, documents and pages programmatically:

# Get a JWT (domain is empty for a single-org self-hosted instance):
TOKEN=$(curl -s -X POST \
  -H "Authorization: Basic $(printf ':%s:%s' admin@documize.local '<admin-password>' | base64)" \
  http://<vm-public-ip>/api/public/authenticate | jq -r .token)

# Create a space:
curl -s -X POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"name":"Runbooks"}' http://<vm-public-ip>/api/space

Step 10: Put TLS in Front (Production)

The UI is served over plain HTTP on port 80. Before putting anything sensitive in your knowledge base, terminate TLS in front of Documize. Add a Let's Encrypt certificate to the bundled nginx:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

Point your DNS A record at the VM's public IP first, and open port 443 in the network security group. Certbot updates the bundled nginx vhost in place, preserving the reverse-proxy setup. Documize builds its links from the request host, so no application change is needed after you add a domain.

Step 11: Change the Administrator Password and Add Users

Change the administrator password from Documize's own account menu after signing in (Step 8). To add more people, open Settings → Users and invite them, or connect an external identity provider — Documize Community supports LDAP, Keycloak, CAS and OAuth2. Configure these under Settings → Integrations / Authentication, then restart the service:

sudo systemctl restart documize

Step 12: Back Up the Knowledge Base

All content lives in the bundled MariaDB documize database on loopback. Take a consistent dump with the local socket (root uses unix_socket auth — no password on-box):

sudo mariadb-dump --single-transaction documize | gzip > documize-backup-$(date +%F).sql.gz
ls -lh documize-backup-*.sql.gz

Restore into a fresh instance with gunzip -c documize-backup-YYYY-MM-DD.sql.gz | sudo mariadb documize. Store backups off the VM (for example in Azure Blob Storage).

Step 13: Managing the Documize Service

# Status and logs
systemctl status documize --no-pager
sudo journalctl -u documize -n 100 --no-pager

# Restart after changing configuration in /etc/documize/documize.env
sudo systemctl restart documize

# nginx (the reverse proxy)
sudo nginx -t && sudo systemctl reload nginx

Architecture Summary

• Documize Community 5.14.0 — a single statically-linked Go binary at /usr/local/bin/documize, run as the non-root documize service account under systemd, bound to 127.0.0.1:5001 and gated on a first-boot marker.

• MariaDB on 127.0.0.1:3306 (loopback only) holding the documize database — schema, organisation and administrator provisioned at build time so no unauthenticated setup wizard is ever exposed.

• nftables (documize-firewall.service) pinning port 5001 to loopback, so the server is never reachable off the VM directly.

• nginx on port 80 — reverse proxy in front of Documize. Access is gated by Documize's own per-VM administrator login (no Basic Auth layer, which would hijack Documize's Authorization-header authentication).

• First-boot service mints a per-VM administrator password, database password and JWT salt, rotates the administrator, and writes them to a root-only credentials file. No shared or default credential ships in the image.

Support

cloudimg provides 24/7 technical support for this Documize image by email (support@cloudimg.co.uk) and live chat, with a guaranteed 24 hour response SLA and a one hour average response time for critical issues. We help with deployment, retrieving and rotating the first-boot credentials, creating spaces and documents, configuring users, groups and per-space permissions, integrating LDAP, Keycloak, CAS or OAuth authentication, adding HTTPS and a custom domain, database backup and restore, upgrades and patch management, and troubleshooting. For billing, subscription changes or refund requests, contact support@cloudimg.co.uk.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.