Build your own Wazuh SOC, or deploy one that's already built

What you have to build

Stock Wazuh gives you a manager, an indexer, and an agent. Everything above that is the project: per-customer managers and indexers, a control plane to provision them, database-level tenant isolation, network policy, agent enrollment plumbing, a triage workflow, and upgrade tooling. Each piece is tractable on its own; integrating all of them, and keeping them integrated as customers arrive, is where the engineering months go. Add an AI triage layer and you also own prompts, tool orchestration against Wazuh and your enrichment sources, guardrails so the model cannot close what it shouldn't, token budgets, and a review workflow around all of it.

SocTalk ships those pieces assembled: one control plane running per-customer Wazuh stacks in isolated Kubernetes namespaces, with the triage pipeline and review queue included. A deterministic funnel of dedup, coalescing, and correlation resolves many alerts before any model call, every escalation goes through human review with no auto-approve mode, and the LLM is yours to choose per tenant, including a fully local Ollama. Everything is Apache 2.0, the chart targets stock Kubernetes 1.30+, and a production install is roughly an hour on a prepared cluster.

Tenant isolation

Multi-tenancy is the design decision to get right early, and on the DIY route it is yours to prove. That means row-level security policies on every tenant-scoped table, tenant identity threaded through every query and dashboard, per-tenant network policy and resource quotas, and a test suite demonstrating that cross-tenant queries actually fail. The provisioning scripts you write for customer three still have to work for customer thirty.

SocTalk enforces FORCE ROW LEVEL SECURITY on every tenant-scoped Postgres table, backed by seven isolation tests that are required to pass in CI. Each customer gets a dedicated Wazuh manager and indexer in its own namespace, with Cilium NetworkPolicy, ResourceQuota, and tenant-scoped agent enrollment secrets. The stack is tested to ~50 tenants on a 3-node cluster; plan roughly 6 to 8 GB of RAM and 1.5 vCPU per persistent tenant.

Onboarding and upgrades

In a homegrown stack, each new customer is a runbook: stand up their Wazuh instance, wire DNS and enrollment secrets, build their dashboards, and connect it all back to whatever central tooling you have written. Upgrades multiply the same way. Wazuh version bumps times the customer count, schema migrations, certificate rotation, and Kubernetes lifecycle add up to recurring engineering time that grows with every tenant.

SocTalk onboards from the control plane. Provisioning runs nine ordered phases with idempotent retry, creating the namespace, quotas, Wazuh stack, and enrollment endpoint, and agents enroll over hostname-routed ingress with tenant-scoped secrets. Per-tenant DNS and load balancer wiring is still manual in V1, and a 'provided' profile connects a Wazuh you already run. Both charts upgrade via helm upgrade with database migrations applied automatically, though fleet-wide upgrades today are a documented manual loop over tenant namespaces; a fleet upgrade API is on the roadmap, not shipped.

What it costs

License fees are zero on both routes. Wazuh is open source, and SocTalk is Apache 2.0 with no community/enterprise split and no feature gates. The difference is where the spend lands. A DIY build costs engineering months up front plus the ongoing time to keep it running, which is a fine trade if the platform is where you want your team. With SocTalk you pay for your own infrastructure and LLM tokens, on the order of $9 a day per tenant at 30 alerts a day on a budget setup, highly variable, or zero per-token cost with a local Ollama.

When building it yourself makes sense

SocTalk assumes a Wazuh data plane. SocTalk's data plane is Wazuh-only today; other SIEMs are feasible additions to its tool surface, but none ship. A Splunk- or Elastic-centered practice is better served by its own integration work.

Build, too, if the SOC platform itself is your product differentiator. Custom correlation logic, a proprietary analyst experience, and workflows your competitors can't copy all argue for owning every layer, and a prebuilt platform would mostly be in your way.

If you're genuinely unsure, the source is at github.com/soctalk/soctalk under Apache 2.0. Read the RLS policies, the network model, and the triage pipeline before deciding. The worst case is that you leave with a working reference architecture for your own build.

What you keep either way

SocTalk runs on your own Kubernetes, from a bare-metal box to EKS, AKS, or GKE, air-gapped if you need it, with your choice of LLM per tenant including a fully local one. Self-hosting is a constant across both routes. You keep your infrastructure and your data, and the customer relationship never routes through a vendor.

It's the DIY stack with the assembly already done, and the license means the ceiling is the same as building it yourself: everything in the repo is Apache 2.0, there's no held-back enterprise tier, and if you ever disagree with where the project is going, you can fork it and keep operating.