Operations and Maintenance
DeskDox production operation requires active monitoring, controlled patching, backup review, upgrade planning, and clear support ownership.
Monitoring Areas
| Area | What to monitor |
|---|---|
| CPU | Sustained high usage, spikes during OCR, preview conversion, backups, or search indexing. |
| RAM | Container memory pressure, host memory exhaustion, database memory pressure. |
| Disk | Database volume, uploads, previews, FAISS/index data, backups, logs, and temporary processing capacity. |
| Docker containers | Running state, health status, restart count, failed pulls, image tag drift. |
| Database health | PostgreSQL readiness, connection failures, slow queries, storage growth, backup consistency. |
| Backup success | Schedule execution, archive presence, size trends, retention cleanup, off-host copy status. |
| Preview/index workers | Worker running state, queue growth, conversion failures, OCR errors, stale jobs. |
| Email failures | SMTP connectivity, authentication failures, bounced notifications, wrong public URL links. |
| Integrations | WhatsApp/API errors, OpenAI/Emii failures, rate limits, credential expiry. |
Patch Management
Patch management should cover:
- Host operating system.
- Docker Engine and Compose.
- Reverse proxy or gateway.
- TLS certificate renewal.
- DeskDox images and deploy-kit package.
- Database maintenance and patching if using a separated database tier.
Patching should be performed during approved maintenance windows and preceded by a verified backup.
Upgrade Planning
DeskDox upgrades may include image updates and database migrations. The backend production startup command runs Alembic migrations before starting the API, so upgrade planning must account for:
- Release tag selection.
- Pre-upgrade backup.
- Review of release notes and migration impact.
- Maintenance window.
- Rollback or restore procedure.
- Post-upgrade smoke test.
- Handover note update after validation.
For Windows deploy-kit deployments, upgrade.ps1 is the operational helper. For Linux compose deployments, image tag and compose update procedures must follow the customer change process.
Change Management
Production changes should be recorded for:
- Environment variable updates.
- Image tag changes.
- DNS/TLS changes.
- Firewall changes.
- Backup retention changes.
- SMTP/WhatsApp/AI integration changes.
- Storage expansion.
- Admin and service account changes.
Each change should include owner, approval, execution window, validation steps, and rollback plan.
Log Retention
Docker logging is configured with JSON file rotation in the compose files. The customer should define log retention for host logs, container logs, reverse proxy logs, application audit logs, and integration logs. Where regulatory audit retention is required, database growth must be included in sizing.
Support Handover
The handover package should record:
- Deployment model and host details.
- DeskDox image tag/release.
- Compose file and environment file locations.
- Persistent data paths.
- Public URL and TLS owner.
- Backup path, retention, encryption key custody, and off-host copy owner.
- Admin contacts and escalation path.
- Monitoring dashboards or alert owners.
- Known open items marked
To be confirmed. - Go-live readiness checklist.
Escalation Information
Escalation records should include:
- Customer infrastructure owner.
- Customer application administrator.
- Customer security/network owner.
- Database/backup owner where applicable.
- DeskDox implementation/support contact.
- Severity definitions and response expectations.
- Required diagnostic information for incidents.
Operational Readiness Record
Production handover notes should record:
- Infrastructure baseline.
- Security exposure model.
- Backup and restore posture.
- RPO/RTO.
- Monitoring and operational ownership.
- Known limitations or deferred validation items.
- Go-live validation results.
The record should include the named owner for each operational area and the date the handover notes were last updated.