Designing, building, and operating a multi-tenant SaaS platform on bare-metal Kubernetes (Tagfalter) 

• First-party production workload ? listed here as engineering experience, not as a third-party reference
  • What this engagement demonstrates for a client: I designed, built, and have continuously operated a multi-tenant WordPress/Nextcloud SaaS on bare-metal Kubernetes as a single engineer ? covering the full stack a regulated client would also need me to cover: IAM, secrets, gateway, TLS, GitOps, automation controller, release pipeline, data isolation, lifecycle management, GDPR erasure/portability, and in-house mail. Every design decision and every production incident listed below is real load on a live platform, not a portfolio artifact.
  • Why WordPress: as a solo operator, building and running the platform substrate ? automation, security, release pipeline, mail, storage, IAM ? is already more than one person's scope; layering a bespoke CMS on top would be irresponsible. WordPress is open source, has an enormous community, receives constant third-party security scrutiny, and ships patches on a predictable cadence. That transparency is a deliberate security choice, not a convenience one. A WooCommerce purchase (handled by my own Woo-Merchants plugin) fires a webhook that triggers a Jenkins pipeline, which runs Anduril ? a declarative site controller I wrote as a ~9,000-line Ansible role composed of 75+ modular tasks. Sites are declared as YAML records (type × status × group) and Anduril reconciles the live infrastructure against that declaration ? similar in spirit to a Kubernetes controller, but operating at the provisioning layer where a controller cannot reach (DNS, gateway TLS, MariaDB users, ArgoCD git repo, Vault).
  • What Anduril does on an active WordPress deployment: creates an isolated Kubernetes namespace, provisions a per-site database on MaxScale with a dedicated 32-character MariaDB user stored in HashiCorp Vault (blast-radius isolation ? one compromised site cannot reach another's data), installs per-site TLS / WordPress salt / Docker registry secrets, updates the nginx gateway and copies TLS material to it, writes a Kustomize overlay into the ArgoCD config repository, and hands off to ArgoCD for the Helm rollout and WordPress initialization. The same role also handles grace-period soft deletes (data preserved, deployment torn down), hard removes (database + Vault credentials + namespace), domain migrations (export / import / wp-cli search-replace / DNS cut-over / source cleanup), TLS-only refreshes, and dry-run validation.
  • Operational maturity: fully idempotent (Vault is checked before credential generation; ArgoCD reconciliation makes partial runs safe); compensating logic for DNS propagation, Let's Encrypt rate limits, and production-observed timing scenarios with compensating error handling; per-site blast-radius containment across namespaces, Vault credentials, MariaDB users, and NetworkPolicies; temp files can be preserved (anduril_cleanup_temp=false) for post-mortem; documented runbooks for every named failure mode.
  • Platform architecture ? deliberately managed, not a constraint: Tagfalter customers do not have WordPress admin access, by design. The automation is the product: updates, security patches, and plugin rollouts are handled centrally, so customers never have to. Customer interaction happens only through the native WordPress Customizer (theme/layout adjustments) and a set of self-written frontend plugins that provide curated content editing ? the WordPress backend is never exposed. Plugin and feature changes ride a three-stage release train: a test branch where new work lands and validation runs (test automation in progress), an integration branch that is an opt-in early-access tier for customers who have explicitly committed to receive features first-hand (a voluntary beta channel with a real customer role), and a production branch that is the stable default for all end users. This keeps the blast radius of any change bounded and gives beta-consenting customers a named place in the release process.
  • Privacy & data handling: all customer data is resident in the EU (self-operated small Tyrolean data center, no US sub-processors in the hosting path); per-site database credentials are generated on demand, stored in HashiCorp Vault, and rotatable; sites are isolated at the Kubernetes namespace and NetworkPolicy layer with dedicated MariaDB users per site; CDN77 is the single named sub-processor for content delivery and is disclosed in the Tagfalter AGB. Transactional and newsletter email is delivered by my own in-house mail stack (Postfix / Dovecot / Amavis / OpenDKIM / OpenDMARC, operated by Rothirsch Tech. GmbH on the same Kubernetes substrate) ? transactional email is delivered entirely via our own EU-resident infrastructure. Mail stays inside EU-resident infrastructure at every hop, which removes an entire class of trans-Atlantic sub-processor exposure that competing managed-WordPress hosts carry. GDPR Article 20 (portability) is handled by a self-written frontend plugin, Tagfalter Data Porter, that lets customers export posts, Customizer settings, WooCommerce products, merchants, events, and media as a WXR bundle importable into any other WordPress instance ? no admin involvement, no ticket, no fee. Article 17 (erasure) is driven by declarative inventory state: cancellation moves a site to grace (pods removed, data preserved, 30-day window); expiry moves it to removed, at which point a daily cron job reaps the Kubernetes namespace, MariaDB database and user, Vault credentials, ArgoCD configuration, and DNS records ? fully idempotent, fully auditable

2020 ? today:
Customer: Rothirsch Tech. GmbH

Tasks:
Scalable Mail Infrastructure on Kubernetes

• A fully containerized, horizontally-scalable mail stack running on my own Kubernetes cluster: Postfix (MSA/MTA), Dovecot (IMAP + LMTP), Amavis (policy orchestration), SpamAssassin, ClamAV, OpenDMARC, OpenDKIM, with central authentication against OpenLDAP. Built as a microservices architecture so each component scales and updates independently; deployed and reconciled via the same GitOps pipeline as every other workload on the substrate
• Why this matters as a compliance differentiator: this stack is not just a back-office service ? it is the mail path for every product Rothirsch Tech. GmbH operates. Tagfalter transactional mail, Community Sites member signups and marketplace order confirmations, newsletter campaigns, password resets, event notifications, and standalone business mailboxes all flow through this infrastructure. No third-party Email Service Provider is involved at any hop. Mail stays inside EU-resident infrastructure from origin to recipient handoff, which removes an entire class of trans-Atlantic sub-processor exposure that virtually all competing managed-WordPress and community-platform vendors carry. For GDPR Article 28 / Article 30 / DPIA purposes, the sub-processor list for lifecycle mail is simply: Rothirsch Tech. GmbH itself. That is rare in the managed-hosting market and is documented as a named compliance advantage in the Tagfalter and Community Sites product documentation

2019 ? today:

Customer: Rothirsch Tech. GmbH

Tasks:
Extending the platform to a second product line: BuddyPress + WooCommerce community marketplace (Community Sites) 

• First-party production workload ? listed here as engineering experience, not as a third-party reference
  • What this engagement demonstrates for a client: given an existing platform substrate, I extended it to carry a second, structurally different product line without rewriting the substrate ? the exact shape of work a client needs when a successful internal platform has to stretch to cover a new use case.
  • The platform: a productized WordPress + BuddyPress + WooCommerce platform for community marketplaces with multi-vendor storefronts, member profiles, activity feeds, event calendars, and local business directories. The product grew out of the 2019 agency build of ilumina-circle com (see the founder section above): after the pandemic collapsed that engagement, I kept the plugin stack I had written, moved it onto my own Kubernetes substrate, and turned it into a repeatable product line. Two deployments currently run on the platform ? both operated by Rothirsch Tech. GmbH ? exercising the same substrate in two very different domains: a regional community and marketplace for Tyrol (members: Tiroler, blog: G'schichtn, marketplace: Mårkt, directory: Locals) and ? a community platform with extended governance rules (deployment stack identical to insa.tirol).
  • Technical shape: single-site WordPress with BuddyPress for member profiles and activity streams; WooCommerce + a self-written Woo-Merchants plugin driving Stripe Connect Express payouts (10% platform fee, min ?1.00, Stripe processing included); a self-written event plugin; and a shared custom theme. Users can author posts, events, and WooCommerce products on the shared site; users who want to sell register a merchant entity via Woo-Merchants and appear in the directory. Marketplace payouts are merchant-direct via Stripe; the platform is not a party to the sale contract. All plugins come from the same in-house portfolio ? the investment made for ilumina-circle in 2019 is still earning returns in production in 2026.
  • Substrate reuse: the platform rides the exact same Anduril + ArgoCD + Helm + Vault + MariaDB/MaxScale + CephFS + Kubernetes stack as Tagfalter. Same declarative inventory (type: community_site, status: active|grace|removed), same grace-period lifecycle (30 days), same daily reconciliation cron, same blast-radius-contained per-site credentials. I did not rewrite the platform for the second product ? I extended the controller's type dimension and reused everything else. That reuse is the actual deliverable: one solo operator maintaining two productized web-services lines on one substrate, with one release pipeline and one operational surface.
  • Privacy & data handling: EU-resident self-operated small data center; Stripe Connect Express (EU-resident) is the single payments sub-processor; CDN77 (EU-headquartered) handles content delivery; spam defence is handled by registration- and MFA-gated comments rather than a third-party content filter. Transactional email, password resets, event notifications, marketplace order confirmations, and newsletter campaigns are all delivered by my own in-house mail stack ? same Postfix/Dovecot/Amavis/OpenDKIM/OpenDMARC substrate referenced in the Tagfalter block above. No third-party ESP touches any Community Sites lifecycle mail. GDPR Article 17 is handled at two scopes (per-member and per-deployment) with named Anduril code paths.

2022 ? 2026:
Customer: mgm technology partners GmbH

Tasks:
Secure Kubernetes Cluster 

• Security-First Kubernetes Cluster Design from Scratch
• Comprehensive security hardening across all layers. Security automation in CI/CD
• Successful production deployment for critical business applications