Self-hosted HR software — when to go on-prem (and when not to)

The pitch for self-hosted HR software writes itself: "your sensitive employee data stays on your servers, you control updates, no vendor lock-in." Marketing pages everywhere repeat it. Most of it is true. Most of it is also irrelevant for most teams.

This piece tries to be honest about the four scenarios where on-prem deployment of HR software is correct, and the larger number of scenarios where it isn't.

What on-prem actually changes

When you deploy an HR portal on-prem, the practical differences vs cloud SaaS:

Read the table again, slowly. Almost every difference moves work and risk from the vendor to you. The exceptions are "where the data lives" and "when upgrades happen". Everything else is now your problem.

The four cases where on-prem is correct

Case 1: Regulated industry with strict data-locality rules.

If you're in a regulated industry (defense, healthcare in some jurisdictions, banks in others, government contractors) where employee personal data is required by regulation to never leave your perimeter, on-prem is mandatory. There's no SaaS workaround. Pick a portal vendor that ships an on-prem distribution and accept the operational overhead.

This is the most common legitimate reason. It's also the rarest in absolute terms — most companies that think they have data-locality requirements actually have a policy preference, not a regulation. Read the actual law before assuming.

Case 2: Distrust of any third-party SaaS holding employee data.

Some companies make a strategic choice that no third party should hold their HRIS data, full stop. This is a judgment call, not a regulation. The reasoning often includes:

• Risk of vendor bankruptcy / acquisition / data leak.
• Russia, China, and similar jurisdictions where local cloud-data law makes hosting in US-headquartered SaaS legally fraught.
• Internal-policy precedent ("we self-host the wiki, we should self-host this too").

This is a legitimate position, but be honest about it: you're trading vendor-risk for self-managed-infrastructure-risk. The probability of YOUR database being compromised in the next 5 years is non-zero. The vendor's might be lower (they specialize in this). Math out the actual exposure.

Case 3: You're at the scale where SaaS subscription cost exceeds infra+ops cost.

The break-even for HR software is roughly: 500-1000 employees. Below that, SaaS subscription per-seat is usually cheaper than the infra-VM + ops-time + license-fee of self-hosting. Above that, the math can flip.

If you're at 1500+ employees and the per-seat SaaS bill is $20k+/year, the self-hosted license fee + a fractional ops engineer might be cheaper. Math it out for your specific numbers.

Case 4: Air-gapped or near-air-gapped environment.

Some workplaces (some government, some defense, some industrial) have networks that can't reach the public internet — or can only reach it through tightly-controlled gateways. SaaS isn't an option because the portal can't reach back to the vendor.

Self-hosting on a server inside the perimeter is the only option here. Be aware that even self-hosted portals usually need some external connectivity (license verification, security updates) — verify the vendor supports your specific connectivity model.

The cases where on-prem is wrong (most cases)

You think you need data sovereignty but you actually have a policy preference.

If you can't cite the specific regulation that forbids vendor-hosted employee data, you don't have a regulation, you have a preference. Preferences are valid but should be weighed against the real cost of operating infrastructure.

You think you'll save money but haven't done the math.

Self-hosting looks cheap because the license fee is visible. The infra cost (a VM, backups, monitoring), the ops time (an engineer who knows enough to keep it running), the upgrade-window cost (someone has to remember to apply security patches, someone has to be on-call when an upgrade breaks), the support-debt cost (when something goes wrong, you can't escalate to the vendor like a SaaS customer can) — these are all real and usually invisible until they bite.

A 50-person company that self-hosts to "save money" is usually spending 4-8 hours of engineering time per month it could have spent on its actual product, plus 1-2 incidents per year that cost a day each. Compare to the SaaS bill the company is "saving" — it rarely nets out.

You want customization.

Self-hosting doesn't give you customization. The code is the vendor's; you're running their image. The only customization you have is the config knobs they expose. If you want to fork and modify, you need source code access (most on-prem vendors don't give you this), and then you've taken on a maintenance burden the size of the original product.

If real customization matters, the path is "build your own" or "buy the vendor's API and integrate" — not on-prem.

You don't have an ops team and aren't planning to hire one.

If "who handles the server when something goes wrong" doesn't have an answer, on-prem isn't viable. SaaS abstracts this away; on-prem requires someone on call. A "dev who happens to also know Docker" isn't an ops team, especially at 3am.

The middle path: hosted on YOUR cloud

A pattern people sometimes miss: many vendors will deploy their SaaS in your cloud account (your AWS, your Azure, your GCP). You get data-locality (data is in your account) without the operational burden of managing the application yourself (the vendor's pipeline updates it).

This is often the right answer for "we need data sovereignty but don't want ops overhead". Not every vendor offers it; ask.

How DTPulse fits

For context: DTPulse ships in three configurations.

• SaaS at dtpulse.com or dtpulse.ru — what most customers should use. 5-minute signup, vendor-managed everything.
• Self-hosted on-prem — single Docker stack, customer's VM, lifecycle-managed license key with hourly phone-home heartbeat (verifies license validity, no data leaves your install). 15% discount on any tier. For the cases in section 1 above.
• Hosted in your cloud account — case-by-case, contact sales.

We don't push on-prem to anyone whose answer to "why on-prem" is hand-wavy. The honest pitch for a 50-person SaaS-equivalent company is "use SaaS, it's literally cheaper and faster." We only mean the on-prem path for the four scenarios where it's the right answer.

If you're evaluating: read our on-prem docs for the operational shape, then mail [email protected] (or .ru) to discuss your specific scenario.

Related reading

• What is an employee portal — and when does a company really need one
• SAML SSO for SMBs — getting started without an IT department