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

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.

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.

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.

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. Whether a given tool supports it, and in which edition, is a question for that project's documentation; the Okta page 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.

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.

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 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.

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 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.

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 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 to see how that is meant to work.

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.

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.
• An outage would stop revenue, and nobody is reachable fast enough to prevent it.