Skip to content

Deployment Overview

SLIM can be deployed in several topologies, from a single local binary to a multi-cluster Kubernetes setup with SPIRE-based mTLS across trust domains. This page helps you choose the right deployment mode for your situation.

Deployment Modes

Mode Use case High availability SPIRE required
Local Single-machine deployments, local agents, quick setups No No
Docker Containerised single-host deployments, CI, portable setups Optional No
Kubernetes: Deployment Cluster-scale deployments, production services Yes Optional
Kubernetes: DaemonSet Node-affine routing — one SLIM pod per node Yes Optional
Kubernetes: Multi-Cluster Cross-cluster agent communication Yes Yes

What Gets Deployed

A SLIM deployment consists of one or more of these components:

  • SLIM Data Plane node — required in all deployments; handles message routing between applications
  • SLIM Controller — optional for single-cluster; required for multi-cluster; manages route tables and node configuration
  • SLIM Channel Manager — optional; required if you want operator-managed group channels
  • SPIRE — optional for single-cluster; required for multi-cluster; provides cryptographic identity and mTLS

SDK applications connect to a SLIM node and communicate over the data plane. They do not connect directly to the Controller or Channel Manager.

Choosing a Mode

Local binary — start with Local when you want a SLIM node running on a single machine with no additional infrastructure. The fastest path is slimctl slim start. Suitable for local agent setups — for example, coding agents or automation tools running on a developer workstation that need to communicate with each other.

Docker — use Docker for containerised single-host deployments or when you want a portable, self-contained SLIM setup. Docker Compose makes it easy to bring up a SLIM node alongside your agent services with a single command.

Kubernetes Deployment — use the Kubernetes Deployment when running agents at cluster scale. Start with the simple pattern for straightforward setups, then add the Controller and SPIRE for production-grade deployments.

Node-affine workloads — use the DaemonSet pattern when application pods should always route through a SLIM pod on the same Kubernetes node. Kubernetes internalTrafficPolicy: Local ensures traffic stays node-local.

Cross-cluster — use the Multi-Cluster deployment when agents on different clusters need to communicate. This requires SPIRE federation between trust domains and either LoadBalancer services or an Ingress for inter-cluster connectivity.