---
title: "How to run self-hosted software safely at a small company"
description: "The operating checklist for running self-hosted software at a small company: backups, restore tests, updates, access, exposure, monitoring, when to quit."
canonical: "https://lopifi.com/savings/how-to/run-self-hosted-software-safely"
---

# How to run self-hosted software safely at a small company

> The operating checklist for running self-hosted software at a small company: backups, restore tests, updates, access, exposure, monitoring, when to quit.

Source: https://lopifi.com/savings/how-to/run-self-hosted-software-safely
Part of: Lopifi — US GAAP books on autopilot, checked by a CPA (https://lopifi.com)

---

Series: Move and replace. Reviewed 2026-10-25.

Deciding to self-host is the easy part; the [self-hosting math guide](https://lopifi.com/md/savings/how-to/self-hosting-honest-math) covers whether it pays. This guide is what comes after yes: a short list of habits that keep a tool you run yourself from becoming the thing that loses your data or lets someone in. It covers backups and restore tests, updates, who can sign in, whether to put it on the internet, how you find out it is down, where the secrets live, who answers the alert, and when to stop. Lopifi plans to run this for customers once the service opens; today it is not open and there is no uptime commitment, so treat everything below as work you or a hired person does.

## Run your numbers

- [Self-hosting vs SaaS cost](https://lopifi.com/md/tools/selfhost-cost): The honest yearly cost of running open-source software yourself, set against the bill it replaces, with the seat count where it stops paying.

## Write the one-page runbook first

Before the tool holds real data, write a single page and keep it somewhere that does not depend on the tool. It is the document the next person opens at an awkward hour, and writing it is how you find out what you do not know.

- What the tool is, what company data it holds and who uses it.
- Where it runs, how it is reached, and which domain name points at it.
- Who the primary and backup owner are, by name.
- Where the backups go, how often, and the date of the last successful restore test.
- Where the secrets are kept and who can read them.
- How to apply an update, and how to roll back.
- The exit plan: how to export the data in a format another tool can read.

## Backups and restore tests

Start with what has to be in the backup, because a copy of the wrong folder looks fine until the day you need it. The project's own documentation says what that is. Nextcloud's manual lists five things to retain: the config folder, the custom apps folder (only if you have custom apps), the data folder, the theme folder and the database. Vaultwarden's wiki marks its database and its `attachments` directory as required, and `config.json` and the `rsa_key*` files as recommended. It also warns that `config.json` holds some plaintext sensitive data and that the key files should be encrypted if they go to cloud storage, so the backup itself needs protecting.

For a database that is being written to, use the project's own backup method rather than copying the live file. Vaultwarden's wiki shows the SQLite `.backup` command and, since version 1.32.1, a built-in `/vaultwarden backup` command; in Docker that is `docker exec -it vaultwarden /vaultwarden backup`. Nextcloud's manual describes maintenance mode, which locks the sessions of logged-in users and prevents new logins to help avoid inconsistent data, and gives `sudo -E -u www-data php occ maintenance:mode --on` to turn it on. Set it back when you finish.

Keep a copy somewhere that does not share a failure with the server: another provider, another account, credentials that the server itself cannot use to delete it. That part is our advice, not a quotation from any source. If you use restic, its documentation shows how to check the repository: `restic check` verifies the structure, the `--read-data` flag also verifies the integrity of the pack files, and `--read-data-subset` checks a part at a time. The docs warn that `--read-data` downloads all pack files, so it can raise bandwidth costs.

Checking a repository is not the same as restoring from it. The restore test is the real one.

1. **Pick a date and a clean place.** Use a scratch machine or folder, never the production server. Put the date on the calendar every quarter and assign it to a person.
2. **Restore from the offsite copy.** With restic the docs show `restic -r /srv/restic-repo --no-cache restore c23e491f --target /tmp/restore-work`; replace the repository path, snapshot ID and target with yours. Whatever tool you use, restore from the copy that lives elsewhere, not the one next to the server.
3. **Open the data like a user would.** Start the tool against the restored copy, sign in, and open a few records you know. For a file tool that is a real folder and a real document. For a password vault it is an item you can read.
4. **Time it and write it down.** Record how long it took and what was missing or confusing. Fix the runbook. The time it took is the real answer to "how long are we down if the server dies".

## Updates and patching

Self-hosted software does not update itself on your schedule; you are the vendor's operations team. NIST's patching guide describes enterprise patch management as the process of identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades, and frames it as preventive maintenance: a cost of doing business. You do not need an enterprise program, but you need all five verbs, and you need to do them on a rhythm.

Read the project's upgrade page before the first update, not during an incident. Nextcloud's says to maintain regular backups and make a fresh one before every upgrade, and that the upgrade must go step by step: you reach the latest point release of your current major version before the next major one, and you cannot skip major releases. It also tells you to review third-party apps for compatibility first. Projects differ, so find the equivalent rules for yours and put them in the runbook.

To decide what cannot wait for the monthly window, CISA maintains a catalog of vulnerabilities that have been exploited in the wild and says organizations should use it as an input to their vulnerability management prioritization. Check whether your software or the software under it (the operating system, the web server, the container runtime) appears there. This guide does not tell you which fixes matter; the project's announcements and that catalog do.

- Pin the version you run and write it in the runbook, so "what are we on" is never a guess.
- Take a backup, confirm it exists, then update. In that order.
- Update a copy first if the tool is important enough to have one.
- After the update, open the tool, check one real record and look at the logs.
- Do not let a tool fall several major versions behind; with step-by-step upgrades the catch-up is slow and risky.

## Access: single sign-on and two-factor

Every self-hosted tool is one more login. The simplest control is the one CISA starts with: multifactor authentication on admin accounts and on people who handle sensitive data, extended to systems like email, file storage and remote access. CISA ranks the methods: security keys give the best protection against phishing, number-matching app prompts are strong, and text or email codes are the weakest and a last resort, though any MFA is better than none.

Single sign-on is attractive because removing a person in one place removes their access everywhere, which is the point of the [offboarding guide](https://lopifi.com/md/savings/how-to/offboard-saas-accounts). Whether a given tool supports it, and in which edition, is a question for that project's documentation; the [Okta page](https://lopifi.com/savings/okta) covers what replacing a paid identity provider involves. If a tool cannot use your sign-in system, put it on the offboarding checklist by name so it is not forgotten.

- Give each person their own account. No shared admin login.
- Turn on MFA for every admin account on day one, then for everyone.
- Keep one break-glass admin account with its credentials stored offline and sealed, and test it once a year.
- Remove access the day someone leaves, and list this tool on the exit checklist.

## Expose it to the internet, or not

The question is not whether the tool is secure; it is who needs to reach it. If only your team uses it, it does not need a public address. Keep it on a private network or behind a connection your team already uses, and the number of people who can even attempt a login drops from everyone on earth to the people you gave access to. That is our recommendation and reasoning, not a quoted rule.

Some tools have to be public, because customers or outside contacts use them. In that case serve them over HTTPS, keep their admin pages away from the public, and keep the software current, since a public tool is the one that gets probed. Vaultwarden's wiki says it is heavily recommended to activate HTTPS before enabling its admin page, to avoid possible man-in-the-middle attacks. Uptime Kuma's README shows binding its port to `127.0.0.1:3001:3001` to limit access to localhost, a small example of publishing only what you meant to.

- Write down every public address and what is behind it. If you cannot list them, you cannot patch them.
- Publish the smallest piece: the sharing page, not the admin console.
- Put the admin interface on the private side wherever the tool allows it.
- Re-check after every update that a port or setting did not change.

## Monitoring and uptime

You want to hear about a problem before a customer or a colleague tells you. Uptime Kuma is one open-source option: its README lists monitor types including HTTP(s), TCP, ping, DNS record, push and Docker containers, notifications through channels such as email, Slack, Telegram and Discord, and 20-second check intervals. The README gives a `docker run` command that publishes port 3001 with a named volume for its data.

Two rules matter more than the tool. First, run the monitor somewhere other than the server it watches, or it goes down with it. Second, monitor the thing that matters: a page that returns 200 can still be serving an error, so check for a keyword on a real page, and add a push or heartbeat check for the backup job so that a backup that silently stops raises an alert. If you would rather not run a monitor at all, the [Pingdom page](https://lopifi.com/savings/pingdom) covers the paid uptime-check job and its alternatives.

- Check the public address from outside your network.
- Alert on the backup job not running, not only on the app being down.
- Watch disk space on the server and the backup target; a full disk stops both.
- Send alerts to a channel that a named person actually reads.

## Secrets: passwords, tokens and keys

OWASP's cheat sheet is clear on the habits. Secrets should be rotated regularly so that stolen credentials only work for a short time; rotation is better automated than done by hand; each secret should have the minimum privileges for its use; secrets should never be logged, and should not be hardcoded using Docker `ENV` or `ARG`; environment variables are not recommended unless the other methods are not possible; and auditing is essential. For a small company that means a team password manager, not a spreadsheet and not a chat thread. The [LastPass page](https://lopifi.com/savings/lastpass) covers the job of a team vault if you have not chosen one.

Take the admin interface seriously too. Vaultwarden's wiki says its `ADMIN_TOKEN` acts as the admin password, should be a long random string, and can be stored as an argon2id hash so it cannot simply be read out of the configuration. It also says that disabling the token gives unrestricted access to the admin panel, which it warns against unless you know what you are doing.

- One owner and one backup owner for every credential the tool uses, written in the runbook by name.
- Never keep the keys to the backup only on the server being backed up.
- Rotate on a schedule and whenever someone with access leaves.
- Search your repositories and chat for pasted keys before you assume none were leaked.

## Who is on call

Self-hosting fails most often at the human layer. The tool is fine until the one person who understands it is on vacation, busy or gone. Name a primary and a backup. Agree what counts as an emergency (the tool is down during working hours, the backup has failed twice, a security update is overdue) and what can wait until Monday. Make sure the backup person has actually logged in and read the runbook, not only been told where it is.

Be honest about hours. A founder who answers the alert is paying with time that is not free, which is why the [self-hosting math guide](https://lopifi.com/md/savings/how-to/self-hosting-honest-math) counts it. Lopifi plans to take this on for customers once the service opens. There is no service and no SLA today, so the person who answers is you or someone you hire. Read [how we get paid](https://lopifi.com/md/savings/how-to/how-we-get-paid) to see how that is meant to work.

## The weekly, monthly and quarterly checklist

Put these on the calendar with a name next to each. The cadence is our suggestion, sized for a small team and a handful of tools. The tasks come from the sections above.

- Weekly: confirm the last backup ran and the monitor and its alerts are working; glance at disk space; read any security announcement from the projects you run.
- Weekly: look at who signed in as admin and whether anything unfamiliar appears.
- Monthly: take a backup, then apply updates in your chosen window and check a real record afterward; check the vulnerability catalog for the software you run; review the list of accounts against current staff.
- Monthly: run the repository check your backup tool provides, for example `restic check`.
- Quarterly: do a full restore test into a clean place, time it and update the runbook.
- Quarterly: review public addresses and open ports, rotate secrets, and confirm both the primary and the backup owner can still sign in.
- Yearly: test the break-glass admin account, rehearse the exit export, and re-run the cost math against what the work actually took.

## When to stop self-hosting

Stopping is not failure; it is the outcome of the same math that told you to start. Several signals mean the arrangement has stopped paying.

- The person who understands the tool has left and no one has taken over.
- Updates are being skipped for more than a cycle or two, or the tool is several major versions behind.
- A restore test has failed twice, or has not been done at all this year.
- The tool now holds data you are contractually or legally required to protect, and you cannot show the protection.
- The hours spent keep exceeding the license fee you saved; see the [self-hosting math guide](https://lopifi.com/md/savings/how-to/self-hosting-honest-math).
- An outage would stop revenue, and nobody is reachable fast enough to prevent it.

1. **Export first.** Take a full export in a format another tool can read and confirm it opens. The exit plan in the runbook is for this day.
2. **Choose the landing place.** A paid plan of the same product, a different product, or a managed service. The [consolidation guide](https://lopifi.com/md/savings/how-to/consolidate-into-one-suite) and the [software spend audit checklist](https://lopifi.com/md/savings/how-to/software-spend-audit-checklist) help you compare.
3. **Run both for a month.** Keep the self-hosted copy read-only while the new one does real work, then shut down. Delete credentials, DNS records and backups according to your retention needs, and remove it from the vendor list in your [vendor register](https://lopifi.com/md/savings/how-to/vendor-register-and-renewal-calendar).

## Common questions

### How do I know my backups work?

Restore it, on a schedule, into a place that is not production, and check that the data you care about is there. A backup that has never been restored is an assumption. The restic documentation includes a `check` command for the repository and a `restore` command, and Nextcloud's manual says to keep regular backups and take a fresh one before every upgrade.

### How often should I update self-hosted software?

Set a fixed review time, read the project's release notes, back up first and apply updates in a window you chose. NIST's patching guide frames patching as preventive maintenance and recommends an organization-wide strategy for it, and CISA publishes a catalog of vulnerabilities known to be exploited that you can use to decide what cannot wait.

### Should a self-hosted tool be reachable from the internet?

Not unless you have to. The safer default is to keep it off the public internet and reach it through a connection your team already trusts, such as a VPN you already run, and to expose only what an outside person genuinely needs. If you do publish it, serve it over HTTPS and protect every admin page. Vaultwarden's wiki, for one, says to activate HTTPS before enabling its admin page.

### Do we need two-factor authentication on internal tools?

Yes, on every admin account first. CISA says to start with admin accounts and people who handle sensitive data, then extend MFA to systems such as email, file storage and remote access, and prefers phishing-resistant methods such as security keys over text or email codes.

### Who should be on call for a tool we host?

Two named people, one primary and one backup, each of whom knows where the runbook and the credentials are. An uptime alert that nobody is responsible for answering is a log entry. If neither person can be named, that is a result of the cost math in the [self-hosting math guide](https://lopifi.com/md/savings/how-to/self-hosting-honest-math), not an inconvenience.

### When should we stop self-hosting?

Stop when the person who understands it is gone and not replaced, when updates are being skipped, when a restore test fails twice, or when the tool holds data you cannot afford to lose and cannot protect. Export your data, move to a paid plan or another product, and follow [cancelling without penalties](https://lopifi.com/md/savings/how-to/cancel-without-penalties) for anything you still pay for.

### Does Lopifi run this for us?

Lopifi plans to run open-source replacements for customers, but the service is not open yet and nothing here is a promise of an uptime level or a result. Until it opens, this checklist is for you or whoever you hire. The [free audit](https://lopifi.com/savings/audit) runs in your browser and shows which of your subscriptions are candidates at all.

## Sources

- [restic docs: Working with repositories](https://restic.readthedocs.io/en/stable/045_working_with_repos.html) (read 2026-10-25)
- [Vaultwarden wiki: Backing up your vault](https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault) (read 2026-10-25)
- [Vaultwarden wiki: Enabling admin page](https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page) (read 2026-10-25)
- [Nextcloud admin manual: Backup](https://docs.nextcloud.com/server/latest/admin_manual/maintenance/backup.html) (read 2026-10-25)
- [Nextcloud admin manual: Upgrade](https://docs.nextcloud.com/server/latest/admin_manual/maintenance/upgrade.html) (read 2026-10-25)
- [Uptime Kuma README](https://github.com/louislam/uptime-kuma) (read 2026-10-25)
- [CISA: Require Multifactor Authentication](https://www.cisa.gov/require-multifactor-authentication) (read 2026-10-25)
- [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) (read 2026-10-25)
- [NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final) (read 2026-10-25)
- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) (read 2026-10-25)

## Keep going

- [The honest math of self-hosting](https://lopifi.com/md/savings/how-to/self-hosting-honest-math): A formula for the real yearly cost of running open-source software yourself, a worked sample, and when you should not self-host.
- [Open-source licenses for founders](https://lopifi.com/md/savings/how-to/open-source-licenses): MIT, Apache, MPL, GPL and AGPL in plain English for founders who run open-source software instead of paying a license, and what each asks you to do.
- [Offboarding SaaS accounts](https://lopifi.com/md/savings/how-to/offboard-saas-accounts): Remove a leaver's seats, shared logins and SSO access in order, keep their data with an owner, and put the freed licenses to work or cancel them.
- [Dropbox migration, in depth](https://lopifi.com/md/savings/how-to/dropbox-migration): A start-to-finish plan for leaving Dropbox: inventory, destination, pilot, copy and verify, shared links, cutover, cancellation and how the books treat it.
- [Run the free audit](https://lopifi.com/savings/audit)
- [All how-to guides](https://lopifi.com/md/savings/how-to)

*General information, not tax, legal or accounting advice.*