DeskDox

Deployment

Plan DeskDox infrastructure with clear operational ownership

Use this page to evaluate deployment models, reference architecture, service dependencies, typical ports, infrastructure sizing, security hardening, and production readiness.

Deployment overview

DeskDox deployments should be planned around user count, document volume, search/OCR workload, storage growth, security policy, administrator maturity, and required network restrictions.

Reference architecture

A typical production architecture places web traffic behind a reverse proxy, keeps API and database services internal, runs conversion and OCR work through workers, and stores files in managed object or filesystem-backed storage.

Supported deployment models

Single-server deployment for pilots, controlled evaluations, and smaller production environments.
Private cloud or VPS deployment for customer-managed infrastructure with public or private access.
Docker-based deployment for repeatable environment setup and operational portability.
Distributed deployment where web, API, database, storage, conversion, and worker services are separated.
Air-gapped or restricted-network deployment where update, package, AI, and email flows are planned explicitly.
Hybrid AI routing where Emii can be configured around customer policy, connectivity, and data-handling needs.

Core services

  • Frontend web application
  • Backend API service
  • PostgreSQL database
  • Document conversion service
  • OCR and indexing workers
  • Preview and thumbnail workers
  • Object or file storage
  • Reverse proxy and TLS termination

Typical ports

80 / 443Web access through reverse proxy and TLS termination
Frontend internal service portInternal app service behind proxy
Backend API internal service portInternal API traffic from the frontend and workers
5432PostgreSQL internal database access
Gotenberg or conversion service internal portDocument conversion and preview generation
Optional monitoring/admin portsEnvironment-specific monitoring, diagnostics, and administration

Infrastructure sizing

Exact sizing depends on document volume, OCR workload, concurrent users, retention policy, preview generation, and backup strategy. A pilot can usually start smaller, while production environments should reserve capacity for database growth, file storage, and worker queues.

Storage planning

Plan storage for original files, converted previews, thumbnails, OCR output, backups, and retention growth. Storage should be monitored and expandable before production onboarding.

Backup and restore planning

Production readiness requires database backups, file storage backups, restore testing, retention policy, administrator ownership, and a documented recovery procedure.

SMTP and email requirements

Notification delivery, workflow updates, password or account messaging, and support communications require a trusted SMTP relay with appropriate sender identity and delivery monitoring.

DNS and TLS requirements

Use stable DNS names, valid TLS certificates, and reverse proxy rules that route web and API traffic predictably. Certificate renewal should be operationally owned.

AI and Emii deployment options

Emii planning should cover model access, permission-aware retrieval, data routing, restricted-network behavior, and whether AI services are cloud-based, private, or hybrid.

Security hardening checklist

  • Place public traffic behind TLS and a reverse proxy.
  • Restrict database and internal service ports to trusted networks.
  • Use strong administrator accounts and defined operational roles.
  • Confirm backup jobs, restore drills, and retention rules.
  • Review public link policy, workflow governance, and audit review procedures.
  • Monitor storage, database health, conversion queues, and worker capacity.

Pre-deployment and production readiness

  • Confirm users, roles, departments, folders, metadata, and workflow templates.
  • Validate SMTP delivery, DNS, TLS, backup location, and restore procedure.
  • Run sample uploads, OCR, search, preview generation, sharing, and approval flows.
  • Review support handover, administrator training, escalation contacts, and launch communications.