Tutorials & guides
Deploying Faramesh at scale
Topologies, fleet operations, catalog mirrors, and production posture for platform teams.
Platform engineers run Faramesh beside agents not inside the model API path. This guide covers how to roll out stacks safely across many hosts.
Deployment patterns
| Topology | When |
|---|---|
| Sidecar daemon per pod | Kubernetes agents (one stack per workload) |
| Shared daemon per node | Multiple agents on same VM |
| CI gate | faramesh check on every governance.fms PR |
| Bundle + air-gap | faramesh bundle into regulated networks |
See Topologies for diagrams and trade-offs.
Catalog distribution
Default: CLI pulls from github.com/faramesh/faramesh-registry.
| Environment | Pattern |
|---|---|
| Internet egress allowed | No config (GitHub default) |
| Mirror required | Internal git mirror + FARAMESH_REGISTRY_ROOT |
| HTTP internal | Run catalog cmd/registry, set FARAMESH_REGISTRY_URL |
Pin FARAMESH_REGISTRY_GITHUB_REF to a release tag for immutable rollouts.
Operations checklist
- Bootstrap:
faramesh initin golden templates; store stack in git. - CI:
faramesh check+faramesh planon PRs; block merge on failure. - CD:
faramesh applyin deployment pipeline; restart daemon with compiled artifact. - Secrets: vault/SPIFFE providers; no long-lived keys in agent env.
- Observability: scrape daemon health; ship DPR to log pipeline.
- Upgrades: bump import pins in staging; run integration tests; promote.
Fleet visibility
For fleet visibility, forward DPRs and health signals to your observability and audit systems. Keep enforcement local and keep the daemon WAL as the source of truth.
Related
- CLI reference
- Registry versioning
- Dev mode for local parity