# Fairvisor for Platform Engineering

URL: https://fairvisor.com/for/platform-engineering/

---


 One policy layer for every service. Zero code changes. Declarative rate limiting, cost budgets, and abuse protection — managed as config, enforced at the edge. Your platform team defines the rules. Services just work.
Read the platform engineering guide What Fairvisor Does for Platform Engineers Policy as Config JSON policies, versioned in git or managed in the SaaS UI. One source of truth. Applied to all services via the edge — no per-service implementation. → Policy bundle docs Git-Driven Policy Management source_of_truth: git. Push policies to a repo. Fairvisor validates, builds bundles, and deploys to all edges. GitOps-native from day one. → Shadow mode rollout CLI for Developer Workflow fairvisor init, validate, test --dry-run, connect, status, logs — full workflow from scaffolding to production. → CLI reference Two Deployment Modes Reverse proxy (standalone, in front of your service) or decision service (sidecar, behind your existing ingress). Both work. Pick what fits your infra. → Deployment docs Kubernetes-Native /livez and /readyz health checks, Prometheus /metrics endpoint, Helm chart, StatefulSet or Deployment. Works with any service mesh. → Helm guide Policy Templates Pre-built templates for LLM API protection, B2B SaaS tiered limits, and webhook protection. Instantiate, customize, deploy. → Golden bundles Observability Built In Prometheus metrics for every decision: fairvisor_decisions_total, fairvisor_loops_detected_total, fairvisor_circuit_breaker_trips_total, fairvisor_decision_duration_seconds. Plug into Grafana. Alert in PagerDuty. → Metrics reference Environment Promotion Controls Promote the same policy set from dev → staging → prod with guardrails and diff visibility. Roll forward and rollback stay deterministic across environments. Day-2 Operations What running Fairvisor in production looks like after week one:
Policy changes go through git push → validate → bundle → deploy. Same review process as code. Full diff history. Rollback to any version in seconds. → Operations hub Incidents start with decision tracing: use reject headers first, then debug session headers for policy/rule attribution. No blind log hunting. → Decision tracing Emergency response uses the kill-switch: freeze a tenant or route with a rapid, role-gated, audit-logged workflow. Propagation timing should be validated in your deployment runbook. → Kill-switch incident response Runbooks available for every operational scenario: reject spikes, budget exhaustion, bad bundle rollback, SaaS disconnect. → Runbooks | Policy lint checklist Who This Is For Platform and infrastructure teams owning shared rate limiting across services Staff engineers standardizing API governance across microservices DevOps teams building internal developer platforms Engineering orgs where every team re-implements rate limiting differently FAQ How do teams deploy their own rate limits without involving ops? Policies are JSON files in git. Teams write and review policies in the same repo with the same PR process as code. The platform team sets guardrails; product teams self-serve within them — no ticket, no ops dependency. How does policy versioning work? Every policy change creates a new immutable version. Full diff history. Rollback to any previous version in seconds via CLI or SaaS UI. You always know exactly what was enforced at any point in time — useful for both debugging and audits. What deployment modes are supported? Reverse proxy (standalone, Fairvisor in front of your service) or decision service (sidecar, behind your existing ingress via auth_request/ext_authz). Both modes share the same policy language, observability, and operational tooling. → Deployment docs How does shadow mode prevent bad policies from causing outages? Shadow mode logs what would be throttled or rejected without enforcing anything. Run against real production traffic for a day or a week. Tune thresholds on real data. Promote to enforcement when you’re confident. → Shadow mode rollout How do I integrate Fairvisor with our observability stack? Prometheus metrics endpoint out of the box — plug into Grafana, alert in PagerDuty, ship to Datadog or Splunk. Standard /metrics endpoint, standard label names. No custom exporters. → Metrics reference Is Fairvisor Kubernetes-native? Yes. /livez and /readyz health checks, Prometheus /metrics, Helm chart, StatefulSet and Deployment support. Works with any service mesh including Istio and Linkerd. → Helm guide How do I manage policies across multiple environments? The same policy bundle can be parameterized for dev, staging, and prod. GitOps workflow: push to repo → CI validates → bundle builds → edges pick up the new version automatically. No environment drift, no manual sync. Can I enforce temporary rules during incidents without changing app code? Yes. Apply a short-lived policy override (for route, tenant, or key), propagate it to edges, and remove it after incident resolution. All actions stay versioned and auditable in the same policy workflow. Why teams choose Fairvisor Policy as infrastructure, not code JSON policies versioned in git, deployed to all services at once. No per-service implementation drift, no language-specific library sprawl. GitOps-native from day one Push to repo → validate → build bundle → deploy to edges. Fits existing CI/CD without new tooling or process changes. Kubernetes-ready out of the box Health checks, Prometheus metrics, Helm chart. Drops into any service mesh without modification. Rate limiting is infrastructure. Treat it that way. Read the platform engineering guide Also relevant For SRE Sub-millisecond enforcement, graceful degradation, and SLO alerting.
For Compliance Immutable audit logs, RBAC, and SOC 2 control mapping.
For API-First SaaS Per-tenant limits, noisy neighbor protection, and tiered plan enforcement.