In-House Database HRM Deployment — A Practical Walkthrough
If you have decided your HRM has to be self-hosted with the database inside your network, this is what the deployment actually looks like — sizing, network shape, backups, upgrade model, support boundaries.
Architecture overview
A self-hosted Zaffre HRM deployment has three logical tiers:
- Application tier: one or more nodes running the Zaffre HRM API, worker and cron processes. Stateless; horizontally scalable.
- Database tier: MongoDB (replicated for high availability) and Redis (for queues and caching). This is where your data lives.
- Storage tier: a file storage service for employee documents, payslips and reports. Either an internal blob store or a directory on a shared filesystem.
All three tiers are inside your corporate network. The application tier is the only one that gets traffic from end-users; the database and storage are private.
Sizing
Rough sizing per active employee:
- Application nodes: 1 vCPU + 2 GB RAM serves ~250 active employees. For 1000 employees, run 4 application nodes (with load balancing) for fault tolerance.
- Database: 4 vCPU + 16 GB RAM + 200 GB SSD for the first year of a 1000-employee deployment. Storage grows ~50 GB/year per 1000 employees mostly from attendance event logs.
- Redis: 2 vCPU + 4 GB RAM, no persistence needed (queue replay handled at the application layer).
- Storage: ~1–5 MB per employee per year (mostly attendance screenshots if you enable the desktop monitoring agent; payslips and documents are small).
For HA, double the application node count and run the database with at least one secondary replica. Three-node Mongo replica sets are the standard.
Network shape
The minimum acceptable network isolation:
- HRM accessible only from the corporate LAN, the corporate VPN, or both.
- The database accepts connections only from the application tier — not from end-users, not from the internet.
- Outbound internet access from the application tier limited to: SMTP for email delivery, optional FCM/APNs for mobile push, optional SMS gateway, optional license check (configurable).
- All traffic between tiers over TLS — internal too, not just internet-facing.
- Backups encrypted at rest with a customer-owned key.
Stricter setups (defense, banking) air-gap the application tier from the internet entirely; email and SMS go through internal relays.
Backups
Daily encrypted backups to a customer-owned backup target. Recommended retention:
- Daily backups: 30 days rolling
- Weekly backups: 12 weeks rolling
- Monthly backups: 24 months rolling
- Pre-payroll-run snapshot: retained until the next payroll cycle closes
Restore drills should be run quarterly. The whole point of self-hosted backups is that you can actually use them.
Upgrades
Self-hosted deployments do not auto-upgrade. Zaffre Tech publishes a release every ~6–8 weeks with a release-notes document, a database migration runbook and a rollback plan. The customer's IT team picks an upgrade window (typically a weekend) and applies it in a change-managed way.
Skipping releases is supported up to ~12 months — beyond that, the migration cost goes up.
Where Zaffre Tech ends and the customer begins
Self-hosted is a partnership, not a hand-off. Zaffre Tech provides:
- The deployment package (Docker images, infrastructure manifests, configuration templates).
- Sizing guidance.
- Security patches and version upgrades within the support window.
- L2/L3 incident response under a support contract.
- The same product feature set as the cloud SaaS — there is no "downgrade" for self-hosted.
The customer's IT team owns:
- Hardware provisioning, OS patching, network configuration.
- Backup execution and restore drills.
- End-user support (L1).
- Applying upgrades within the support window.
That division of labour is what makes self-hosted economically viable. A vendor that promises full-managed self-hosted is just running a cloud deployment in your data centre at SaaS pricing.
When to choose self-hosted vs cloud
Choose self-hosted if:
- You have a regulatory data-residency requirement (SBP, PDP, KSA PDPL, healthcare PHI, defense).
- You have an internal IT team that already runs on-premise systems and is comfortable with the operational responsibilities.
- Your annual employee count is stable enough that the up-front infrastructure cost amortizes cleanly.
Choose the managed cloud if:
- You do not have a residency requirement.
- You prefer to outsource the operational burden.
- Your headcount is growing fast enough that infrastructure-as-config is more valuable than infrastructure-you-own.
Either way, Zaffre HRM is the same product. Read the use-case page or book a deployment review.