Self-Hosting Your Internal Tools: When It Makes Sense and What It Really Costs

Someone on your IT team has found an open-source internal tool platform. It does most of what the subscription product does, the licence is free, and they can have it running on a spare server by Thursday. The pitch is compelling: no per-seat fees, your data stays in-house, nobody can triple the price at renewal.

All of that can be true. But “free to download” and “free to run” are different things, and the gap between them is where most self-hosting decisions go wrong.

What self-hosting actually means

Self-hosting means running the software on infrastructure your organisation controls, either physical servers in your office or virtual servers you rent from a cloud provider. Open-source means the code is published and you’re allowed to use and modify it, usually without a licence fee.

The vendor of a hosted product does a lot of invisible work: keeping the servers running, backing up data, applying security fixes, scaling when you grow. When you self-host, all of that becomes your team’s job. You’re not just a customer anymore. You’re the operator.

When it genuinely makes sense

Self-hosting isn’t a bad idea. It’s a specific idea that fits specific situations.

• Data residency or confidentiality requirements. If contracts or regulations say certain data can’t leave your environment, self-hosting may be the cleanest way to comply.
• You already run servers well. If your IT team already operates databases, patches servers on a schedule and has monitoring in place, adding one more application is incremental, not foundational.
• Large user counts with modest needs. Say 400 staff need read access to an internal directory. Per-seat pricing at that scale adds up, and the operational overhead stays roughly flat as users grow.
• Deep integration with internal systems. If the tool needs to reach databases that sit on your private network, hosting it next to them can be simpler and safer than opening them to the internet.

If none of these apply, a hosted product is usually cheaper once you count people’s time.

The real costs, line by line

Here’s what your IT team will be signing up for. Make sure everyone, including whoever approves budgets, sees this list.

Backups, and proving they work

A backup is a copy of your data stored somewhere separate, so you can recover if something breaks. Taking backups is the easy part. The hard part is knowing they’ll actually restore.

You need automated daily backups (more often if data changes quickly), stored away from the main server, ideally in a different location. You also need a scheduled restore test: someone actually rebuilding the system from a backup into a test environment and checking the data is all there. Quarterly is a sensible minimum. A backup that’s never been restored is a hypothesis, not a backup.

Patching and upgrades

Software needs updates, both security fixes and new versions. With a hosted product, they happen without you noticing. Self-hosted, someone has to read the release notes, test the update, apply it, and roll back if it breaks.

Security patches can’t wait for a convenient quarter. When a serious vulnerability is announced, your team needs to act within days. Major version upgrades are bigger: sometimes they change how data is stored, and skipping a few in a row can turn a routine update into a multi-day project.

There’s also the underlying server, its operating system and the database underneath. Each has its own patch cycle.

Single sign-on and access control

Single sign-on lets staff log in with their existing company account rather than a separate password. It matters because when someone leaves, IT disables one account and all their access goes with it.

Many open-source tools support it, but it takes setup and testing, and some reserve it for a paid edition. Without it, you’re managing separate accounts, and leavers will keep access until someone remembers to remove them. Ask your IT team to confirm it works with your identity system before you commit.

Monitoring

Monitoring means automated checks that tell you when something’s wrong: the app is down, the disk is filling up, backups have stopped running, the security certificate is about to expire. Without it, you find out from an annoyed colleague, or worse, you don’t find out at all until data is lost.

Who gets paged

This is the question that ends most self-hosting conversations, and it should be asked first. If the tool goes down at 7pm on a Friday during month-end close, who fixes it?

If the answer is “one engineer, when they’re available”, be clear-eyed about that. It’s acceptable for a low-stakes tool. It’s not acceptable for a process that stops the business when it’s offline. A proper on-call rota needs at least two or three people who know the system, or you’ve created a new single point of failure, which is exactly what you were escaping.

A rough cost comparison

Use illustrative numbers to frame the discussion. Say a hosted platform would cost a modest per-seat monthly fee for 50 users. Now estimate self-hosting honestly:

Multiply the staff days by a realistic internal day rate. For a small team, self-hosting often costs more than the subscription. For a large one, or one with existing infrastructure, it can cost much less. The point is to do the sum rather than assume “free”.

Questions to settle with your IT team

• Who owns this system, by name and role, and who covers for them?
• What’s the agreed response time if it’s down during working hours, and outside them?
• When was our last successful restore test for a comparable system?
• How will we know if backups silently fail?
• What’s our plan if the open-source project slows down or stops being maintained?

That last one matters. Open-source projects can lose momentum. You’ll still have the code, but security fixes may dry up. The data export questions in “Choosing an Internal Tool Platform: The Questions Vendors Won’t Answer for You” apply here too.

Where to start this week

• Write down the one reason you’re considering self-hosting. If it’s only “it’s free”, run the cost table above first.
• Ask your IT lead who would be on call, and how many people could realistically share it.
• Agree a backup schedule and a date for the first restore test before anything goes live.
• Confirm single sign-on works with your company accounts in a test setup, not just on paper.