ONLYOFFICE DocSpace

• In the Azure Portal, search the Marketplace for ONLYOFFICE DocSpace on Ubuntu 24.04 LTS and select the SecureAnyCloud offer.
• Choose Standard_B4ms or larger.
• Set the administrator username to azureuser and upload your SSH public key.
• On the Networking tab, allow inbound SSH (22) and HTTPS (443).
• Review and create.

az vm image terms accept --urn sac1647283583153:onlyoffice-docspace-ubuntu-24-04:default:latest
az vm create \
  --resource-group my-docspace-rg \
  --name my-docspace-vm \
  --image sac1647283583153:onlyoffice-docspace-ubuntu-24-04:default:latest \
  --size Standard_B4ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

ssh azureuser@<vm-ip>

onlyoffice-docspace-firstboot is a one-shot unit that runs once, on the first boot. It generates every secret this VM needs, issues the TLS certificate, arms the setup gate, and only then releases the DocSpace and Document Server services. Until it finishes, the web address answers HTTP 503 rather than serving a half-configured portal.

sudo systemctl status onlyoffice-docspace-firstboot.service --no-pager | head -5

The stack then takes two to three minutes to warm up on a fresh boot, because more than twenty services compile and start at once. Confirm that the core services are active:

systemctl is-active mysql redis-server rabbitmq-server opensearch openresty nginx ds-docservice \
  docspace-api docspace-studio docspace-files docspace-people-server docspace-login docspace-doceditor \
  docspace-socket docspace-identity-api docspace-identity-authorization | sort | uniq -c

Expected output:

16 active

Confirm that the DocSpace API answers through the loopback front:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/api/2.0/settings

Expected output:

200

Then confirm that the Document Server behind it is healthy:

curl -s http://127.0.0.1/ds-vpath/healthcheck; echo

Expected output:

true

Everything unique to this VM is written to a root-only file on first boot:

sudo cat /root/onlyoffice-docspace-credentials.txt

This file contains:

• DOCSPACE_URL: the address to open in a browser, https://<your VM address>/
• SETUP_URL: the one-time setup link that unlocks the first-run wizard, and SETUP_KEY, the key inside it
• MYSQL_PASSWORD, RABBITMQ_PASSWORD, REDIS_PASSWORD: the per-VM passwords of the onlyoffice database, broker and cache accounts, all on loopback
• JWT_SECRET: the secret that authenticates every request between DocSpace and the Document Server

DocSpace creates its owner account through a wizard that upstream serves to anyone who reaches the portal first. On a public IP, that is a race you could lose. This image closes it. Until the wizard is complete, every request to the front door is answered with 403 unless it carries a cookie that only the setup link can set.

sudo onlyoffice-docspace-setup-gate status

Expected output on a freshly deployed VM:

armed (waiting for the owner to complete the setup wizard)

Prove it from the VM itself. Without the cookie, the portal is closed:

curl -ks -o /dev/null -w '%{http_code}\n' https://127.0.0.1/

Expected output:

403

A wrong key is refused in the same way. The real setup link answers with a redirect and sets the cookie:

SETUP_KEY=$(sudo grep '^SETUP_KEY=' /root/onlyoffice-docspace-credentials.txt | cut -d= -f2-)
WRONG=$(curl -ks -o /dev/null -w '%{http_code}' 'https://127.0.0.1/sac-setup?key=not-the-key')
RIGHT=$(curl -ks -o /dev/null -w '%{http_code}' "https://127.0.0.1/sac-setup?key=${SETUP_KEY}")
echo "wrong key -> ${WRONG}; setup link -> ${RIGHT}"

Expected output:

wrong key -> 403; setup link -> 302

A timer on the VM polls DocSpace every ten seconds and opens the gate as soon as the wizard reports complete. To open the gate by hand, run sudo onlyoffice-docspace-setup-gate lift.

Open the SETUP_URL from Step 5 in a browser. The image ships a self-signed certificate generated for this VM, so your browser warns you on the first visit. Accept the warning, or install a trusted certificate as described below. The link sets the setup cookie and takes you to the DocSpace wizard, where you choose the owner email address and password.

Within seconds of the wizard finishing, the gate opens and the same address serves the DocSpace sign-in page to everyone. From then on, the portal is protected by DocSpace accounts, roles and sharing rules, as upstream designed them.

Sign in as the owner and use Rooms to create your first room. A collaboration room suits a team that co-edits files. Inside the room, select Create new to start a document, spreadsheet, presentation or form, and select Upload to bring in existing files.

Opening a document launches the ONLYOFFICE Docs editor in the same tab. The Document Server on this VM serves the editor through the front door under /ds-vpath/, and every editing session is authenticated with the per-VM JWT secret from Step 5. Text you type is saved back into the room automatically.

Contacts lists members, guests and admins. To invite people by email, first configure an SMTP server under Settings > Integration > SMTP settings. Alternatively, generate an invitation link and share it yourself, which needs no mail server.

List every socket bound to an address other than loopback, so that anything unexpected shows up:

sudo ss -lntH | awk '{print $4}' | grep -vE '^(127\.|\[::1\]|\[::ffff:127\.)' | sed -E 's/.*:([0-9]+)$/\1/' | sort -un | tr '\n' ' '; echo

Expected output:

22 80 443 8000

Ports 22, 80 and 443 are the public surface. Port 8000 belongs to the Document Server process. It is a compiled binary that binds every interface and offers no setting to change that, so the image closes the port with a host firewall instead. ufw runs with a default-deny inbound policy and exactly three allow rules:

sudo ufw status verbose | grep -E '^(Status|Default)|ALLOW IN'

Expected output:

Status: active Default: deny (incoming), allow (outgoing), disabled (routed) 22/tcp ALLOW IN Anywhere 80/tcp ALLOW IN Anywhere 443/tcp ALLOW IN Anywhere 22/tcp (v6) ALLOW IN Anywhere (v6) 80/tcp (v6) ALLOW IN Anywhere (v6) 443/tcp (v6) ALLOW IN Anywhere (v6)

Every backend sits on loopback: MySQL on 3306, Redis on 6379, RabbitMQ on 5672, OpenSearch on 9200, the Document Server's nginx on 8083, the DocSpace router on 8092 and the individual DocSpace services on 5000 to 5158, 8080, 8888, 9090, 9834, 9899 and 9999:

sudo ss -lntH | awk '{print $4}' | grep -E ':(3306|6379|5672|9200|8083|8092|5011|9899|9090)$' | sort -u

Expected output:

127.0.0.1:3306 127.0.0.1:5011 127.0.0.1:5672 127.0.0.1:6379 127.0.0.1:8083 127.0.0.1:8092 127.0.0.1:9899 [::1]:9200 [::ffff:127.0.0.1]:9090 [::ffff:127.0.0.1]:9200

The passwords in the credentials file are the live ones, and none of the backends answers without them:

MYSQL_PASSWORD=$(sudo grep '^MYSQL_PASSWORD=' /root/onlyoffice-docspace-credentials.txt | cut -d= -f2-)
REDIS_PASSWORD=$(sudo grep '^REDIS_PASSWORD=' /root/onlyoffice-docspace-credentials.txt | cut -d= -f2-)
mysql -uonlyoffice -p"${MYSQL_PASSWORD}" -N -e 'SELECT COUNT(*) AS tables_in_onlyoffice FROM information_schema.tables WHERE table_schema="onlyoffice"' 2>/dev/null redis-cli -a "${REDIS_PASSWORD}" --no-auth-warning ping redis-cli ping 2>&1 | grep -o NOAUTH

Expected output (the table count grows with upgrades):

86 PONG NOAUTH

The Document Server only accepts editing sessions signed with this VM's JWT secret, and DocSpace signs every one with the same value:

JWT=$(sudo grep '^JWT_SECRET=' /root/onlyoffice-docspace-credentials.txt | cut -d= -f2-)
DS=$(sudo jq -r '.services.CoAuthoring.secret.inbox.string' /etc/onlyoffice/documentserver/local.json)
APP=$(sudo jq -r '.files.docservice.secret.value' /etc/onlyoffice/docspace/appsettings.community.json) [ "${JWT}" = "${DS}" ] && [ "${JWT}" = "${APP}" ] && echo "DocSpace and Document Server share this VM's JWT secret" || echo "MISMATCH"

Expected output:

DocSpace and Document Server share this VM's JWT secret