Operations integration, 1 October 2026. Cloud inventory supplies deployment/resource evidence to Operations & Reliability. Shadow workspaces verify isolated destinations and leases; shared observability retains the existing collectors and ClickHouse consumers. A declared binding or historical provider read is not proof of an observed runtime call or safe workspace isolation.

Reaktor Cloud

Cloud is the workbench pane that shows everything a product runs on, in one graph. It reads the Cloudflare account, the Google Cloud project and the Kubernetes cluster with the logins already on the machine, adds what the repository declares, and joins them: a hostname to the worker it routes to, the worker to its bindings, a tunnel to the cluster service behind it, a pod to its volume, the volume to the disk it lives on, and the disk to the machine.

Status: rebuilt on 30 September 2026 and checked against the BestBuds accounts. It replaces the earlier Compute pane, which read only the repository and said so on every screen. Redesigned on 1 October 2026: one row of views instead of two rows of tabs, the provider tabs folded into one list, and real Deploy, Pipeline and Runs views. The design direction for fleets of cells stays in Reaktor Cloud Control Plane.

At a glance

• Resources. Every resource as one map, with a list and the cluster's own console (Radar) as two other ways to see the same set. A summary card on the map shows each account's reading, what the map holds, the cluster's CPU and memory, and the findings by severity; clicking a severity lists them, and a finding opens its resources on the map.
• Operations. The workspace's cloud operations, grouped by what they do: look, change, or hand out access. Beside them, Cloud APIs reaches every operation Cloudflare, Supabase and Google Cloud publish, about 3,800 plus any of Google's 315 APIs (more).
• Deploy. Every worker and workload: when it went live and who shipped it, whether it matches the repository, where it falls in the deploy order, and a deploy button that goes through approval.
• Pipeline. The CI pipeline as a map: the GitHub Actions jobs, the Dagger functions they call, and the lanes that run on a host.
• Runs. Everything that happened, newest first: deploys, rollouts and restarts the accounts report, and the operations Hangar ran.
• Cost. The quantities the bills are made of, and the capacity paid for but not used.
• Agents. Five read-only MCP tools give coding agents the same graph, and the door's cloud provider gives Claude Code and Codex the complete APIs, with writes waiting for a person.

1. How it works

Cloudflare API ─┐
gcloud token ───┼─ CloudInventoryRead (native, read-only) ─ run in the control plane ─┐
kubectl ────────┘                                                                   ├─ assemble ─ findings ─ pane · MCP
repository (wrangler configs, k8s manifests) ───────────────────────────────────────┘

The read is a control-plane operation, not something the pane does by itself. Refresh asks the plane for Cloud inventory · read; the plane records it as a run with a safety class of live read and a fingerprinted plan; the tooling executor runs it in-process and returns the readings as the run's output. The pane parses that output, the same way the device list and the Kubernetes reads already work. Nothing polls: the pane reads once when it first opens and again when you press Refresh.

The pieces live where the rest of the tooling does:

Where every fact comes from. Each resource and each relationship carries its evidence: declared (the repository), observed (a provider's API) or inferred (joined by the assembler). The pane draws them differently — solid for deployed, dashed for declared only, dotted for inferred — and the inspector lists the sources with how old each reading is.

How providers are joined. Each reader emits what it can see, plus references it cannot resolve alone. The assembler resolves them against the whole snapshot:

The Cloudflare reader adds the Postgres database behind each Hyperdrive configuration itself. A reference that resolves to nothing becomes a finding, and a binding whose target no reading has becomes a placeholder marked missing.

Credentials. The Cloudflare reader uses CLOUDFLARE_API_TOKEN when it is set and otherwise the wrangler login, refreshing it through wrangler when it expires. The Google Cloud reader asks gcloud for an access token, trying each signed-in account until one can read the project, and remembers which one worked. The cluster reader uses the workspace kubeconfig. Secret values are never read: worker secrets and Kubernetes secret references appear by name only.

2. The pane

One row holds everything above the content: the six views (Resources, Operations, Deploy, Pipeline, Runs, Cost), the app picker, each account's reading, and Refresh. Apps are worked out from zones, declared resources, names, namespaces and neighbours: a store only one app binds belongs to that app.

Resources

Three ways to see the same resources, with the search, Problems only and the provider switches shared between them: Map, List and Radar (the cluster's own console, shown when a cluster was read).

Summary card. Like the Graph pane's, it sits on the map: each account's reading with its count and duration (or why it failed), how much of the inventory the map shows at this detail level, a bar of what the resources are (internet, compute, state, data, network, platform, machines), the cluster's CPU and memory asked for against what the machine has, and the findings by severity. Clicking a severity lists those findings; clicking one selects its resources and shows every path through them.

Map. The map is drawn by the same renderer as the Graph pane, so it looks and behaves the same: frames, cards with a coloured header and pins, the same camera, legend, selection highlight and focus.

• Frames are services. One frame per worker (with its dev twin), per Kubernetes namespace and per machine, holding everything only that service uses: its hostnames, Durable Objects, databases and buckets. Stores and connections that several services use go to a shared frame for their app.
• Frames are packed to the window's shape, so a wide screen gets a wide map instead of a tall column per resource type.
• Links run the Graph pane's way, from what is provided to what uses it. Machines, stores and connections sit on the left, workers in the middle, hostnames on the right.
• A worker's bindings are its input pins, named as in its Wrangler config. A hollow red pin is a binding whose target is not deployed. Dashed links exist only in the repository; dotted ones are inferred.

Three detail levels:

Folded groups show their health, traffic and findings and open on click. Selecting a resource highlights its neighbours; Neighbours and 2 hops narrow the map to them, and Path shows every route through it — for a hostname, the worker, its bindings, the tunnel, the service, the pods, the volumes, the disks and the machine. Problems only keeps resources with a medium or worse finding.

The search box takes the same language as DevTools, with cloud keys:

List. One table for every provider: role, name, kind, provider, app, the detail that matters for that kind (requests and latency for a worker, readiness for a workload, size for a store), 24 hours of traffic, the last change, whether it matches the repository, and its findings. Problems sort first. Right-click a row to show it on the map, trace its paths, open it in the console or copy its name.

Inspector. One panel for any resource on any tab: what is wrong with it, what was measured (with a 24-hour request sparkline for workers), the bindings the repository declares against the ones deployed, what reaches it, what it reaches, recent changes to it and its neighbours, every property, and where each fact came from. It links to the provider's console.

Operations

The cloud operations, grouped by what they do. Look reads and runs at once. Change alters what runs, so each becomes a plan you approve first. Access hands out a session or a credential and needs a second approval. Each row shows its last run from Hangar; open it for the command, where it is defined, and the last lines of its output.

Cloud APIs

The second half of Operations reaches each provider's complete API, not only the operations this workspace defines. Reaktor reads the description each provider publishes of its own API and turns every operation in it into something you can find, fill in and call:

Pick Cloudflare, Supabase or one of twelve common Google APIs (Compute, Cloud Run, Pub/Sub, Logging, Monitoring, Artifact Registry, IAM, Resource Manager, Service Usage, Storage, Secret Manager and GKE), search in plain words, and pick an operation. The pane shows its URL, the token permissions that allow it (any one of them is enough) and a field for each parameter, with the workspace's Cloudflare account and Google project already filled in. A read runs at once and is recorded as a run. Anything that writes or deletes becomes a plan instead: it runs only in the production environment, after you approve it and type the operation's id. The answer appears below the form. A refused call says which sign-in was used and which permissions the operation needs.

The same layer serves the pane and the agents (section 4). It lives in reaktor-tooling: ApiSurface and ApiSpecs (common code, so they run on the JVM and in JavaScript) turn an OpenAPI or Discovery document into one list of operations, each with its parameters, body, effect and permissions; CloudApis fetches the descriptions, signs requests and sends them; CloudApiCall is the control-plane operation that runs one call. Descriptions are downloaded on first use and kept in ~/.reaktor/api-specs for a week.

Deploy

Every worker and cluster workload, in deploy order: when it went live and who shipped it, the image a workload runs, whether it matches the repository (in sync, bindings differ, image differs, not deployed, not declared here), and 24 hours of traffic. Deploy runs the repository's own deploy script for that service through the approval path. The order chip compares the documented deploy order with the one the service bindings require.

Pipeline

The CI pipeline, read from .github/workflows and .dagger/src/index.ts and drawn by the same renderer as every other map: what starts each workflow, its jobs and what they wait for, the Dagger functions each job calls and the functions those call, with the commands each runs in its container, and the lanes the workflow names as running on a host. Select a step for its command, how to run it locally, and where it is defined.

Runs

Everything that happened, newest first and grouped by day: deploys, rollouts and restarts the accounts report, and the operations Hangar ran, with a seven-day strip above. Filter by kind, or narrow to the selection and its neighbours; a row opens its resource or its run.

Cost

Prices are not readable with these logins, so Cost lists what the bills are made of: machine types and uptime, disk gigabytes by type, static addresses, stored images and snapshots, worker requests and subrequests, D1 size, buckets and Durable Object classes. Idle capacity gets its own line: memory requested against what the machine can give, and what is paid for but unrequested.

3. Findings

Every finding names the resources behind it, so selecting it shows the evidence on the map.

4. For coding agents

Reaktor Desktop's MCP server carries five read-only tools over the snapshot the pane last read:

Claude Code and Codex reach the complete APIs through the door's built-in cloud provider (see the door). The door classifies each tool, so reads run and changes wait for a person:

Each call tool refuses an operation of another kind, so a write cannot be sent as a read. Answers longer than 60,000 characters are cut. This is the shape Cloudflare chose for its own MCP server: search and call over the description, rather than one tool per operation, which at about 17,000 operations no model could hold.

5. Checked on real accounts

On 30 September 2026, against the BestBuds Cloudflare account, its Google Cloud project and the k3s cluster:

• One reading returned about 210 resources and 375 relationships in roughly ten seconds — Cloudflare about 9 s, Google Cloud 6–9 s through REST (it took up to a minute through the gcloud CLI), the cluster about 1 s.
• Every cross-provider join resolved: tunnel routes and VPC services to cluster services, volumes to their disks, the app server's image to its registry, Hyperdrive to Postgres, the node to the VM.
• The first reading produced 32 findings across security, reliability, health, drift and cost. They describe live infrastructure, so they are kept in the pane and not listed here.
• The pane's render test reads the accounts through the control plane and renders every tab and subpane; the workbench's pane-opening, subpane-crash, graph-coverage and design-gate tests pass, and a synthetic test covers the joins and findings.

On 2 October 2026 the Cloud APIs were checked the same way: Hangar's view found List Worker Scripts in Cloudflare's description, filled in the account, and read the account's workers through the control plane in about two seconds; Google's compute.instances.aggregatedList answered for the project; an agent at the door searched, read, and had a Worker upload held for approval with nothing sent. Supabase's description loads, but calling it needs a personal access token this machine does not have yet.

6. Known limits

• Cloud APIs send JSON only. About 30 Cloudflare operations take multipart uploads (a Worker with its modules, for example) and cannot be sent yet.

• Cloud APIs return one page. A list answers with its first page; pass the page or cursor parameter for the next. Google's long-running operations come back as an operation to read again.

• Cloudflare Access is not readable with the wrangler login, so a public hostname in front of a database is reported as exposed unless you know an Access policy guards it.

• Prices are not read; Cost lists quantities.

• Refresh is manual. There is no live stream of changes yet; the cluster could be watched.

• Supabase, Firebase and Grafana Cloud appear on the map only through what points at them (Hyperdrive, secret names, exporters). Supabase's own API can be called from Cloud APIs, but the map does not read it yet.

• Workers' deployed bindings are compared by kind and target; a binding renamed in the repository shows as removed and added.

• One machine, one cluster. More clusters or projects need more readers configured.

7. How it compares

Cloudflare draws one worker's bindings at a time; the open asset graphs (Steampipe, CloudQuery, Cartography) do not cover D1, KV, Queues, Durable Objects or tunnels. A graph across Workers, their stores, tunnels and the cluster is the part nobody else draws.

8. Roadmap

Ordered by how much each adds. ✅ done, ⬜ still to do.

• ✅ One graph across Cloudflare, Google Cloud, the cluster and the repository, read through the control plane.
• ✅ Findings with evidence; drift between the repository and what runs.
• ✅ Map with groups, neighbourhoods and paths; provider tabs; changes; cost quantities.
• ✅ One row of views; one list across providers; a summary card on the map; Deploy with approval-gated deploys; the CI pipeline as a map; one history of changes and runs.
• ✅ MCP reads for agents.
• ✅ Every operation of the Cloudflare, Supabase and Google Cloud APIs, read from the providers' own descriptions, callable from Hangar and by agents at the door, with changes behind approval.
• ⬜ Save each reading and diff two of them: what appeared, disappeared or changed.
• ⬜ Watch the cluster and overlay changes on health, so a rollout lines up with the errors after it.
• ⬜ Read Cloudflare Access applications to confirm or clear exposure findings.
• ⬜ Prices from the billing exports, per resource and per app.
• ⬜ Actions through the approval step: restart a workload, redeploy a drifted worker, attach a snapshot schedule.
• ⬜ Supabase, Firebase and Grafana Cloud on the map (Supabase's API is already callable).
• ⬜ Multipart uploads and following pages in Cloud APIs.

Sources for the comparison: Headlamp map view, App Hub, CloudWatch Application Signals, SST Console, Encore Flow, GCP Recommender, CloudQuery asset inventory, Wiz toxic combinations, Komodor events, Datadog change tracking, AWS Resource Explorer syntax, JupiterOne J1QL, Hava diff view, OpenCost specification, Lens release notes, Cloudflare worker bindings diagram, Cartography, Steampipe.