How we deploy a client

When we say “we’ll have you up and running this week,” we mean the technical part is automated and the rest is conversation. Below is what actually happens.

One command, ten phases

Onboarding a new client server runs from a single script in our operations repository. The operator types one command and waits about thirty minutes while the following happens, in order:

1. A new dedicated Hetzner server is provisioned.
2. DNS records for the client domain are added to Cloudflare, both for the server (proxied) and for Fastmail (grey-cloud MX, SPF, DKIM, DMARC).
3. The base OS is updated and hardened: deploy user created, root SSH disabled, password auth disabled.
4. Tailscale is installed and the server joins the Martin Business Consultants tailnet. From this point forward, all admin SSH happens via Tailscale, public port 22 is closed at the firewall.
5. UFW, fail2ban, and unattended security upgrades are configured to documented defaults.
6. Docker is installed.
7. Kamal Proxy boots and takes the public 80/443 ports.
8. Vaultwarden is deployed via Kamal as the first managed application.
9. ONLYOFFICE DocSpace is installed via its official installer, then re-bound to 127.0.0.1:8081 and registered with Kamal Proxy.
10. Restic is configured to back up the relevant volumes hourly to Backblaze B2, with 3-2-1 retention and a systemd timer.

A smoke test then hits every public URL and reports the status codes.

Why this matters

Most managed-services providers describe their setup process as “we’ll get back to you with a timeline.” The reason isn’t laziness, it’s that every setup is bespoke, and bespoke is slow, error-prone, and hard to keep consistent across customers.

We made the opposite trade. Every client gets the same baseline. The deploy script is the source of truth for that baseline. The result is:

• Speed. New clients are functional infrastructure in under an hour, not weeks.
• Consistency. Client #1 and client #50 get the same security posture, the same backup configuration, the same patch cadence. We don’t carry tribal knowledge about which client we forgot to harden.
• Auditability. When a client asks “what exactly happens during onboarding?” the answer is “here’s the script.” We’ve published the playbook to ourselves so we can publish it to you.

What still needs a human

We’re honest about the seams. The script gets the technical infrastructure to 90%. The remaining 10% needs human judgment:

• Fastmail mailbox creation, provisioning individual user mailboxes in the Fastmail admin (no API on Fastmail’s standard plans).
• First admin user setup in ONLYOFFICE and Vaultwarden. These accounts represent real people on the client side and we don’t auto-create them.
• End-to-end smoke testing as a real user, clicking through the actual flows from a fresh browser, ideally with someone from the client team alongside.
• Conversation about defaults, naming, branding, who has access to what, what hours someone is on-call. None of these are technical questions.

These aren’t gaps. They’re the parts of the work that should be done by a human looking at the specifics of the client. The technical baseline is automated so we can spend our time on the things that actually need judgment.