DOCSEARCHbyAlgolia
Submit Docs

Cosmonic Documentation

website·Indexed 34 days ago

https://docs.cosmonic.com/

Documentation for Cosmonic, featuring Cosmonic Desktop for creating and running sandboxed AI agent code, and Cosmonic Control for managing workloads. Includes API references for the wasmCloud Runtime Operator (runtime.wasmcloud.dev/v1alpha1) and Cosmonic Control (control.cosmonic.io/v1alpha1), guides for the cosmonic CLI and cosmonicd daemon, and setup instructions for AI sandboxes integrating with Claude, OpenAI Codex, Gemini, and others.

Tokens
59K
Snippets
241
Records
420
Agent score
56%

What's inside Cosmonic

  1. Overview of cosmonic:kafka interfaces

    The cosmonic:kafka capability provides several interfaces for interacting with Kafka. The choice of interface depends on the desired operational model:

    • producer: Used for publishing messages. Binding-scoped functions with no stateful resource.
    • transaction: Used for atomic publishing and offset commits. begin() returns a stateful resource.
    • consumer: Used for long-lived services requiring direct control of a Kafka session. The component owns the stateful resource and must drive the record stream to maintain group membership (heartbeats).
    • handler: The serverless/event-driven path. The component exports the handler, and the host manages polling, heartbeats, and commits, invoking the component only when work is available. This allows scaling to zero without adding Kafka group members.
    • types: Provides shared vocabulary, including records, variants, and the error-code variant.

  3. Overview of Cosmonic Desktop Application Views

    Cosmonic Desktop organizes its interface into three primary sidebar categories and a header-based drawer:

    • Explore: Contains the Academy (learning hub with offline missions) and Launchpad (curated catalog of templates and samples).
    • Fleet: Contains Workloads (the primary organizational unit for components and services), Capabilities (all capabilities in use across workloads), Logs (structured daemon and workload logs), and Secrets & config (secret references and named configurations).
    • Inventory: Contains Local Registry (OCI cache for images/versions) and Inspect (graphical view of component imports and exports).
    • Builder: A header drawer used for prompt-to-production app creation.

  5. Overview of Cosmonic Desktop

    Cosmonic Desktop is a free, cross-platform desktop application (macOS, Windows, Linux) that provides a sandbox for creating, running, and managing code on a local machine. It uses the open-source wasmCloud host to run workloads as WebAssembly (Wasm) components, which are portable, isolated units of software. It is specifically designed for running untrusted code such as AI-generated code, agents, MCP servers, and third-party components securely.

  6. Overview of the cosmonic CLI

    cosmonic is a developer command-line tool for Cosmonic Desktop used to scaffold projects and manage the build-and-run loop. It acts as a thin client that communicates with the Cosmonic Desktop background daemon. The CLI is bundled with Cosmonic Desktop and is automatically added to the system PATH; manual installation is not required. Note that Cosmonic Desktop must be running for the CLI to function.

  7. Overview of Cosmonic Control CI/CD and GitOps

    Cosmonic Control workloads are distributed as OCI artifacts. A typical CI/CD pipeline involves building .wasm binaries, pushing them to an OCI registry, and updating Kubernetes manifests. The ecosystem supports GitHub Actions and GitLab CI for automation, and Argo CD or Flux for GitOps reconciliation of Kubernetes state.

  8. Overview of Cosmonic Sandboxing

    Cosmonic provides a capability-based sandbox for AI-generated applications, Model Context Protocol (MCP) servers, and untrusted code. It ensures that code runs within a defined boundary of allowed access, protecting against risks such as prompt injection, lateral movement, and remote code execution. The system allows developers to define a security boundary on a local machine and deploy that same boundary unchanged to a production cluster.

  9. Understand Capability-Based Security in Cosmonic

    Capability-based security is a mechanism where a 'capability' is an unforgeable reference that grants the right to perform a specific action on a specific resource. Unlike Access Control Lists (ACLs) or Role-Based Access Control (RBAC), which check the identity of the requester (ambient authority), capability-based security attaches authorization to the reference itself. This eliminates the 'Confused Deputy' class of attack because code cannot manufacture a grant or access resources for which it does not hold a specific capability handle.

  10. Reduce platform costs using WebAssembly and wasmCloud

    Cosmonic utilizes WebAssembly (Wasm) and wasmCloud to address high cloud infrastructure and engineering costs. Key benefits include:

    • Scale to Zero: Achieve sub-millisecond start times and vertical auto-scaling, allowing applications to scale to zero with no cold starts.
    • Increased Density: Use the small footprint of Wasm to bin-pack more workloads on existing hardware.
    • Code Reusability: Leverage the WebAssembly component model to allow binaries written in different languages to interoperate, reducing time spent on boilerplate and patching dependencies.
    • Resiliency: Deploy applications across clouds, datacenters, and edges with cross-region and capability-level resilience.

  11. Sandbox OpenAI Codex with Cosmonic Desktop

    Cosmonic Desktop provides a local AI sandbox for OpenAI Codex. Code generated by Codex is compiled to WebAssembly and runs on the local machine without access to files, network, or keys unless explicitly granted. This is achieved through two primary configurations: a sandbox playbook (skill) and an MCP server.

  12. Understand WebAssembly component sandboxing and capability boundaries

    In the Cosmonic/wasmCloud ecosystem, a WebAssembly component's imports define its capability surface. Sandboxing is an inherent property of the artifact produced by the compiler, rather than an external configuration. Because this surface is derived from the code, it accurately reflects all dependencies, registry imports, or LLM-generated code. The platform's role is to pin the artifact, allow the boundary to be reviewed, and enforce the attached policy.