// EXPERTISE

Open source we run in production,
not just evaluate.

A stack is not a list of logos. Every tool below is something we have run in production, tuned under real load, and broken in ways that taught us how to run it better. No "we evaluated it in a lab." No certifications without production scars. This is what the principal deploys, operates, and supports.

VIRTMONSECCI/CDBACKUPSTORIaCQUALOSAI/LLMDOCSDATA

Technology stack

The tools below are the ones we default to. Each is open-source-first and chosen because we have run it in production and it earns its place against a proprietary alternative on capability and cost. Where a proprietary tool wins, we use it and we say why. Most of the time it does not.

Virtualization / Compute

Proxmox VEKubernetesQEMU / KVMContainersHA clustersPCI passthroughLive migration

Monitoring

ZabbixGrafanaGraylogZabbix APISLA reportingAlert tuningSNMP / agents

Security / SIEM

WazuhSuricataClamAVZero TrustVulnerability mgmtHARDN baselineAudit logging

Source Control / CI/CD

GiteaGitea ActionsGitRenovateQuality gatesRelease automationTrunk-based

Backup / DR

Proxmox Backup Serverresticrsync3-2-1 strategyOffsite syncSnapshot policiesRestore drills

Storage / Network

CephZFSNFS / CIFSWireGuardVLAN segmentationSite-to-site VPNDDNS

IaC / Automation

OpenTofuAnsibleshellPythonIdempotent playbooksGolden templatesConfig drift control

Code Quality / Supply Chain

SonarQubegovulncheckDependency-TrackSBOMVEX triageCEL policiesPipeline gates

Operating Base

LinuxLXCDockerOPNsensesystemd hardeningCIS benchmarksUnattended upgrades

AI / LLM Operations

LiteLLMA2AMCPPII guardrailsSpend monitoringFallback chainsAgent orchestration

Knowledge / Docs

BookStackOnyxGitea wikisMkDocsRunbooksDecision logsEntity baselines

Databases / Data

PostgreSQLTimescaleDBRedispg_dump automationHypertablesCompressionReplication

Open-source deployments

There is a difference between a tool you have installed once and a tool you have run long enough to know where it breaks. We have run this stack long enough to know. Proxmox clusters under sustained load. Zabbix templates tuned to the alerts that actually fire. Wazuh rulesets that catch the threats that matter to your environment, not the defaults that flood the dashboard. Gitea Actions pipelines that gate releases on real tests, not on a green checkmark.

That operational knowledge is the part that does not show up in a feature list — and we put it in your knowledge base. It is the reason the stack runs reliably when it is operated by someone who knows where it breaks, and why the runbooks, templates, and decision logs are written for your team, not locked in ours.

Industries served

We work where infrastructure downtime has a cost that shows up on a P&L or in a regulator's inbox. The engagements are under NDA — no customer names, no case studies with the identifying details left in. What we can say is the shape of the work.

  • Fintech. Transactional systems where latency and uptime are revenue, and where security and compliance are not optional. Open-source stack hardened to pass the audits that proprietary stacks pass by default.
  • Defense. Environments where the threat model is real and the procurement constraints are strict. Open source wins here on auditability — code you can read, not a binary you have to trust.
  • High-tech manufacturing. Production-adjacent infrastructure where a network outage stops a line. Monitoring and operations tuned to the failure modes that actually cost money.
  • SMB IT. Smaller environments that still need enterprise-grade discipline — virtualization, backup, monitoring, security — without enterprise-grade licensing. The open-source stack fits this profile exactly.

Scale range

The stack scales down to a single Proxmox node with a handful of LXC containers for an SMB, and up to multi-node clusters with hundreds of tracked hosts in Zabbix and CI/CD pipelines running across dozens of repositories in Gitea. The same tools, the same operational discipline, the same principal owning the outcome. The difference between the small deployment and the large one is not a different stack — it is the tuning, the templates, and the runbooks, all of which come from having run both.

If your environment falls inside that range — and most do — the stack below is what we would deploy. If it does not, we will tell you before we start, and point you at the part of the stack that needs to change.

Need a stack that is deployed, not just evaluated?

We take on a small number of selected engagements. If you want the open-source stack run by engineering that has operated it in production, let's talk.