ZaffreZaffre Axon
← All articles

In-House Database HRM Deployment — A Practical Walkthrough

Zaffre HRM Team · June 2, 2026

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:

  1. HRM accessible only from the corporate LAN, the corporate VPN, or both.
  2. The database accepts connections only from the application tier — not from end-users, not from the internet.
  3. 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).
  4. All traffic between tiers over TLS — internal too, not just internet-facing.
  5. 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.