Skip to main content

Deployment Models

Feature row 46 — Sprints W / W.1 / W.2

All four deployment models are supported on every plan. Enterprise tenants can mix and match.

The four options​

Behavry supports four deployment models, trading managed convenience for data locality and operational control.

ModelControl planeData planeWho runs it
SaaSBehavry-hostedBehavry-hostedBehavry
HybridBehavry-hostedCustomer-managedMixed
BYOC (Bring Your Own Cloud)Customer-managed in customer cloudCustomer-managed in customer cloudCustomer (Behavry supported)
On-PremCustomer-managed on customer infraCustomer-managed on customer infraCustomer

"Control plane" means policies, configuration, dashboards, and audit visibility. "Data plane" means the proxy that sits inline on agent traffic and the audit store that holds Decision Trace rows.

When to pick which​

SaaS​

  • Pick when: you want to get value fast and you don't have strict data residency requirements
  • You get: instant provisioning, managed upgrades, 24/7 monitoring
  • You give up: you're sending agent traffic metadata to a third party

Hybrid​

  • Pick when: you want the managed dashboard and policy authoring UX, but your audit log and proxy traffic can't leave your environment
  • You get: SaaS dashboard + your data stays local. Policy changes sync from the control plane via an OPA bundle + JWKS.
  • You give up: you run the data plane (stateful: proxy + Postgres + TimescaleDB)

BYOC​

  • Pick when: you want everything under your own cloud account — including the control plane — but you want Behavry to run the day-to-day operations
  • You get: Full Behavry stack inside your AWS / GCP / Azure account, with Behavry staff as operators via a narrow cross-account IAM role
  • You give up: provisioning overhead and some velocity; upgrades happen on your change-window cadence

On-Prem​

  • Pick when: air-gapped or regulated environments where no connection to Behavry infra is acceptable
  • You get: Full control, full isolation. Helm chart for Kubernetes or Docker Compose for smaller footprints.
  • You give up: upgrade cadence is entirely on you; you deploy signed container images from a local registry

Shared architecture​

All four models run the same backend container (backend/ → docker build). What changes is:

  • Which pieces are hosted where
  • How the control plane and data plane authenticate to each other (JWKS + signed OPA bundles)
  • Where the audit log is written

Control plane / data plane split (Hybrid / BYOC)​

In Hybrid mode:

  • Control plane runs BEHAVRY_MODE=control_plane and exposes the admin UI, policy API, and bundle endpoint
  • Data plane runs BEHAVRY_MODE=data_plane and polls the control plane for policy bundles on a schedule (default 30s)
  • Identity is bridged via JWKS — the data plane verifies control-plane tokens against a public key it fetches once

Audit events stay on the data plane. The control plane can issue a forensic pull to retrieve specific traces on demand (with admin approval).

Images & packaging​

  • Container images are published to a signed registry with cosign signatures and SBOMs
  • Helm chart at charts/behavry/ for Kubernetes
  • Terraform ECS Fargate module at terraform/aws-ecs/ for BYOC on AWS
  • Docker Compose at docker/docker-compose.yml for single-host SaaS-lite / on-prem deployments