I am a tax accountant in Japan. I have been working in IT for over forty years — starting from an era when source code was compiled overnight.
Last year I sat down and added up what my small practice was paying for SaaS: cloud storage, document collaboration, AI assistants, calendar, email, remote desktop, monitoring. The number was $163 per user per month. I decided to see whether I could build a self-hosted replacement that I actually understood and controlled.
This is what I ended up with, running in production on real client work every day:
- VPS: Vultr, $24/month, Ubuntu 24.04 LTS
- Access: Cloudflare Zero Trust (free tier) — 2 open ports, no VPN, no exposed SSH
- Cloud + editing: Nextcloud + Collabora Online
- AI: Unified proxy for ChatGPT, Claude, Gemini, Perplexity (~100 lines of Node.js)
- Automation: OpenClaw (≥2026.1.29, patched for CVE-2026-25253)
- Remote desktop: Apache Guacamole through 5 authentication layers
- Monitoring: Prometheus + Grafana + Alertmanager
- Backups: Nightly DB to Supabase + weekly AES-256 encrypted config archive
Total for a 3–8 person team: approximately $35–50/month.
I wrote a five-part guide covering the entire build. Every command, every configuration file, every place where I made a mistake. It is free and will remain so.
A few things I learned that may be useful to others here:
- Cloudflare Tunnel eliminated the need for a VPN entirely. Two ports open, everything else invisible. This was the single biggest simplification.
- The hardest integration was not the AI proxy — it was getting Collabora’s
aliasgroupconfiguration to work correctly with Cloudflare’s TLS termination. - OpenClaw’s CVE-2026-25253 (CVSS 8.8) is a serious concern. The architectural defense — localhost-only binding plus tunnel authentication — neutralizes it structurally, but it should not be deployed without understanding the risk.
- The most underrated component is Supabase as a backup target. PostgreSQL-to-PostgreSQL with zero format conversion.
I would be grateful for any feedback from this community. If you see something I could improve, or a better approach to any part of this stack, I would genuinely like to hear it.
There’s a multitude of reasons any business with critically important data to their customers (lawyer, accountant, etc as you mention) should not roll their own system to save a couple hundred dollars a month…
This is a fair and important challenge, and I do not want to dismiss it.
You are right that for many firms, managed services with professional SLAs, dedicated security teams, and compliance certifications are the responsible choice. A solo practitioner or small firm that lacks the technical capacity to maintain infrastructure should not self-host critical systems simply to save money. The cost saving is real, but it is not the primary argument.
The argument is about control and verifiability.
In my profession, I carry fiduciary liability for client data. When that data resides on a third-party SaaS platform, I am trusting their security architecture — which I cannot audit, cannot verify, and cannot modify. Their terms of service grant them rights over my data that I would never grant to a colleague. When a breach occurs on their side, the regulatory liability still falls on me.
Self-hosting does not eliminate risk. It transfers the responsibility from a vendor I cannot oversee to an architecture I built, documented, and can verify line by line. Whether that trade-off is appropriate depends entirely on the individual’s technical capacity and willingness to maintain what they build.
The guide is explicit about what this requires: a monthly maintenance checklist (13 items, ~30 minutes), an annual review (8 items, ~90 minutes), and a tested emergency runbook for seven failure scenarios. It is also explicit about what it does not provide: there is no vendor to call, no SLA, and no customer support. That responsibility is yours.
I wrote the guide so that the barrier is knowledge, not gatekeeping. But I would never suggest that every firm should self-host. For many, the right answer is a well-chosen managed service. For those with the capacity and the motivation, this is an alternative that exists and works.
Thank you for raising this — it is a point the guide should address more directly, and I will consider adding a “Is this right for you?” section.
And which was designed by and is operated by dedicated teams of professionals.
Which you are not.
Which would you find easier to explain to a judge - that your client data was part of a larger Google breech and attack or that your bespoke home grown system was misconfigured?
Why does this read as if you copied and pasted a LLM response?