Self-hosted HR software: what it actually involves
What running HR software on your own infrastructure really takes: the requirements, the ongoing work, and when self-hosting is the wrong answer.
"Self-hosted" gets used loosely enough that it is worth being precise. It means the software runs on a machine your organization controls, connected to a database your organization controls, and no copy of your data sits on a vendor's servers because the vendor has no servers in the path.
That is the whole idea. What follows is what it costs you, in work rather than money.
What you actually need
For a modern self-hosted HR system, the shopping list is short:
- A Linux server. One virtual machine is enough. Two vCPUs and 4 GB of RAM comfortably handles a few hundred employees — HR software is not computationally demanding, because a few hundred people generate a few hundred rows a day.
- PostgreSQL 14 or newer. Managed (RDS, Cloud SQL, DigitalOcean) or self-run. Managed costs more and removes most of the database work; both are fine.
- A domain and a TLS certificate. Whatever reverse proxy you already use. Let's Encrypt if you have no preference.
- Optionally, an email provider for invitations and password resets, and object storage for employee photos and documents.
If your organization already runs any internal web application, you have all of this. If it does not, the honest answer is that you are learning to run a server as well as adopting HR software, and you should count that.
What the ongoing work actually is
This is the part vendors of hosted software describe as enormous and vendors of self-hosted software describe as trivial. Neither is right.
Backups. Everything that matters is in PostgreSQL. If you already back up a Postgres database, this is covered by the same job. If you do not, set up pg_dump on a schedule and — this is the part people skip — restore one into a scratch database once a quarter. An untested backup is a belief, not a backup.
Updates. New releases arrive when they arrive; you apply them when it suits you. That is genuinely an advantage over hosted software, which updates on the vendor's schedule regardless of whether you are mid-payroll. It is also a responsibility: security patches do not install themselves, and an installation nobody has updated in two years is a liability.
Monitoring. Something should tell you when it is down. This can be a proper monitoring stack; it can equally be a free uptime checker pinging a health endpoint. The failure mode you are guarding against is finding out from an employee who could not clock in.
Realistically this is a few hours a month, concentrated around upgrades. It is not a job. It is also not nothing.
The parts that are genuinely better
Your data is in your database. Not exportable on request — actually yours. You can query it, join it against your finance system, back it up to your own storage, and keep it under your own retention policy. For anyone with data residency obligations this is often the deciding factor, and no amount of vendor assurance substitutes for it.
The cost stops. A perpetual licence is a fixed number. Per-seat subscriptions scale with headcount, which means the bill grows precisely as you succeed.
You can change it. If the licence includes source code, an approval chain that matches your actual org chart is a development task rather than a feature request that gets declined. This matters more in organizations whose processes are unusual — and most organizations think their processes are usual right up until they try to fit them into someone else's software.
No vendor failure mode. If the company behind your hosted HR system is acquired, changes pricing, or shuts down, you have a migration. If the company behind your self-hosted system does the same, you have software that keeps running exactly as it did yesterday.
When self-hosting is the wrong answer
It is worth being clear about this, because the answer is not always yes.
You have nobody technical. If there is genuinely no one who can maintain a server, and no budget to pay someone to, a hosted product is the right call. Software that nobody can patch is worse than software you rent.
You need it running this afternoon. Self-hosting has a setup step. Hosted products do not. If the constraint is time rather than money, that matters.
You are five people. At very small scale the per-seat maths favours subscriptions and the operational overhead is disproportionate. Come back at twenty-five.
Your compliance regime requires a certified processor. Some contracts and some sectors require specific certifications from the entity processing the data. Self-hosting makes you that entity. Usually that is what you want. Occasionally it is not what the contract says.
A note on what self-hosting does not solve
Self-hosting puts your employee data on infrastructure you control. It does not, by itself, make you compliant with anything.
GDPR, and its equivalents elsewhere, govern how personal data is collected, what you tell people about it, how long you keep it, and how you respond when someone asks for a copy. Those are obligations on your organization regardless of where the server sits. Self-hosting removes the transfer question and the sub-processor question. It leaves every other question exactly where it was.
Anyone selling you self-hosted software as "GDPR compliance" is overstating it. What it gives you is control, and control is a precondition for compliance rather than a substitute.
The practical test
If you are weighing this up, one question separates the cases better than any feature comparison:
Where would you rather the difficult conversation happen?
With hosted software, the difficult conversation is with a vendor: about price rises, about an export, about where exactly the data sits, about a feature you need that is not on their roadmap.
With self-hosted software, the difficult conversation is internal: about who patches the server, about whether the backups have been tested, about finding time for the upgrade.
Neither is free. But one of them you can schedule.
Ace HR runs on a single Linux host with your own PostgreSQL database. The requirements and deployment steps are here, and installation is available as a paid add-on if you would rather not.