Windows Offline Installer Deployment

Windows deployment is supported through the DeskDox deploy-kit model and should be treated as a conditional, customer-specific deployment path rather than the preferred enterprise production baseline.

Deployment Position

Use the Windows offline installer model when:

• The customer requires Windows-based server operations.
• The environment is offline or registry access is restricted.
• The customer accepts the Docker runtime, service startup, Windows update, antivirus, and operational support boundaries.
• The implementation team has validated the deploy-kit package against the target host.

Linux remains the preferred production baseline where the customer has no Windows-specific requirement.

Deploy-Kit Components

Windows Compose Baseline

The deploy-kit compose file defines postgres, gotenberg, backend, preview-worker, index-worker, and frontend on an internal Docker bridge network. The frontend publishes ${HOST_BIND_IP:-0.0.0.0}:${HTTP_PORT:-8088}:80, which means network exposure depends on the configured bind IP and firewall rules.

The default deploy-kit configuration uses:

Antivirus and Endpoint Security

Windows endpoint protection must be reviewed before production. The customer security team should approve exclusions or controlled-access rules for:

• DATA_ROOT and its subdirectories.
• PostgreSQL data files.
• Uploaded documents and preview artifacts.
• FAISS/index data.
• Backup output directories.
• Temporary processing paths used during conversion, OCR, backup, and restore.

The goal is to avoid file locks, quarantine, or partial backup corruption while maintaining security monitoring.

Support Boundaries

The implementation team can support DeskDox application configuration, deploy-kit scripts, container startup, application validation, and documented backup/restore workflows. The customer remains responsible for Windows patching, Docker runtime support, host hardening, antivirus policy, Windows service recovery behavior, storage reliability, firewall configuration, certificate lifecycle, and backup media.

Use of Docker Desktop for production should be reviewed carefully with the customer. Licensing, auto-start behavior, resource limits, Windows updates, and interactive-user dependencies must be assessed before production use.

Implementation Notes

Run deploy-kit scripts from an elevated PowerShell session according to the customer change window.

.\scripts\install.ps1
.\scripts\healthcheck.ps1
.\scripts\backup.ps1 -Tag "pre-go-live"

Restore is destructive and overwrites current database and runtime files. It should be tested outside production before go-live. If restore testing is deferred, record the decision and follow-up validation plan in deployment handover notes.

Windows Readiness Checks