Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Self-hosting internal tools vs SaaS: what it really costs When running your own Git, chat, password manager or analytics beats paying per seat, when it does not, and how to count the hours that never show on an…
A team of twenty-five reviews its card statement and finds fourteen separate tool subscriptions. Chat, Git hosting, a wiki, a password manager, uptime checks, product analytics, a form builder, a diagram tool. Each one was a sensible decision on the day. Together they cost real money every month, and the per-seat ones go up every time someone joins. Someone suggests running the open-source versions on a server instead.
Short answer: self-hosting beats SaaS for an internal tool when the subscription grows with headcount, the open-source option is mature, the data is sensitive or bulky, and someone owns updates, backups and access. Keep paying for SaaS when the tool is business-critical, needs high availability, or nobody has time to run it properly.
We build and run self-hosted setups with Docker, Dokploy, Tailscale and MinIO, and we still recommend SaaS for plenty of tools. This guide is about deciding tool by tool, not picking a side.
What you are actually buying with a subscription A SaaS price is not only for the software. Most of it pays for operations you would otherwise do yourself:
Updates and security patches, applied without you noticing. Backups, and someone else's responsibility for restoring them. Availability across zones, and an on-call team when it breaks at night. Email delivery, mobile apps, push notifications and integrations that just work. Single sign-on, audit logs and admin controls, often on a higher tier. Vendor paperwork such as security questionnaires and data processing agreements. Self-hosting removes the subscription but hands every item on that list back to you. The question is never "is open source cheaper than SaaS". It is "is our time running this cheaper than their price for running it".
Tools that usually self-host well Some categories have open-source projects that are mature, light on resources and forgiving if they go down for an hour. These are where we see self-hosting pay off most often:
Uptime and status checks: Uptime Kuma is a single container with a simple UI. Run it outside your main infrastructure, or it goes down with the thing it is watching. Web analytics: Umami and Plausible Community Edition give privacy-friendly page analytics and keep visitor data on servers you control. Workflow automation: n8n self-hosted removes per-execution pricing, which matters once you run thousands of workflows a month. Read its Sustainable Use License first: internal use is fine, offering it to your own customers may not be. Object storage for internal files: an S3-compatible store such as MinIO, Garage or SeaweedFS, when you hold large volumes and outbound transfer fees add up. MinIO's community edition has been scaled back recently, so check its current licence and release status before you commit. Dashboards and BI on your own database: Metabase or Grafana, close to the data, without exporting it to a third party. Staging and preview environments: a platform such as Dokploy or Coolify on one VPS often replaces several hosted app plans. What these share: the data is either already yours or not regulated, outages are inconvenient rather than costly, and upgrades are usually a new image tag.
Tools we usually leave as SaaS Other categories look simple until you run them. We advise most small and mid-sized teams to keep paying for these:
Email: deliverability, spam reputation and abuse handling are a full-time job. Self-hosted mail servers are the classic regret. Primary identity and single sign-on: if Keycloak or Authentik goes down, every tool behind it goes with it. Self-host it only with a second instance and someone who understands it well. Chat as the main incident channel: if your Mattermost or Rocket.Chat server is on the same infrastructure as production, you lose your communication exactly when you need it. Password management for the whole company, unless you are prepared to treat it like production. Vaultwarden is a solid, lightweight server, but a lost database without a tested backup means lost credentials. Anything customer-facing with uptime commitments, such as support desks or status pages your clients rely on. Git hosting sits in the middle. Gitea and Forgejo are light and reliable, and they suit teams with data-residency or air-gapped needs. But hosted Git also gives you CI minutes, security scanning and a familiar workflow for contractors. If you self-host Git, plan where CI runners live before you move the repositories.
Counting the real cost The comparison people make is subscription versus server rent. The comparison that matters includes people's time. A simple worksheet we use, filled in per tool:
SaaS per year = seats x monthly price per seat x 12
+ extra for the tier with SSO / audit logs
Self-hosted per year = server + storage + off-site backup
+ loaded hourly cost x (
setup hours / 3 (spread over ~3 years)
+ upkeep hours per month x 12
+ expected incident hours per year )A made-up example, in whatever currency you pay in. Sixty users on a tool at 8 a seat per month is 5,760 a year. Self-hosting it on a shared server at 50 a month costs 600, plus about 52 hours of staff time a year (24 setup hours spread over three years, 3 upkeep hours a month, 8 incident hours) at 40 an hour, which is 2,080. Total: 2,680, so self-hosting wins. At ten users the subscription is 960 and the self-hosted cost barely moves, so SaaS wins clearly.
Be honest about upkeep. A well-run self-hosted tool needs version upgrades, OS patches, certificate renewals, backup checks and the occasional broken migration. A few hours a month per tool is realistic once it is stable; the first quarter is usually more. Several tools on one shared platform cost far less each than one tool on its own server, because patching, monitoring and backups are set up once.
Two patterns tip the numbers strongly. Per-seat pricing at fifty or more users, where the tool itself is light, almost always favours self-hosting. A single paid feature you need, such as SSO, sitting on an enterprise tier can also change the answer overnight. The reverse is just as common: a five-person team self-hosting a tool that costs little per seat is paying engineer hours to save very little.
Running self-hosted tools properly If you decide to self-host, the failures we see are rarely about the software. They are about the absence of a routine. The minimum we put in place for any internal tool:
Pin image versions instead of using latest, and upgrade deliberately after reading the release notes. Keep tools off the public internet where possible. A private network such as Tailscale, plus SSO or strong passwords with two-factor authentication, removes most of the attack surface. Back up both the database and any uploaded files, copy them off the server, and test a restore at least once a quarter. Monitor from outside the server so you hear about outages before your colleagues do. Write a one-page runbook per tool: where it runs, how to upgrade it, how to restore it, who owns it. Keep an exit path: know how to export your data back to a SaaS product if self-hosting stops making sense. A nightly backup for a typical Compose-based tool with a PostgreSQL database can be this simple. Adjust names to your stack and send the output to S3-compatible storage on a different machine:
#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/var/backups/wiki
mkdir -p "$DEST"
# database dump from the running container
docker compose -f /opt/wiki/compose.yaml exec -T db \
pg_dump -U wiki -Fc wiki > "$DEST/wiki-$STAMP.dump"
# uploaded files
tar -czf "$DEST/uploads-$STAMP.tar.gz" -C /opt/wiki data/uploads
# copy off the server, keep 30 days locally
rclone copy "$DEST" offsite:backups/wiki
find "$DEST" -type f -mtime +30 -deleteRestore it into a scratch container with pg_restore before you trust it. A backup that has never been restored is a hope, not a backup.
A decision checklist, tool by tool Go through your subscriptions one at a time. Self-hosting is worth a closer look when most of these are true:
The cost grows with headcount or usage, and you expect both to grow. A mature open-source project exists, with regular releases and a clear upgrade path. An hour of downtime would be annoying, not expensive. The data is sensitive, large, or needs to stay in a particular country. A named person or partner owns updates, backups and access, with time set aside for it. You already run, or plan to run, a shared platform so the tool is not a one-off server. If fewer than four are true, keep the subscription and revisit in a year. If you are planning to move several tools at once, start with one low-risk tool such as uptime checks or analytics, run it for a couple of months, and measure the hours it actually took. That number is the most useful input to every decision that follows. If nobody in the team can own the platform, get help setting it up and running it, or stay on SaaS until someone can.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789