Deployment Manual6 min readReviewed 2026-05-15

Infrastructure Baseline

DeskDox EDMS is deployed as a controlled enterprise document management platform. This Deployment Manual defines the infrastructure baseline used to plan, install, secure, validate, and operate DeskDox in customer-managed environments.

Purpose

This manual is written for infrastructure planning, deployment readiness review, architecture workshops, production preparation, and operational handover. It explains the expected platform, service topology, network exposure model, security baseline, storage and backup scope, and operational responsibilities for DeskDox deployments.

The manual is public Help Center documentation. It is not a commercial or formal completion document. Deployment teams can use it to prepare implementation notes and handover records, but final operational decisions remain part of the customer's normal governance process.

Primary Audience

Audience	Expected use of this guide
Enterprise IT and infrastructure teams	Confirm servers, storage, network, DNS, TLS, firewall, backup, and monitoring readiness.
Solution architects	Review logical architecture, deployment models, service boundaries, and sizing assumptions.
Deployment engineers	Plan installation, validate Compose/runtime configuration, and prepare deployment handover notes.
Security and risk teams	Review exposure boundaries, TLS, secrets, privileged access, backup handling, auditability, and hardening.
Operations and support teams	Establish monitoring, patching, backup review, escalation, and maintenance ownership.

Scope

This manual covers customer-managed deployments using repository-supported container deployment patterns:

Linux Docker Compose production deployment using docker-compose.prod.yml.
Windows offline installer deployment using deploy-kit/compose/docker-compose.production.yml and the deploy-kit PowerShell scripts.
VPS or private-cloud single-server deployment where the customer controls the host, DNS, firewall, and backup destination.
Conditional two-tier or three-tier readiness planning where components may be separated after solution review.

The manual does not present Kubernetes, managed database, multi-region, or active-active high availability as packaged deployment options. Those patterns require separate design validation and are treated as future-state or customer-specific architecture.

In Scope and Out of Scope

Area	Guidance
In scope	Infrastructure planning, deployment readiness, service topology, ports, storage, backup, restore validation, security hardening, and operational baseline.
Out of scope	Commercial terms, formal completion records, custom HA design, and customer-specific network diagrams.
Technical source of truth	Current repository Compose files, configuration templates, application settings, NGINX configuration, and deploy-kit scripts.
Deprecated assumptions	Redis and Celery are not part of the current production Compose service baseline and are not documented as required deployment services.

Deployment Assumptions

The current production baseline assumes:

DeskDox runs as a Docker Compose application.
PostgreSQL 16 is the primary database engine for production compose deployments.
Uploaded documents, previews, search/index artifacts, licensing files, and backups are persisted on mounted filesystem paths.
Gotenberg 8 provides document conversion for preview generation.
Dedicated preview-worker and index-worker containers are present in the production compose paths.
The frontend container serves the React application through NGINX and proxies /api/ traffic to the backend.
The database, converter, workers, and backend API remain internal unless a deployment-specific design explicitly requires otherwise.
Linux is the preferred production baseline. Windows deployment is supported through the offline deploy-kit model with explicit operational boundaries.

Production Baseline at a Glance

flowchart LR
    Users["Users and administrators"] --> Edge["Customer DNS, TLS edge, or reverse proxy"]
    Edge --> Frontend["frontend"]
    Frontend --> Backend["backend"]
    Backend --> Postgres[("postgres")]
    Backend --> Storage[("documents, previews, index data")]
    Backend --> Gotenberg["gotenberg"]
    Preview["preview-worker"] --> Storage
    Preview --> Gotenberg
    Index["index-worker"] --> Storage
    Backend --> SMTP["SMTP relay"]
    Backend --> Optional["Optional AI, WhatsApp, or API integrations"]
    Storage --> Backup[("backup storage")]
    Postgres --> Backup

Deployment Planning Areas

DeskDox deployment planning should cover the following areas before production use:

Area	Baseline guidance	Planning note
Controlled exposure	Users should reach only the approved web endpoint.	Internal ports must not be exposed publicly.
Persistent storage	Database, uploads, previews, index data, backups, and licensing state must survive container replacement.	Storage layout affects backup and restore design.
Workload-based sizing	CPU, RAM, database, and storage sizing must reflect real workload.	Concurrency, document volume, OCR, previews, retention, and RPO/RTO matter more than user count alone.
Recoverability	Backups must include the database and required file stores.	Production deployments should include restore validation before go-live.
Least privilege	Host, Docker, database, application admin, and service access should be restricted.	Shared admin access should be governed by the customer's privileged-access process.
Operational baseline	Monitoring, backup review, patching, escalation, and ownership should be documented.	Record open items in deployment handover notes.

Responsibility Model

Area	Customer responsibility	Implementation team responsibility
Host provisioning	Provide server, storage, OS baseline, DNS, firewall, and administrative access.	Validate that the host matches the selected deployment model and readiness checklist.
Network and TLS	Provide FQDN, certificate, reverse proxy or TLS termination approach, and firewall approvals.	Confirm DeskDox endpoint configuration and application URL alignment.
Secrets and credentials	Provide or approve secure handling of database, JWT, SMTP, WhatsApp, OpenAI/Emii, and backup keys.	Configure secrets according to the deployment package and avoid recording sensitive values in handover notes.
Backup location	Provide backup target, retention policy, off-host/off-site copy process, and restore owner.	Configure DeskDox backup paths and support initial backup or restore validation where in scope.
User and role readiness	Nominate administrators and define the initial access model.	Support initial admin setup and validation of RBAC-controlled access.
Monitoring and operations	Operate host monitoring, storage alerts, backup review, patching windows, and escalation.	Provide deployment handover notes and known support boundaries.

Support Boundary Statement

DeskDox support covers the application containers, DeskDox configuration, documented deployment scripts, application-level health validation, and product behavior. Customer or infrastructure-provider responsibilities include the host operating system, virtualization platform, Docker runtime installation, DNS, TLS certificate lifecycle, reverse proxy, firewall, storage subsystem, backup media, endpoint security tooling, external SMTP, WhatsApp, OpenAI/Azure/Ollama services, and organization-specific monitoring platforms.

Where an issue crosses these boundaries, joint troubleshooting may be required. Deployment handover notes should record the named customer owner for infrastructure, network, security, database/backup, and application administration.

Final Sizing Disclaimer

Sizing values in this manual are planning baselines. Final production sizing must be confirmed against the customer workload, document retention profile, preview/OCR percentage, workflow volume, search behavior, backup retention, and target RPO/RTO. Large document archives, high OCR usage, strict audit retention, or short restore windows may require larger database, CPU, memory, and storage allocations than a user-count estimate alone suggests.