KDCube

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

Keep the agent and product code you already have. Run LangGraph, CrewAI, Claude Agent SDK, your own loop, or KDCube's built-in 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.
• 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

pip install kdcube-cli

Then create or connect an app, start the local runtime, and reload changes without rebuilding the platform image. Follow the Quick Start.

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 accountable 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 KDCube ReAct Agent

Existing agent frameworks remain responsible for their own graph or loop. KDCube supplies the surrounding runtime. 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 optional built-in 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 runtime · Why ReAct 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