Installation Readiness
Installation readiness confirms that the customer environment, deployment package, security approvals, and operational owners are prepared before DeskDox is installed.
Readiness Principle
DeskDox installation should not begin until the infrastructure owner, network owner, security owner, application administrator, and deployment engineer have confirmed the target deployment model and the required access window. This reduces installation delay caused by missing DNS, firewall, storage, certificate, SMTP, license, or backup information.
Pre-Install Checklist
| Area | Required confirmation |
|---|---|
| Deployment model | Linux Docker Compose, Windows offline installer, VPS/private cloud, or reviewed customer-specific model selected. |
| Host access | Administrative access available for the deployment engineer during the planned window. |
| Docker runtime | Docker Engine/Compose or Windows deploy-kit prerequisites available and tested. |
| Storage | Durable storage provisioned for database, uploads, previews, index data, backups, logs, and temporary processing. |
| DNS | FQDN selected and DNS administration available. |
| TLS | Certificate approach confirmed; certificate and private key handling defined where customer-managed. |
| Firewall | Inbound and outbound firewall decisions completed. |
| Secrets | Production secrets generated or secure generation procedure defined. |
| SMTP | SMTP relay details and test recipient available if email features are in scope. |
| Integrations | WhatsApp, OpenAI/Emii, Azure/OpenAI, Ollama, or other integration keys available if enabled. |
| Backup | Backup path, retention, off-host copy, restore owner, and restore validation approach defined. |
| License | DeskDox license key or activation process available. |
| Admin owner | Named customer administrator available for validation and handover. |
Customer Information Required
| Information | Required for | Notes |
|---|---|---|
| FQDN | Public endpoint, email links, public links, callbacks | Must match the production URL used in configuration. |
| TLS certificate | HTTPS access | Certificate chain and renewal process are customer responsibilities unless separately managed. |
| SMTP host, port, sender, username, password or token | Notifications, password reset, document email | Credentials must be handled as secrets. |
| Backup location | Backup and restore readiness | Prefer storage outside the primary application data path. |
| Admin contact | Initial validation and escalation | Must be available during installation and post-install validation. |
| License key or activation details | Product activation | Online activation settings are environment-specific. |
| Integration keys | WhatsApp, OpenAI/Emii, Azure, or external APIs | Only required if the feature is enabled. |
| DNS access | Public endpoint setup | Required for go-live unless preconfigured. |
| Firewall decisions | Inbound and outbound communication | Must include public endpoint, SMTP, WhatsApp/API, and AI endpoints where applicable. |
Deployment Package Readiness
For Linux compose deployments, confirm:
docker-compose.prod.ymlis available..env.prodhas been created from.env.prod.template.- Image tag policy is agreed through
IMAGE_TAG. - Persistent host paths under
/srv/edms/volumes/...or approved equivalents are provisioned. - Reverse proxy/TLS approach is defined if HTTPS is terminated outside the DeskDox frontend container.
For Windows offline installer deployments, confirm:
- The deploy-kit package is complete.
deploy-kit/config/.envhas been reviewed before first install.- Offline image archives are available if the environment cannot pull from a registry.
- PowerShell execution policy and administrator access allow the deploy-kit scripts to run.
- The Windows service model and Docker runtime support boundary are accepted by the customer.
Image and Tag Readiness
Production deployments should use a deliberate image tag rather than an uncontrolled moving target. The deploy-kit template currently defines IMAGE_TAG=v1.0.56; the root production template uses IMAGE_TAG=latest as a placeholder to be pinned for the target release. The implementation team should confirm the release tag selected for the customer deployment and record it in the handover notes.
Offline Installer Readiness
Offline Windows deployment requires the deployment package to include all container images and scripts needed by the target host. The deployment engineer should validate that image archives load successfully before the installation window where possible. Internet access assumptions must be documented because offline environments may block activation, SMTP, WhatsApp, OpenAI/Emii, and update flows unless explicit allow-lists are approved.
Post-Install Validation Checklist
| Validation area | Expected result |
|---|---|
| Login | Production admin can log in through the approved URL. |
| User access | At least one non-admin user can authenticate and access only permitted areas. |
| Upload | A test document uploads successfully and appears in the correct folder. |
| Preview | PDF and Office preview behavior is validated for representative file types. |
| OCR/search | Search returns expected results after index processing; scanned-document OCR is tested if in scope. |
| Workflow | A representative workflow can be started, actioned, and completed. |
| SMTP test and at least one real notification or document email are delivered if email is in scope. | |
| Backup | Initial backup completes and backup artifacts are visible in the configured location. |
| Restore review | Restore procedure is tested in a non-production environment or a deferred validation plan is recorded in handover notes. |
| Public URL | Email links, public document links, and frontend URL behavior use the production FQDN. |
| Audit logs | Login, upload, admin, and document events are visible in audit/history views where applicable. |
Readiness Output
The readiness workshop should produce deployment handover notes containing:
- Target deployment model.
- Host, storage, DNS, TLS, and firewall decisions.
- Environment variables requiring customer-supplied values.
- Backup/restore expectations and RPO/RTO.
- Named operational owners.
- Support boundaries.
- Open items marked
To be confirmedwith owner and target date.