KDCube

The open-source, self-hosted production runtime for AI applications and agents.

Keep the agent and product code you already have. Run LangGraph, CrewAI, Claude Agent SDK, Claude Code, your own loop, or KDCube's native ReAct Agent. KDCube handles the production work around it: multi-user serving, ordered conversation delivery, streaming, files, identity, isolated code execution, cost controls, configuration, secrets, and deployment from Git.

Start with one capability. Put an existing agent behind REST, a webhook, or a streaming conversation endpoint. Embed the ready-made chat in your site. Add managed integrations or isolated execution later. You do not need to adopt the whole platform at once.

Website: kdcube.tech · Interactive architecture: kdcube.tech/architecture.html

Security and deployment scope

KDCube is an application runtime and SDK, not a single MCP server or a workstation connector. Applications can expose or consume MCP, REST, UI, event, and agent surfaces under explicit deployment policy.

• One running deployment is bound to one effective tenant/project and may serve many users and operator-approved applications.
• Each surface declares its access policy. Public routes do not require a normal platform session; other routes can require login, provider proof, or delegated access.
• Application backend code is trusted deployment code. Generated code is a separate boundary whose isolation strength depends on the configured execution profile.
• In the managed production path, secrets and connected-account credentials stay on the trusted server side; trusted tools resolve them only for an authorized request. The split executor receives neither the platform secret store nor provider credentials.
• Shared backing infrastructure is logically namespaced. Use separate deployments or dedicated infrastructure when a stronger boundary is required.

Read the canonical Security And Trust Model and the repository security policy before production use.

Quick start

python3 -m pip install --upgrade kdcube-cli
kdcube init --tenant acme --project local
kdcube start --tenant acme --project local

The kdcube init wizard uses the latest published release, offers Google login by default, and lets you skip optional model and private-Git credentials. init prepares the tenant/project workdir; start launches its local Docker Compose runtime. See the Quick Start for prerequisites, Google OAuth setup, source/version choices, and the generated workdir layout.

Working with a coding agent? Point it at AGENTS.md — it routes contributor rules and the operator/builder path (install, configure, build an app) and names the docs to read first.

Claude Code users can install the KDCube plugin. It equips the agent as both a KDCube app engineer and runtime DevOps operator: it can bootstrap and operate runtimes, scaffold and configure apps, inspect status and logs, test integrations, and run approved release workflows.

Choose your starting point

Each app can be as small as one backend service or as broad as a workspace. Apps may have no UI and no agent, or may host several agents and frontends.

What the runtime handles

• Serve and stream. Ordered per-conversation work, live output, followups, external events, reconnectable chat, files, and conversation history.
• Deploy and update. App code from Git, descriptor-based configuration, secret references, local/cloud parity, and near-live app reloads.
• Run generated code under explicit isolation policy. Local subprocess mode provides development-time crash containment but inherits the host environment and network. Legacy combined Docker adds a container and a filtered child environment while retaining one container/mount trust zone. The reference split-Docker profile places generated code in a separate, networkless executor with narrow mounts. Approved tools run on the trusted supervisor side under the current request identity and policy.
• Connect users and systems. OIDC and application authority, external accounts, Telegram identity linking, managed grants, revocable automation access, and protected REST or MCP surfaces.
• Track economics. Attribute LLM, embedding, web-search, and tool work to the user, app, conversation, and turn; enforce budgets before covered calls run.
• Compose a product. Ready chat and workspace components, custom widgets, scenes, canvases, app-hosted websites, APIs, jobs, and domain services.

A KDCube deployment is bound to one tenant/project scope and serves many concurrent users. Shared infrastructure may be namespaced rather than dedicated, while request identity and policy travel across process, thread, subprocess, and isolated-runtime boundaries.

Bring your agent, or use the native ReAct Agent

Existing agent frameworks remain responsible for their own graph or loop. KDCube hosts framework-owned runtimes through adapters over its shared Agent Harness Runtime. The architecture calls this the hosted foreign-runtime path; LangGraph and Claude Code are worked adapters, not the limits of the host layer. Each adapter binds the event, timeline, workspace, tool, and control contracts its agent needs. Direct app-owned Claude Code execution can remain outside the conversational harness. KDCube supplies the surrounding runtime: multi-user serving, ordered delivery, streaming, shared state, guarded tools, and deployment. In scaled serving, a graph is built for the current turn and then discarded; durable state belongs in its checkpointer or storage, not in a process-local graph object.

The native ReAct Agent uses an event-aware timeline and semantic streaming channels rather than requiring a provider-native tool-calling protocol. It can react to user input, tool results, application events, followups, steering, and current runtime conditions. With the reference split isolation profile, model-written code runs in a separate, networkless executor and reaches privileged capabilities through trusted supervisor tools.

Settle an existing solution in KDCube · ReAct Agent runtime · Why the ReAct Agent is not simply tool calling · Isolated execution

Apps provide and consume surfaces

An app can provide APIs, widgets, named services, MCP endpoints, events, jobs, or an agent. The same app can consume another app's services, external MCP servers, provider accounts, and shared platform capabilities. These boundaries are explicit in configuration, so every agent and surface can have its own tools, grants, models, budgets, and execution policy.

This is the framework layer: the SDK, contracts, configuration, components, and extension points builders use. The runtime executes and enforces those contracts. The platform combines both with shared serving, identity, economics, storage, hosting, and control surfaces.

Where KDCube fits

KDCube complements agent frameworks and observability products. It does not ask you to discard either.

Documentation

• What you can do with KDCube
• How to integrate with KDCube apps
• Architecture
• Security and trust model
• Docs index
• Builder navigation

License

MIT