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 and who supports what.

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, and 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 traffic included, not just what faces the internet.
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. A self-hosted backup is only worth something if you know it restores.

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 for 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.

In-House Database HRM Deployment: A Practical Walkthrough