Published on 12/09/2026
Our business IT: what we host ourselves and why
Many small businesses know their IT only as a collection of logos: one service for files, another password vault, and a server somewhere in the background. When something fails, the number of tools is irrelevant. What matters is who is responsible, where the data sits, and how the system can be restored.
We have therefore divided our own business IT into a small number of deliberate building blocks. We operate much of it ourselves, but not all of it. Self-hosting is not an ideology for us. It is an operating decision that only makes sense when responsibility, maintenance, and recovery are included.
Our system map
This overview shows the real division. It deliberately excludes internal hostnames, access paths, and secrets.
| Purpose | System or service | Operating model | Main responsibility |
|---|---|---|---|
| Files and collaboration | Nextcloud | operated by DevSeal | Accounts, updates, storage, and recovery |
| Passwords | Vaultwarden | operated by DevSeal | Access, updates, and backup |
| Source code and development | Forgejo | operated by DevSeal | Projects, rights, updates, and backup |
| Private network access | Headscale | operated by DevSeal | Device approvals and connectivity |
| HTTPS and routing | Traefik | operated by DevSeal | Certificates, routes, and configuration |
| Website analytics | Umami | operated by DevSeal | Application, updates, and data |
| Public website | Cloudflare | external hosting service | Platform operation at Cloudflare, application at DevSeal |
| Delivery of website emails | Resend | external service | Delivery at Resend, configuration at DevSeal |
This map prevents a convenient but inaccurate claim: we do not host everything ourselves. Our website runs on Cloudflare, and messages from its contact process are delivered through Resend. External services still need an owner, documented settings, and a plan for change.
Why we operate these systems ourselves
For files, passwords, and development, we want to understand the accounts, configuration, and data flows directly. That supports a documented handover and reduces dependence on knowledge held by one person. Open source is a tool in this arrangement, not an automatic guarantee of security or low cost.
Control comes with operating work. Updates need planning, dependencies need checking, and failures need observation. Backups must leave the systems they protect so that a fault or mistake at the source does not also remove the backup. We therefore keep encrypted backups off-host.
Our configuration is reproducible with Ansible, and systemd manages the Docker services. In practical terms, the intended state is described as configuration, and starting a service does not depend on a handwritten note. Automation still does not replace review. A reproducible setup can reproduce a mistake too.
For changes, a short pre-change check is therefore useful. Is the configuration versioned so another person can follow it? Does the change affect stored data or only the service? Is there a route back if startup fails? Afterwards, test a real core function rather than merely checking that a process runs, such as signing in, retrieving a file, or opening a project. This catches applications that are technically running but unusable for their users.
What a restore test actually proves
On 16 July 2026, we destroyed a Nextcloud test instance and restored it from backup. We then verified login, file listing, and download. The test proves that specific process for that test instance at that time.
It does not prove that every possible failure is covered. It is not evidence of a production client rollout, nor does it establish that every one of our workloads has been restored completely. Those limits belong in an honest test record alongside scope, result, open actions, and the next scheduled test.
For a small business, a narrow repeatable test is often more useful than a broad status reading "backup successful". A file platform test might include:
- build a separate test environment from the current backup
- sign in with an intended test account
- locate specified folders and a known sample file
- download and open that file
- record the time required and any differences
- remove the test environment in a controlled manner
What can change over time
On 18 August 2026, we replaced Google Analytics on our own website with an Umami instance we operate. That is a concrete system decision, but not proof that the same choice fits every business. Reporting needs, existing integrations, internal effort, and responsibilities differ.
The useful question is therefore not simply "cloud or own server?" Ask who owns the account, who can administer it, who updates it, where its backup is held, and who can demonstrate a restore. Once those five answers are clear, a set of applications starts to become dependable business IT.
Put those answers in short operating documentation that more than one person can find and understand. For each system, add a business owner, technical owner, and substitute. Review the map after every major change and at least annually. This keeps it a working tool rather than a snapshot. You can draft the first version in 30 minutes: list the five most important tools, add operator and administrator, mark every unknown, then start with the system whose outage would disrupt the working day most.
If you want the same clarity for your systems, our IT infrastructure services cover setup, documented restore tests, and ongoing operations.