Thank you for taking the time to read this carefully and push back. Several of your points are fair, and I want to address them honestly.

“Written by OpenClaw”

It was not. But I understand why the prose style raised that question. I am a non-native English speaker who writes carefully — which can sometimes read as overly polished. I will take that as a signal to write more conversationally in future posts.

“All open-source” is overstated

You are right, and I should not have used that framing. The infrastructure layer is open-source (Nextcloud, Collabora, Guacamole, Prometheus, Grafana). The AI providers are proprietary commercial APIs — and they do send bills. Cloudflare’s free tier is proprietary. The accounting integrations are proprietary SaaS. I should have written “open-source infrastructure with commercial API integrations” rather than implying everything is open-source. That is a fair correction.

Security layers

I understand the skepticism. You are correct that UFW alone blocks inbound traffic. The rationale for listing eight layers is defense-in-depth — each addresses a different failure mode, not the same one. Cloudflare Access handles identity (OTP). The tunnel eliminates port exposure entirely. UFW is the fallback if the tunnel fails. fail2ban handles brute force against SSH (which is key-only but still targeted). sysctl hardens the kernel network stack. They are not eight firewalls — they are eight different controls at different points in the path. Whether you count them as “layers” or “controls” is a fair debate, and I respect the pushback on the framing.

Guacamole / RDP

The guide targets small professional firms (accountants, lawyers) where staff have Windows desktops at the office with licensed software that cannot be moved to the cloud — QuickBooks Desktop, industry-specific applications, licensed design tools. Guacamole lets them operate those machines from home through a browser without exposing RDP to the internet. For a purely cloud-native team, it is unnecessary.

Backups

This is the point I want to take most seriously. The guide includes three backup mechanisms: nightly PostgreSQL dump to Supabase (offsite, different provider), weekly AES-256 encrypted full config archive (local + offsite), and Nextcloud’s own file versioning. The 2-hour restore procedure is documented and tested.

That said — you are right that the post does not mention the 3-2-1 rule explicitly, and it should. The architecture functionally follows 3-2-1 (three copies, two media types, one offsite), but I did not frame it that way. I will update the guide to make this explicit. Thank you for raising it.

I appreciate the scrutiny. This is exactly the kind of feedback that makes the guide better. If you see other areas that need correction, I am genuinely interested.

I’m glad it smelled as suspect to someone else.

Its threads like this that make me glad that these people are running around making infinite work for me to be doing, fixing the messes these people are making.

Alas, noody wants to pay for the work to be done

The world is full of clowns and I don’t want to be in their circus any more

Thank you for this recommendation — Mistral is a name I should have included in my evaluation, and I appreciate you raising it.

The GDPR compliance and the availability of self-hostable models are both significant advantages, particularly for professionals handling client data under strict regulatory obligations. The proxy architecture is designed to be provider-agnostic — adding Mistral (or any provider with a chat completions API) would require fewer than 20 lines of code. So this is genuinely practical advice, not just theoretical.

Your point about hallucination behavior is also interesting. In tax and legal work, a model that says “I don’t know” is far more valuable than one that sounds confident while being wrong. I will test Le Chat against my usual evaluation prompts and see how it performs.

I cannot speak to Japanese language performance yet, but I will report back if I try it. Thank you again — this is exactly the kind of suggestion I was hoping for when I posted here.

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.