Configure HTTPS for ONLYOFFICE Docs in Docker

For a direct connection to ONLYOFFICE Docs, publish container port 443, persist the certificate files under the mounted data directory, and point the container at those files. If a reverse proxy already provides HTTPS, keep TLS at that proxy and forward the original host and protocol to ONLYOFFICE instead of enabling a second TLS endpoint by default.

For example, if the public hostname is docs.example.com, first determine whether it points directly to Document Server or to a proxy. Use only the matching configuration below.

1. Decide where HTTPS ends

TLS terminates where HTTPS is decrypted: either in the ONLYOFFICE container or at a reverse proxy. Choose the component that receives the public connection.

• Direct access: clients connect to https://docs.example.com on the host’s port 443, which is mapped to container port 443. The Document Server container needs a certificate and its matching private key.
• Proxy access: clients connect to the proxy over HTTPS; the proxy forwards traffic to Document Server over the internal network. In this setup, the certificate normally belongs at the proxy. ONLYOFFICE’s proxy guidance calls for the X-Forwarded-Proto and X-Forwarded-Host headers so the application can identify the public request scheme and hostname.

Port mapping 443:443 does not create HTTPS; it only maps ports. For direct access, the container must also read the certificate and key. If the proxy owns the public URL, use ONLYOFFICE’s official reverse-proxy instructions.

2. Configure direct HTTPS in Docker Compose

Use this path when the container serves HTTPS directly. For public access, use a certificate trusted by clients for the public hostname. A self-signed certificate can encrypt traffic, but clients will warn about identity unless they are separately configured to trust it.

ONLYOFFICE Docs stores certificates below /var/www/onlyoffice/Data/certs by default, and its current Docker configuration lists tls.crt and tls.key as the default certificate and key paths. The documentation examples have not always used identical filenames, so this example sets both paths explicitly.

services:
  documentserver:
    # Keep your existing image, environment, networks, and other settings.
    ports:
      - "443:443"
    volumes:
      - ./documentserver-data:/var/www/onlyoffice/Data
    environment:
      SSL_CERTIFICATE_PATH: /var/www/onlyoffice/Data/certs/tls.crt
      SSL_KEY_PATH: /var/www/onlyoffice/Data/certs/tls.key

This is an excerpt, not a replacement service definition. Keep existing image, JWT, network, and volume settings. Relative to the Compose file, place the certificate at ./documentserver-data/certs/tls.crt and its matching key at ./documentserver-data/certs/tls.key. Include the certificate chain supplied by your provider, and ensure the certificate covers docs.example.com.

The bind mount keeps the files outside a replaceable container. Restrict private-key access while ensuring the container can read it; otherwise HTTPS may fail to start. Never share the key in a support request.

3. Apply the change without replacing the deployment accidentally

1. Back up the Compose file and certificate directory, then confirm the certificate and key are the matching pair for the public hostname.
2. Make the port, volume, and path changes in the existing service. Do not start a second container with the same host port or discard existing volumes to apply TLS.
3. Recreate the service if you changed its ports, mounts, or environment. With Compose, run docker compose up -d documentserver from the directory containing the Compose file, substituting your actual service name. If you only replaced certificate files in an already-mounted directory, restart the existing container so the server reloads the files: docker restart <container_name>.
4. Check startup logs if HTTPS does not come up: docker logs <container_name>. Look for missing-file, permission, or certificate/key errors before changing unrelated settings.

A restart cannot add a mount or change published ports; recreate the service for those edits. Replacing files in an existing persistent mount does not require a Compose change.

4. Keep TLS at a reverse proxy when it already serves the domain

If a reverse proxy already terminates https://docs.example.com, keep its private key at the proxy. Forward traffic over a controlled network and set X-Forwarded-Proto: https plus X-Forwarded-Host to the public hostname. Use the official sample for your proxy software.

The browser padlock covers the client-to-proxy connection, not necessarily every internal hop. HTTP on a controlled Docker network may fit some deployments; secure the proxy-to-container hop if it crosses an untrusted network.

Another limit: changing TLS does not repair an invalid JWT, a blocked firewall port, or an incorrect public Document Server address in the integration settings. If the certificate is valid but document loading or editing still fails, check the relevant application and proxy logs rather than repeatedly regenerating certificates.

Verify the result

From a client that can reach the public service, open https://docs.example.com and inspect the browser’s certificate details. Confirm that the hostname matches, the certificate is within its validity period, and the browser does not report an untrusted issuer or name mismatch. You can also inspect the TLS handshake from a terminal with curl -Iv https://docs.example.com; review the certificate and connection output rather than relying only on whether a page loads.

Finally, open a document from the integrating application. Browser success confirms the public endpoint, not every integration setting or internal route. For certificate warnings, recheck hostname, chain, paths, permissions, and TLS termination. If HTTPS verifies but editing fails, check logs and authentication or routing settings.

For details on the supported Docker paths, certificate variables, and built-in Let’s Encrypt options, see ONLYOFFICE’s Docker installation and HTTPS documentation. The exact command to update an existing deployment depends on how it was originally created; preserve that deployment’s current volumes and integration settings while applying the relevant TLS changes.