When an Invoice Disappears into the Inbox: Why Infrastructure and Security Belong Together
Situation description: An invoice is overdue, nobody followed up, reminders are created too late and replies get lost in the general e‑mail chaos. For medium‑sized companies this is everyday life — and avoidable. A structured, on‑prem open‑items workflow reduces manual effort and preserves data sovereignty. For such a workflow to run reliably in production, coordinated hardware/VM sizing, clear firewall rules, reliable backups and regular recovery tests are required.
Overview: Core Components of the Checklist
- Resource planning: VM and hardware sizing according to edition and transaction volume
- Network & firewall: minimal openings, segments and admin access
- Backup strategy: intervals, retention, offsite copy
- Encryption & key management
- Recovery tests & monitoring
Why this Fits Debentra
Debentra runs as a self‑hosted solution on your own infrastructure. Depending on the edition (BASIS, PRO, PREMIUM) the resource requirements change: PRO automates parts of assignment and background jobs, PREMIUM integrates additional accounting functions. The following checklist helps to provide the appropriate infrastructure without relinquishing automation control: reminder templates and sending always remain approvable by users.
1. Hardware / VM Sizing (practical per edition)
Recommendations serve as a starting point for typical medium‑sized setups. Adjust the values based on your daily invoice/customer volumes.
BASIS (small setup, low throughput)
- Single VM or small server: 2 vCPU, 4 GB RAM
- Storage: 50–100 GB SSD (prefer NVMe), RAID1 for redundancy
- DB: local in the same VM possible; for performance safety a separate DB VM is recommended later
- RTO/RPO target (recommendation): RTO ~24 h, RPO ~24 h
PRO (medium setup, background jobs & automation)
- App VM: 4 vCPU, 8 GB RAM
- DB VM: 2–4 vCPU, 8 GB RAM; separate storage pool (200 GB SSD)
- Storage: NVMe for DB (IOPS important), RAID10 for performance + redundancy
- Worker nodes: an additional small worker (2 vCPU, 4 GB RAM) for background tasks is recommended
- RTO/RPO target: RTO ~8 h, RPO ~1 h
PREMIUM (larger setups, integrated accounting, higher availability)
- App VMs (cluster-capable): 2× 4–8 vCPU, 16 GB RAM (load-balanced)
- DB cluster: 2–3 nodes with 4 vCPU each, 8–16 GB RAM; dedicated NVMe storage (500 GB+)
- Backup server / archive: separate VM or NAS with high capacity and encryption
- RTO/RPO target: RTO ~4 h, RPO ≤15–30 min (WAL‑shipping / continuous replication)
2. Network & Firewall Rules
Minimal principle: only necessary ports open, segment services (DMZ, application network, database network), restrict admin access to trusted IPs.
Recommended Rules
- Port 443/tcp (HTTPS): Allow from Internet to load-balancer / reverse proxy
- Port 80/tcp: Allow from Internet only for redirect to 443
- SSH (22/tcp): Allow only from admin IPs or VPN (no general exposure)
- DB ports (e.g., 5432/tcp for PostgreSQL): Allow only from application network / specific app VMs
- Backup transfer: Restrict to TLS/SSH-based connections (rsync/ssh or SFTP) and allowed backup servers
- Internal communication: Microsegmentation between app and worker/DB; use stateful firewall or security groups
Further Notes
Establish a management VLAN for admin access and monitoring. Disable unnecessary services on production servers and run regular port scans.
3. Backup Strategy & Intervals
Backups are not just copies — they are a process. Define schedules, test runs and responsibilities.
BASIC
- Full backup: daily (night)
- Incremental snapshots: daily or hourly depending on load
- Retention: 14–30 days
- Offsite copy: at least weekly (encrypted)
PRO
- Full backup: daily
- Increments: hourly for DB, daily snapshots for application
- Transactional backup: WAL backup or similar to restore to minutes
- Retention: 30 days + weekly offsite snapshots
PREMIUM
- Continuous replication (WAL‑shipping / streaming replication)
- Daily full backups + hourly differential backups
- Retention: 90 days for regular backups, long-term archive as needed
- Offsite & encrypted copies: daily transfer to an external location
4. Encryption & Key Management
Encryption must be considered end-to-end: in transit, at-rest and for backups.
- TLS: HTTPS with TLS 1.2+ (preferably TLS 1.3), enable HSTS, automatically renew certificates (e.g. ACME/LetsEncrypt or internal PKI)
- At‑Rest: Full‑disk encryption (LUKS) at VM level or encrypted LVM volumes; database storage additionally on encrypted storage
- Backups: Encrypt with AES‑256; manage keys separately from backups
- Key Management: Use a central KMS (e.g. HashiCorp Vault or an internal enterprise KMS). Avoid locally stored plaintext keys.
5. Recovery Tests, Monitoring & Operations
Backups that have never been tested are worthless. Monitoring resolves issues before dunning runs get stuck.
Recovery Tests
- BASIC: Quarterly full restore test (document the procedure)
- PRO: Monthly restore drill for the database + spot checks of application recovery
- PREMIUM: Weekly restore tests on staging, simulate load and failover
Monitoring & Alerts
- Monitor: Service health, DB latency, disk I/O, backup jobs, replication lag
- Alerts: Report backup failures immediately to responsible parties; warnings for disk usage ≥75%
- Audit Logs: Log access and reminder approvals (for transparency in the follow‑up process)
Practical Example: How a Production Setup Runs
A mid‑sized company runs Debentra PRO. The architecture: load balancer → app VM (4 vCPU/8 GB) → DB VM (2 vCPU/8 GB) → backup server (offsite encrypted copies). Firewall permits 443, 22 only from the admin VPN, 5432 only from the application network. Nightly full backup, hourly DB increments, monthly recovery test. Reminder templates are prepared automatically; users decide on approval and sending – keeping control with the team.
Implementation Tips and Common Mistakes
- Mistake: Exposing the DB port publicly. Consequence: unnecessary attack surface. Solution: allow only internal communication.
- Mistake: Backups on site without an offsite copy. Solution: plan daily encrypted offsite copies.
- Mistake: No recovery tests. Solution: regular, documented restore drills with assigned responsibilities.
- Mistake: Automation without an approval process. Solution: implement automated drafts plus manual approval of dunning notices.
Conclusion and Next Steps
A stable, secure operation of Debentra on‑prem requires predictable infrastructure, limited network openings, a well‑thought backup strategy and regular recovery tests. Choose the edition matching your volume and availability requirements: BASIS for simple setups, PRO when automation and background processing are important, PREMIUM for higher availability and integrated accounting features. In all cases, control over dunning approvals remains with the user.
Act now: Check your current architecture against this checklist and choose the appropriate edition. Choose edition
Next step
Try Debentra yourself
Central overview and process control for open items and payments with full data sovereignty; reduces manual reconciliation work (PRO) and enables integrated accounting (PREMIUM); selectable installation and licensing models.