Skip to content

System Overview

CloudSlash is a local-first control plane. One daemon, six engines, everything your infrastructure needs to be visible, governed, and safely remediable.

It compiles down to a single lightweight binary that orchestrates resource discovery, graph-based relation linking, policy verification, and transactional remediation: no centralized state store required, no continuous polling.


High-Level Architecture

A panic in the AWS plugin cannot crash your daemon. A bad CEL rule cannot corrupt graph state. The separation is enforced at process and API boundaries, not just package imports.

graph TD
    subgraph Client Layer
        CLI[CloudSlash CLI]
        TUI[Terminal UI]
        WebUI[React/Vite Web Dashboard]
    end

    subgraph Control Plane [Daemon Process]
        Daemon[CloudSlash Daemon]
        API[REST / WebSocket Server]
        UnixSocket[Unix Domain Socket]
        Agent[DEVI AI Copilot]
    end

    subgraph Universal Engine Suite
        Graph[Devi]
        Swarm[Swarm]
        Saga[s.a.u]
        CEL[PolicyMesh]
        Oracle[Oracle]
        Rosetta[Rosetta]
    end

    subgraph Plugins [Independent Processes]
        AWS[AWS Plugin]
        GCP[GCP Plugin]
        AZ[Azure Plugin]
        K8s[Kubernetes Plugin]
    end

    %% Client and Control Connections
    CLI -->|REST API| API
    TUI -->|JSON Frames| UnixSocket
    WebUI -->|REST & WebSockets| API

    %% Daemon Internals
    Daemon --> API
    Daemon --> UnixSocket
    Daemon --> Agent

    %% Daemon to Core
    Daemon -->|Callback Injection| Graph
    Agent -->|MCP Tools / API| Graph

    %% Engine to Plugins
    Graph -->|gRPC Subprocesses| AWS
    Graph -->|gRPC Subprocesses| GCP
    Graph -->|gRPC Subprocesses| AZ
    Graph -->|gRPC Subprocesses| K8s

    %% Engine Internals
    Graph --> Swarm
    Graph --> CEL
    Graph --> Saga
    Graph --> Oracle
    Graph --> Rosetta

Core System Layers

Six engines. Each owns a distinct concern.

Devi: The central graph engine. Ingests raw cloud payloads, normalizes them into a unified graph schema, and evaluates structural relationships across clouds. Also hosts the AI Copilot that reasons over the graph.

Swarm: Controls scan cycles using AIMD congestion control. Scales query concurrency dynamically against live API rate limits so you never throttle an account.

s.a.u: Manages transactional state changes. Every mutating action is fully reversible via structured sagas and LWW-CRDT ledgers.

PolicyMesh: In-memory CEL rule evaluator. Blocks non-compliant remediations via DAG interception before they reach the cloud.

Oracle: Handles predictive math: HMM models for spot instance interruption, Dinic's max-flow for network safety, and MILP Branch-and-Bound for optimal fleet bin-packing.

Rosetta: Bridges live cloud resources back to their IaC source. Uses git blame to find the exact file, line, and commit responsible for drift: and patches it.


Architectural Decoupling Boundaries

  • Engine ↔ Daemon: The core engine doesn't import or know about the daemon. The daemon instantiates the engine and registers callback hooks (OnNodeScanned, OnGraphReady).
  • Engine ↔ Plugins: Plugins run as separate OS subprocesses communicating via gRPC over local transport. A panic or leak in a plugin can't crash the daemon.
  • Daemon ↔ AI Agent: The agent interacts via predefined REST APIs and the Model Context Protocol (MCP) server. The LLM can't execute raw logic directly on the engine's memory space.
  • Web UI ↔ Backend: The React Web Dashboard is stateless. All state: layout, policies, real-time events: comes through REST and WebSocket APIs.

Ingestion Data Flow

When a scan triggers, data flows through this pipeline:

[Cloud API] ──(gRPC Stream)──> [FlatBuffers Normalization] ──> [Concurrent Graph Shards]
[Verdict Assignment] <── [Formal Verification] <── [Ghost Linker] <───┘
  1. gRPC Ingestion: active plugins stream discovered resources as structured gRPC messages.
  2. FlatBuffers & Normalization: Raw payloads are parsed, unified, and converted into Cloud Resource Names (CRNs).
  3. Graph Storage: Nodes are inserted into a double-sharded, lock-striped concurrent graph.
  4. Ghost Linking: CIDR overlap and security group analysis run asynchronously to connect separate environments (e.g., matching a Kubernetes service to an AWS ELB).
  5. Formal Verification (Oracle): Safety and reachability proofs run via HMM models for spot instances and max-flow constraints for routing paths.
  6. Verdict Assignment: Heuristics and CEL policies run, tagging nodes with classification flags (FLAG, DELETE, BLOCK, CRITICAL, RISK, PURGED).

Graph Architecture

The memory-resident Universal Graph handles tens of thousands of resources concurrently:

  • 64-Shard Concurrent Graph: Lock-striping minimizes mutex contention. Reads don't block other reads; writes lock only a subset of the graph.
  • Roaring Bitmap Indexing: Accelerates complex topological queries (e.g., filtering all orphaned resources in a specific VPC).
  • Radix Trees: Optimized for rapid CIDR block matching and IP-routing lookups.
  • Async Operation Channel: Write operations queue into a 10,000 buffer channel, batching up to 5,000 entries or flushing every 50ms to prevent disk write bottlenecks.

Engine Callbacks

You can tap into the scan lifecycle by subscribing to the engine's callback interfaces:

Callback Hook Event Trigger Common Use Case
OnNodeScanned A resource is successfully read from a plugin Real-time CLI progress bar updates
OnNodeDiscovered A new edge link is discovered between two resources Infrastructure graph live-drawing
OnPolicyBlock A CEL rule blocks an action Alert notification trigger (Slack/Webhooks)
OnGraphReady Ingestion is finished, and topological sorting is complete Anomaly detection analysis
OnDriftDetected A mismatch between Terraform state and live setup is found Slack notifications & ticket creation
OnSolverResult Fleet optimizer finishes a linear programming iteration Web UI forecast chart rendering
OnTrafficUpdate NetFlow metrics are processed Dynamic link weight adjustments
OnScanComplete The entire pipeline is finished Executing final s.a.u sagas and disk persist

Dual-Execution Remediation Path

Remediations split into two logical channels:

Soft Path

Quarantine & Isolate * Execution: Performed directly by the s.a.u engine in the live cloud environment. * Mechanism: Security groups are locked down, IAM permissions constrained, or instances scaled down. * Safety: Fully reversible. State is tracked via CRDTs, enabling one-click rollback if issues arise.

Hard Path

GitOps & Pull Requests * Execution: Executed via the Rosetta engine. * Mechanism: Generates Git commit diffs or opens GitHub/GitLab Pull Requests modifying source Terraform/OpenTofu files. * Safety: Uses your existing CI/CD review workflows. File ownership is identified via git-blame metadata.


State Backends

CloudSlash scales from laptop to enterprise through modular state backends:

  • LocalBackend (Default): Uses an embedded BadgerDB key-value store under ~/.cloudslash/. Right for development, local CLI, and single-operator environments.
  • DynamoDB / CosmosDB Backend: For enterprise deployments. Lets multiple distributed daemons synchronize lock status, audit trails, and policy meshes across shared environments.