Octelium
Documentation

Introduction

What Is Cordium?

Cordium is a free and open source, self-hosted, identity-based, horizontally scalable sandbox platform built on Kubernetes and Octelium. It provides isolated, reproducible sandboxes for humans, AI agents, and automated workloads.

Cordium is designed around two tightly integrated purposes that most platforms treat as separate concerns:

  • General-purpose sandboxed execution: a platform for running both long-lived workloads (remote development environments, persistent coding sessions, running servers) and short-lived tasks (AI agent runs, CI/CD jobs, automated scripts) inside isolated, reproducible sandboxes accessible via a web browser, SSH, the cordium CLI, or a gRPC-based SDK.

  • Identity-based zero-trust secretless remote access: a platform that leverages Octelium ZTNA capabilities to provide secretless, policy-driven access to infrastructure resources (SSH servers, databases, internal HTTP APIs, mTLS services) from within Workspaces, without exposing, distributing, or managing upstream application-layer credentials (e.g. API keys and access tokens, SSH private keys, database passwords, etc.). This works for both human users opening a browser-based terminal and AI agents executing programmatically inside a Workspace.

Cordium is 100% free and open source. It is designed for single-tenant self-hosting and built on standard Kubernetes infrastructure with no proprietary cloud control plane and no vendor lock-in.

Main Features

  • Unified platform for humans and AI agents. The same Workspace (synonymous with a sandbox) can be accessed interactively through a browser-based terminal, via SSH, through the CLI, or programmatically via gRPC-based SDKs. This makes Cordium equally suitable as a remote development environment for engineers (comparable to GitHub Codespaces) and as an execution sandbox for AI agents, and automated workloads. Workspaces support both long-lived runs (remote development, persistent servers) and short-lived runs (AI agent tasks, build jobs, scripted automation).

  • Highly customizable sandbox environments. Workspace filesystems can be built from OCI/Docker images, Dockerfiles, git repositories, and devcontainers. Multi-repository cloning, including private repositories with authentication. Workspace configurations are fully declarative via YAML files and can be instantiated through the cordium CLI or managed programmatically via the gRPC API. Each running Workspace supports full root access within the sandbox, allowing users to run containers, install system packages, and run privileged services. Templates support pre-building for fast Workspace instantiation. Spaces provide namespacing for Workspaces, Templates, Secrets, and GitProviders. Secrets can be referenced in environment variables and repository authentication configurations. Workspace storage can be persistent or ephemeral. Resource limits (memory, CPU, and storage) can be defined at the Workspace, Space, and Cluster level.

  • Rootless container-based sandboxing on standard Kubernetes. No bare-metal nodes or specialized hardware are needed. Workspaces run efficiently on any Kubernetes cluster.

  • Zero-trust platform on Octelium. Cordium is built on Octelium, inheriting its zero-trust infrastructure as a foundational layer to provide the following capabilities:

    • Dynamic secretless access. Octelium's layer-7 awareness enables Users to seamlessly access resources protected by application-layer credentials without exposing, managing, or distributing such secrets (read more here). This works for HTTP APIs without sharing API keys and access tokens, SSH servers without sharing passwords and private keys, Kubernetes clusters, PostgreSQL/MySQL databases, and any L7 protocol protected by mTLS.

    • Modern, dynamic, fine-grained access control. Octelium provides a centralized, scalable, fine-grained, dynamic, context-aware, layer-7-aware, attribute-based access control system (ABAC) evaluated on a per-request basis (read more here) with policy-as-code using CEL and OPA (Open Policy Agent). Octelium has no notion of an "admin" user, enforcing zero standing privileges by default.

    • Continuous strong authentication. A unified authentication system for both human and workload Users, supporting any web identity provider (IdP) that uses OpenID Connect or SAML 2.0, as well as GitHub OAuth2 (read more here). It also supports secretless authentication for workloads via OIDC-based assertions (read more here). Built-in support for MFA, re-authentication, and login via FIDO2/WebAuthn/Passkey, TOTP, and TPM 2.0 Authenticators.

    • OpenTelemetry-native auditing and visibility. Real-time, identity-based, L7-aware visibility and access logging. Every request is logged and exported to your OpenTelemetry OTLP receivers for integration with log management and SIEM providers.

  • Kubernetes-native pluggable storage. Cordium leverages Kubernetes-native storage for Workspace persistence and integrates with any Kubernetes CSI driver and VolumeSnapshot provider. This includes Longhorn, AWS EBS, GCP Persistent Disk, Azure Disk, Ceph/Rook, OpenEBS, and any other CSI-compliant storage solution. Storage class and volume snapshot class selection is policy-driven via CEL expressions, allowing operators to route different Workspace types to different storage backends.

  • Ready for agentic AI. Cordium is not only a sandbox for isolated long-lived and short-lived process execution by sandboxed AI agents. It leverages Octelium's zero-trust infrastructure to provide identity-based, fine-grained, L7-aware, context-aware, ABAC-based access to resources (e.g. remote private/internal resources behind NAT, publicly protected SaaS resources such as APIs and databases, etc.) of any type from within Workspaces. This includes secretless access for resources that require application-layer credentials (API keys, access tokens, SSH passwords and private keys, database passwords, and mTLS private keys) without exposing, distributing, or sharing such credentials with the sandboxed AI agent. Credential mappings and privilege scopes can be dynamically assigned to specific agents based on identity and context on a per-request basis.

  • Open source and designed for self-hosting. Cordium, like Octelium itself, is fully open source and designed for single-tenant self-hosting. There is no proprietary cloud-based control plane, and this is not a limited open source version of a separate fully functional paid SaaS product. Cordium can be deployed on a single-node Kubernetes cluster running on a low-cost cloud VM/VPS, or on production-grade multi-node Kubernetes installations, cloud-based or on-premises, with no vendor lock-in.

The Problem Cordium Solves

Modern development and automation workflows require isolated, reproducible execution environments that can be provisioned on demand, accessed from anywhere, and decommissioned cleanly. At the same time, those environments need access to infrastructure: databases, internal APIs, source code repositories, SSH targets. Managing that access (distributing credentials, rotating secrets, scoping permissions) is operationally expensive and a persistent source of security incidents.

Existing approaches address one side or the other. Remote development platforms (GitHub Codespaces, Coder, Gitpod) solve the execution environment problem but leave credential management entirely to the user. Most sandbox platforms for AI agents focus primarily on execution isolation and SDK ergonomics, while infrastructure access and credential governance are usually handled separately. Modern identity-aware proxy-based zero trust access platforms solve the credential problem but are not designed as execution environments.

Cordium unifies these. A Workspace is simultaneously an isolated execution environment and a first-class identity in the Octelium Cluster system. Processes running inside a Workspace can access any authorized Octelium-managed resource (e.g. a PostgreSQL/MySQL database, an SSH server, an internal HTTP API, a generic TCP/UDP workload, etc...) through their Workspace identity alone, with no credential injection, no static API keys, and no secrets in environment variables. The Workspace's access scope is determined based on identity and context on a per-request basis via policy-as-code using CEL and OPA expressions.