Documize

In the Azure portal, open the Marketplace, search for Documize, select the SecureAnyCloud 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 you put anything sensitive in your knowledge base. See Step 10.

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

RG="documize-prod" LOCATION="eastus" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:documize-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" \
  --name documize-01 \
  --image sac1647283583153:documize-ubuntu-24-04:default: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.

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.

Confirm that MariaDB, the Documize server and the nginx proxy are running, check the listening sockets, and confirm that the AGPL-3.0 licence ships with the image.

Documize binds to 127.0.0.1:5001 and MariaDB binds to 127.0.0.1:3306. Both are reachable only on loopback, and 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

Documize itself binds port 5001 on all interfaces. An on-box nftables rule (documize-firewall.service) therefore accepts only loopback-destined traffic to 5001 and drops everything else. nginx reaches Documize over loopback, and 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

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. It 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 that Documize is up through nginx and on loopback, that the per-VM administrator authenticates through the real login endpoint, and that common guessable passwords are rejected:

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

Expected output:

OK

Everything Documize serves is behind its own login, and 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

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:

After you sign in, the spaces dashboard opens. Change the administrator password immediately from the account menu (top right).

Then click + SPACE to create your first space. A space is a container for related documents, with its own membership and permissions:

Open a space and add a document. Documents are built from reusable content blocks (rich text, code, tables, diagrams and more). They are 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, and 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

The UI is served over plain HTTP on port 80. Before you put 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

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

After you sign in, change the administrator password from Documize's own account menu (Step 8). To add more people, open Settings → Users and invite them. You can also connect an external identity provider, because Documize Community supports LDAP, Keycloak, CAS and OAuth2. Configure these under Settings → Integrations / Authentication, then restart the service:

sudo systemctl restart documize

All content lives in the bundled MariaDB documize database on loopback. Take a consistent dump through the local socket. Root uses unix_socket authentication, so no password is needed on the VM:

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.

# 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