Platform Requirements and Infrastructure Sizing
DeskDox sizing must be driven by workload, data growth, and recovery objectives. Named user count alone is not sufficient for production infrastructure planning.
Preferred Production Baseline
Linux is the preferred production baseline for DeskDox EDMS. The root production compose file uses Linux-style persistent paths under /srv/edms/volumes/..., loopback-bound internal service ports, and Docker Compose service health checks. This model is the primary baseline for enterprise production deployments, VPS deployments, private-cloud VMs, and customer-managed Linux hosts.
Windows deployment is available through the deploy-kit offline installer model and should be treated as a customer-specific or conditional deployment path. It is appropriate where the customer has a Windows operational standard, a controlled offline installation requirement, or a site-specific support agreement.
Runtime Requirements
| Area | Requirement |
|---|---|
| Container runtime | Docker Engine with Docker Compose v2, or an approved equivalent runtime that supports the supplied Compose files. |
| Database | PostgreSQL 16 in the supplied production Compose baseline. |
| Frontend runtime | NGINX serving the built React application in the frontend container. |
| Backend runtime | Python/FastAPI application served by Uvicorn in the backend container. |
| Converter | Gotenberg 8 container for conversion and preview workflows. |
| Persistent paths | Database, uploads, previews, FAISS/index data, backups, and licensing paths must be durable. |
| Browser | DeskDox is intended for current enterprise-supported versions of Microsoft Edge, Google Chrome, Mozilla Firefox, and Safari. Internet Explorer is not supported. |
Linux Considerations
For Linux production hosts:
- Provision persistent storage before installation.
- Restrict host access to approved administrators.
- Confirm Docker service startup after reboot.
- Review SELinux or AppArmor policy interactions with mounted paths and Docker access.
- Restrict file permissions on environment files and backup paths.
- Use a customer-approved reverse proxy or network edge for TLS when HTTPS is not terminated by upstream infrastructure.
SELinux/AppArmor behavior depends on the distribution and customer hardening profile. If enforced policies block Docker volume access, the customer security team must approve the required labeling or profile adjustment.
Windows Considerations
The Windows deploy-kit path uses:
deploy-kit/compose/docker-compose.production.yml.deploy-kit/config/.envcopied to.envon first install.DATA_ROOT=C:/ProgramData/DeskDoxby default.HTTP_PORT=8088by default, with automatic port selection support in installer tooling.- PowerShell scripts for install, start, stop, restart, health check, backup, restore, upgrade, reconfigure, and uninstall.
Antivirus and endpoint detection tooling should exclude the approved DeskDox data root, Docker storage paths, and temporary processing paths from destructive quarantine behavior. Exclusions must be approved by the customer security team; they should not disable monitoring, but they should prevent document, database, backup, and index files from being locked or modified during runtime operations.
Docker Desktop on Windows is not the preferred enterprise server baseline. Use of Docker Desktop in production must be explicitly accepted by the customer, including licensing, service startup, Windows update, resource allocation, and operational support implications. Where possible, Windows Server deployments should use the customer-approved container runtime model validated during implementation.
Service Account Expectations
DeskDox should be operated by named administrative users or approved service accounts. Service accounts should:
- Have only the host and Docker privileges required for the deployment model.
- Be controlled by the customer identity and privileged-access process.
- Be excluded from personal user offboarding risk.
- Have credential rotation and ownership documented in handover.
Sizing Inputs
Sizing must include the following inputs:
| Sizing input | Planning impact |
|---|---|
| Concurrent users | Drives API, database, frontend, and session workload. |
| Document ingestion volume | Drives storage growth, indexing, preview jobs, and backup size. |
| Average file size | Drives upload limits, storage, backup windows, and network throughput. |
| OCR percentage | Drives CPU, memory, and index-worker workload. |
| Preview generation workload | Drives Gotenberg and preview-worker capacity. |
| Workflow volume | Drives database writes, notifications, task queues, and audit logs. |
| Audit retention | Drives database growth and reporting performance. |
| Backup retention | Drives backup storage and off-host copy requirements. |
| RPO/RTO expectations | Drive backup frequency, restore design, and standby infrastructure needs. |
Planning Sizing Table
The following values are planning baselines only and must be validated against customer workload.
| Profile | Application baseline | Database/storage baseline | Typical use case |
|---|---|---|---|
| Pilot / demo | 2-4 vCPU, 4-8 GB RAM | 100-200 GB usable, SSD-backed | Demonstrations, limited UAT, low document volume, short retention. |
| Small production | 4 vCPU, 8-16 GB RAM | 250-500 GB usable plus backup storage | Department deployment, moderate concurrent use, controlled OCR. |
| Medium production | 8 vCPU, 16-32 GB RAM | 1-2 TB usable plus backup/off-site retention | Multi-department production, regular OCR, workflow and audit growth. |
| Large production | 12+ vCPU, 32+ GB RAM | 2 TB+ usable, sized by retention and RPO/RTO | Enterprise or government deployment with high ingestion, long retention, stricter recovery targets. |
For medium and large deployments, review whether the database, backup destination, or storage layer should be sized separately from the application host.
Application, Database, and Storage Split
| Layer | Main sizing driver | Planning guidance |
|---|---|---|
| Application and workers | Concurrent users, OCR, previews, workflow activity | Scale CPU and memory for conversion and indexing peaks, not only login volume. |
| PostgreSQL | Metadata, workflow, audit, and job history growth | Use SSD-backed storage and include audit retention in database growth planning. |
| Document storage | Original files, previews, index data, backups, and logs | Size for retention, backup copies, off-host replication, and processing headroom. |
Storage Sizing Method
Estimate production storage by adding:
- Original document repository size.
- Preview artifacts.
- Search, OCR, and FAISS/index data.
- PostgreSQL data and WAL/maintenance overhead.
- Backup retention footprint.
- Log retention.
- Temporary processing allowance.
- Growth reserve approved by the customer.
| Storage category | Include in plan | Notes |
|---|---|---|
| Original documents | Yes | Primary document repository and highest recovery priority after the database. |
| Preview artifacts | Yes | May be regenerable, but rebuild time can affect operations. |
| FAISS/index data | Yes | Can be rebuilt in some cases, but OCR and indexing time must be planned. |
| Database | Yes | Use database-aware backup or dump procedures. |
| Backups | Yes | Store outside the primary application volume where possible. |
| Logs and temporary processing | Yes | Keep enough space for diagnostics, conversion, OCR, and backup activity. |
Backup storage should normally be outside the primary application volume and replicated off-host or off-site according to the customer recovery policy.
Final Sizing Caveat
Final sizing is subject to validation. Deployment handover notes should state the expected workload, agreed sizing, growth assumptions, restore expectations, and the review date for capacity revalidation.