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
Faramesh Cloud provides approvals UI and DPR replica it does not sit in the enforcement path. Use it for operator workflows; keep enforcement local.
Related
- CLI reference
- Registry versioning
- Dev mode for local parity