Faramesh Cloud

Faramesh Cloud is the organizational control plane for Faramesh. It does not run enforcement. It is not a hosted version of the daemon.

The daemon, the policy engine, the WAL, and the credential broker run on your infrastructure, permanently and unconditionally. Faramesh Cloud is everything adjacent to enforcement that benefits from being centralized: indexed DPR storage, the approvals UI for people without CLI access, the policy and provider registry, and fleet visibility across many stacks.

If Faramesh Cloud goes down, every governed agent in your organization keeps running normally.

What lives where

┌────────────────────────────────────────────────────────────────┐
│                    Your infrastructure                          │
│                                                                 │
│   CLI · daemon · policy AST · WAL · credential broker          │  ← enforcement truth
│   identity providers · KMS · audit sinks                        │
│                                                                 │
└──────────────────────────────┬─────────────────────────────────┘
                               │  outbound, batched, async
                               │  DPR records (post-redaction)
                               │  health metrics, pending approvals
                               ▼
┌────────────────────────────────────────────────────────────────┐
│                    Faramesh Cloud                               │
│                                                                 │
│   DPR replica (queryable, long-retention)                       │
│   Approvals UI · Fleet view · Compliance reports                │
│   Registry (providers / packs / framework profiles)             │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

The sync channel is outbound only from your infrastructure. Cloud cannot reach into the daemon. It cannot modify policy. It cannot issue credentials. The daemon decides every permit and deny by itself, and writes the DPR locally before the call completes.

Why the enforcement path stays local

Three reasons that are non-negotiable.

What Cloud is

Cloud is four things, clearly separated.

Observability plane

The daemon optionally streams DPR records outbound to Cloud after they've been written to the local WAL. The WAL is still the source of truth. Cloud is an indexed, queryable, long-retention replica that gives you cross-stack visibility and search that would be impractical to run locally across many stacks.

Approvals plane

When a defer decision is pending and the approver doesn't have CLI access, Cloud is the approval interface. The daemon pushes pending approvals to Cloud over the sync channel. Approvers act via the web UI. Cloud pushes the decision back to the daemon. The daemon records the approval as a DPR update. The enforcement path is still the daemon. Cloud just routes the human decision.

Registry

Policy packs, provider binaries, framework profiles. Globally accessible, versioned, signed. See Registry.

Fleet control plane

Organizations running multiple stacks see all of them in one place, status, health, pending approvals, budget burn, recent decisions, aggregated.

The sync channel

The sync channel is:

• Established from the daemon side. Outbound only from your infrastructure. No inbound connections from Cloud to your network.
• Authenticated via a stack API key provisioned at registration time.
• Encrypted (TLS 1.3 minimum).
• Asynchronous and buffered. DPR records batch-sync on a configurable interval, not per-record. A slow or unavailable Cloud causes records to queue locally and sync when the channel recovers.
• Fully degradable. If the channel is down, the daemon logs the condition and continues enforcement. No alert suppression. No enforcement degradation.

The one exception to "Cloud cannot reach the daemon": emergency kill switches for operators without CLI access. The daemon polls Cloud on a short interval (default 30 s) for emergency commands. Only two command types are accepted:

• Agent kill, terminate sessions for a named agent.
• Agent isolate, put a named agent into shadow mode.

Both are recorded as DPR events. Both require platform admin role. No other command can flow Cloud → daemon. faramesh agent kill from the CLI remains the immediate path for engineers with terminal access.

Navigation

Six primary sections. Everything is scoped to an organization. Stack context is a filter, not a navigation step.

What Cloud explicitly is not

When Cloud is not needed

You govern one stack. You are the operator. You have CLI access. You check faramesh status in your terminal. You review faramesh audit tail when something happens. Approvals come to you and you run faramesh approvals approve from the CLI. One team, one stack, one engineer.

The CLI does everything you need locally. Cloud adds nothing here.

When Cloud becomes necessary

Any one of these forcing functions justifies it:

1. Multiple people need visibility without CLI access. Compliance officers, security reviewers, engineering managers. None should SSH into the production host.
2. Multiple stacks need to be seen in one place. Five teams, five governance stacks, five daemons across five hosts. faramesh status shows one stack at a time.
3. Approvals need to reach people who don't have CLI access. The defer workflow works locally. The moment the right approver isn't the one with the terminal, the local workflow breaks.
4. Long-term DPR retention and compliance reporting. The local WAL is durable but not designed for queryable retention across 18 months and 6 stacks. The Cloud replica is.

Deployment models

In both models, the daemon is the same. Only the sync target changes.

Pricing

• Local runtime, CLI, every interception tier, free and open-source forever.
• Cloud, per seat for approvers/operators, plus a usage tier on ingested DPR volume for high-throughput projects.
• Self-hosted Cloud, annual license, includes priority support and a registry mirror.

What's next

• Quickstart: get the runtime running first; pair to Cloud later
• Auditing: the DPR stream Cloud indexes
• Approvals → CLI: the approval workflow Cloud puts a UI on
• Registry: the artifact store