BYOC (Self-Hosted) Deployment

Causely can run entirely inside your own cloud account or data center. In a bring your own cloud (BYOC) deployment, also called self-hosted or on-premises, both the mediation layer and the Causely backend (causal engine, API, UI and MCP server) run on infrastructure you control. Nothing is sent to Causely.

This page explains what a BYOC deployment includes, what infrastructure it requires, and how data flows. It is not an installation guide.

Deploying Causely in your environment

To deploy Causely as BYOC, contact your Causely support representative. They will provide deployment instructions, the Helm chart, and access to the container images.

BYOC compared with Causely-hosted

The mediation layer always runs in your environment. The difference between the two models is where the backend runs and whether anything leaves your network.

	Causely-hosted (SaaS)	BYOC (self-hosted)
Mediation layer (mediator, agents, local metrics store)	Your environment	Your environment
Causely backend (causal engine, API, UI)	Causely-managed infrastructure	Your cloud account or data center
MCP server for AI agents	Causely-hosted endpoint (api.causely.app/mcp)	Part of the API service, served from your own portal endpoint
What leaves your environment	An abstract representation of your environment and targeted evidence. See What leaves your environment.	Nothing. All traffic stays within your network.
Outbound connections to Causely	Mediator connects to the Causely backend over outbound TLS	None. There is no license check, phone-home, or update channel to Causely.
Causely's own health telemetry	Sent to Causely for support by default. Can be turned off.	If turned on, sent only to your self-hosted backend. Can be turned off.
User authentication	You configure single sign-on (SSO) with any identity provider over OpenID Connect or SAML from the admin portal. See Single Sign-On (SSO).	Optional OIDC through your identity provider (for example Microsoft Entra ID, Okta, or Keycloak)
Updates	Causely updates and manages the backend. You manage and upgrade the mediation layer (mediator and agents).	You manage and upgrade both the backend and the mediation layer, pulling new versions from Causely's registry or your private mirror on your own schedule
Encryption	Managed by Causely. See Encryption.	Governed by your own infrastructure and policies
LLM usage	Not used for causal inference. See LLM usage.	None by default. Optional features use your own LLM provider.

Architecture

A BYOC deployment uses the same components as the Causely-hosted system. The mediation layer is deployed next to your workloads, one mediator per cluster or environment, exactly as described in Architecture and Mediator Details. The backend runs in a Kubernetes cluster you operate and is reached through two endpoints on a domain you choose:

• gw.<your-domain>: the gateway that receives data from your mediators.
• portal.<your-domain>: the UI, API and MCP server for users and AI agents.

Backend components

The backend is installed with a single Helm chart and includes the following services:

Component	Role
Gateway	Receives topology, symptom states and evidence from your mediators
Analysis	Runs the causal engine that builds the causal graph and infers root causes. Includes a machine learning sidecar.
API	Serves the Causely API, including the MCP server for AI agents
UI	Serves the Causely portal
Background	Runs scheduled and asynchronous jobs
Image generation	Renders metric charts and dependency graphs as images
Database migrations	Kubernetes job that applies database schema changes during installs and upgrades
Copilot controller (optional)	Generates LLM-based diagnosis summaries using your own AI gateway. Disabled by default.

Supporting infrastructure

You provide or install the following alongside the backend:

• Ingress controller, such as NGINX Ingress, to expose the gw. and portal. endpoints. We recommend an internal-only load balancer that users and mediators can reach over your private network.
• cert-manager to provision and renew TLS certificates.
• PostgreSQL, the primary data store for configuration, analysis results and system metadata.
• Redis or Valkey, used by the API, Gateway and Analysis services for caching and coordination.

Resource requirements

Requirement	Specification
Kubernetes cluster for the backend	At least 3 nodes, each with 4 vCPU and 16 GB RAM
Tooling	Helm 3.x and kubectl with access to the cluster
DNS	Two records under one base domain: portal.<your-domain> and gw.<your-domain>
TLS	Certificates for both endpoints, typically issued by cert-manager
Network	Mediators must reach the gw. endpoint. Users and AI agents must reach the portal. endpoint.
Container images	Access to Causely's container registry with credentials from Causely, or a private registry where you mirror the Causely backend, mediation and supporting open source images
PostgreSQL	A managed PostgreSQL instance (see Managed services)
Redis	A managed Redis or Valkey instance (see Managed services)
Identity provider (optional)	An OIDC provider to protect access to the portal and API

These requirements cover the backend. Mediation layer resources depend on the size of each monitored environment. See Sizing the Mediator for large environments and Sizing VictoriaMetrics for high-volume environments.

Managed services

For production BYOC deployments, we recommend running PostgreSQL and Redis as managed services from your cloud provider or database team rather than inside the Kubernetes cluster. Managed services provide backups, high availability and operational support that in-cluster databases do not. In-cluster PostgreSQL and Redis are supported only for evaluation and other non-production environments.

PostgreSQL

• Supported services include Amazon RDS and Aurora, Google Cloud SQL, Azure Database for PostgreSQL, or an equivalent offering.
• The pg_stat_statements and uuid-ossp extensions are required. They are installed automatically if the database user can create extensions. Otherwise, your DBA must install them.
• A non-default schema is supported.
• On Amazon RDS and Aurora, Causely can authenticate with IAM database authentication instead of a password.

Redis

• Supported services include Amazon ElastiCache, Google Memorystore, Azure Cache for Redis, or any Redis-compatible (Redis or Valkey) service.
• TLS connections are supported.
• On Amazon ElastiCache, including serverless caches, Causely can authenticate with IAM instead of a password.

Data and network flows

In a BYOC deployment, every Causely component runs within your network boundary:

• Mediators send an abstract representation of your environment and targeted evidence to your own backend over TLS. The content is the same as described in What leaves your environment, but it never leaves your network.
• The backend does not connect to Causely for licensing, authorization, updates or telemetry.
• Causely's own health telemetry, if turned on, is sent only to your self-hosted backend.
• User and API access can be protected with OIDC through your own identity provider.
• The MCP server is served from your own portal. endpoint. When you connect AI agents, the agent integration instructions in your portal point to that endpoint.

LLM usage

Causely does not use LLMs for topology discovery, symptom detection, causal inference or diagnosis. These are performed by Causely's causal reasoning engine.

In the default BYOC deployment, Causely sends no input to and receives no output from any LLM. Two optional capabilities let you bring LLMs in under your own control:

• LLM-based diagnosis summaries. The optional Copilot controller generates log summaries and descriptions for each diagnosis. It uses an AI gateway and model that you configure.
• AI agents through MCP. You can connect your own agents, such as Claude Code, Cursor or a custom agent, to the MCP server in your deployment.

In both cases, data flows directly between your deployment and the LLM provider you choose, under your own agreement with that provider. It does not pass through Causely.

Getting started

Contact your Causely support representative to plan a BYOC deployment. They will provide deployment instructions, the Helm chart, registry credentials, and guidance on sizing for your environment.

For more on permissions and data handling in the mediation layer, see Security.