> ## Documentation Index
> Fetch the complete documentation index at: https://docs.svantic.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Deployment models
# Deployment Models
Svantic supports three deployment topologies, each designed for different organizational needs — from a developer's laptop to a globally distributed enterprise fleet.
***
## 1. Standalone
**One machine. One Svantic. One or more applications.**
The simplest deployment: Svantic runs as a local server, and applications on the same machine (or network) register as agents.
**When to use:**
* Local development and testing
* Single-team workloads
* Prototyping and demos
* Small-scale production (single server)
**Setup:**
```bash theme={null}
# Start Svantic
cd agents && npm run api
# Start your app (registers with Svantic automatically)
SAVANT_AGENTS_URL=http://localhost:3000 node my-app.js
```
**Characteristics:**
* Zero infrastructure overhead
* Knowledge persists locally
* All capabilities on one machine
* No network latency between components
***
## 2. Sidecar
**One pod. One Svantic sidecar. One application. Fully autonomous.**
Svantic runs as a sidecar container alongside your application in a Kubernetes pod. Each pod gets its own AI brain. The sidecar operates independently — it can plan, execute, and learn even when disconnected from any central infrastructure.
**When to use:**
* Distributed scraping fleets (e.g., 50 scraper workers, each with its own AI)
* Microservices that need autonomous AI capabilities
* Edge deployments where connectivity is unreliable
* Teams that want isolation — one service, one brain, no shared state
**Setup (Docker Compose):**
```yaml theme={null}
services:
savant:
image: savant:latest
ports: ["3000:3000"]
environment:
- LLM_API_KEY=${LLM_API_KEY}
my-service:
image: my-service:latest
ports: ["4100:4100"]
environment:
- SAVANT_AGENTS_URL=http://savant:3000
depends_on:
- savant
```
**Setup (Kubernetes):**
```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
name: scraper-worker
spec:
containers:
- name: savant
image: savant:latest
ports: [{ containerPort: 3000 }]
env:
- name: LLM_API_KEY
valueFrom:
secretKeyRef: { name: savant-secrets, key: api-key }
- name: scraper
image: transcript-link:latest
ports: [{ containerPort: 4100 }]
env:
- name: SAVANT_AGENTS_URL
value: "http://localhost:3000"
```
**Characteristics:**
* Full autonomy — works without any central coordination
* Knowledge is local to each pod
* No cross-pod knowledge sharing (unless Central is added)
* Horizontal scaling: more pods = more capacity
* Each pod is self-contained and independently recoverable
***
## 3. Central + Sidecar (Hub Mesh)
**One central brain. Many sidecar arms. Shared knowledge. Distributed execution.**
A central Svantic instance acts as the hub — it holds the shared knowledge store, the agent registry, and coordinates across all sidecars. Each sidecar registers with central, inherits shared knowledge, and operates autonomously for local tasks.
**When to use:**
* Enterprise deployments with multiple teams and services
* Fleets where cross-instance learning is valuable
* When you want centralized monitoring and agent management
* When different services need to compose capabilities across pods
**Setup:**
Central Svantic:
```bash theme={null}
SAVANT_BASE_URL=http://central-savant:3000 \
SAVANT_PORT=3000 \
npm run api
```
Sidecar Svantic (each pod):
```bash theme={null}
SAVANT_BASE_URL=http://localhost:3000 \
SAVANT_PORT=3000 \
SAVANT_CENTRAL_URL=http://central-savant:3000 \
npm run api
```
The `SAVANT_CENTRAL_URL` variable tells the sidecar to register with central on startup. Knowledge flows upward.
**Registration hierarchy:**
1. Your application registers with its local sidecar Svantic
2. The sidecar registers itself with central Svantic
3. Central sees all agents across all pods
4. Central can route tasks to any pod's capabilities
5. Knowledge learned by any sidecar can be promoted to the shared store
**Characteristics:**
* Shared knowledge store — learning from Pod A benefits Pod C
* Centralized agent discovery — central knows about all capabilities
* Sidecars remain autonomous — if central goes down, sidecars continue operating
* Gradual rollout — start with sidecars, add central later
* Best for: scraping fleets, microservice architectures, multi-team organizations
***
## Choosing a Topology
| Factor | Standalone | Sidecar | Central + Sidecar |
| ----------------------- | --------------- | ------------------- | ------------------------------- |
| **Complexity** | Minimal | Low | Medium |
| **Knowledge sharing** | Single instance | Per-pod isolated | Shared across fleet |
| **Autonomy** | Full | Full | Full (degraded if central down) |
| **Scaling** | Vertical | Horizontal | Horizontal + coordinated |
| **Cross-service tasks** | Local only | Pod-local only | Fleet-wide |
| **Best for** | Dev, small prod | Independent workers | Enterprise, fleet ops |
***
## Migration Path
The topologies are additive. Start simple and grow:
1. **Start standalone** — Develop and test locally
2. **Move to sidecar** — Containerize and deploy alongside your service
3. **Add central** — When you need cross-pod knowledge sharing or fleet management, deploy a central instance and set `SAVANT_CENTRAL_URL` on your sidecars
No code changes required between topologies. Only environment variables change.