Q&A
Start with one capability or compose a larger product. These answers explain what KDCube provides, what remains yours, and how adoption can stay incremental.
The product can stay modular while deployment, identity, conversation delivery, storage, budgets, and observability remain consistent. Each app keeps its own code, surfaces, state ownership, and policy; KDCube supplies common runtime seams. Read the full story →
It can help with one app as soon as you need a ready multiuser chat, ordered conversation delivery, streaming, hosted files, isolated code execution, deployment from Git, user-scoped integrations, or spend tracking. You do not have to adopt all of those at once. Choose a starting path →
You can. KDCube exists because we repeatedly needed the same production machinery around AI applications. Keep the parts of your product that already work; use KDCube only for the runtime and components you do not want to build and operate again. Because it is MIT-licensed, you can inspect, change, or fork any layer. See the comparison tables →
Two paths. Drop the question in GitHub Discussions — we (and the community) will answer. Or ask your agent: point it at the GitHub repo, this site's AGENTS.md, or the machine-readable /agents.json manifest, and ask it to explain. KDCube is built for agents to understand — Claude Code, Cursor, GPT, Gemini CLI all parse the same artifacts.
KDCube grew from production requirements and runs real deployments. The open-source project changes quickly, so evaluate the tagged release and tests for the exact surfaces your product requires rather than relying on a blanket maturity label.
No. Keep LangGraph, CrewAI, Claude Agent SDK, custom Python, or another agent implementation and place a thin KDCube app boundary around it. KDCube can add serving, identity, streaming, conversation storage, files, isolation, and economics incrementally. The included native ReAct agent is an option when you want a ready semantic-channel agent. KDCube with agent frameworks →
An app is a self-describing deployable package: runtime composition plus synchronized interfaces, configuration templates, storage ownership, documentation, tests, and release metadata. It may expose any combination of API, UI, chat, MCP, named services, integrations, events, or jobs; none is universally required. bundle_id, bundles.yaml, and related names are retained technical identifiers. Application SDK →
Keep deployment non-secrets in bundles.yaml and deployment secrets in the configured secrets lifecycle. One running KDCube deployment has one effective tenant/project; use separate deployment configurations for independently operated customer or environment boundaries. Within a deployment, typed User Settings hold durable user choices and user-scoped secrets hold personal credentials. The app code stays the same.
KDCube is self-hosted and MIT-licensed. Run it locally with Docker Compose or deploy it using your own container and cloud infrastructure. The repository includes deployment patterns; you retain control of the runtime and its backing services.
You choose where KDCube, Postgres, Redis, filesystem storage, and artifact storage run. Data leaves that boundary only through services you configure, such as an LLM, web search, MCP server, or connected provider account. In the reference split profile, generated code runs in a separate networkless executor without platform credentials; trusted tools and app code perform approved external calls under the carried request identity. Review your deployment and provider configuration for your exact data-residency requirements. Security boundaries →
There isn't one. MIT, free, fork it, ship it in a commercial product if you want. The only thing we ask is that you keep the license file.
There is no KDCube license fee. You pay for the infrastructure and external providers you choose. KDCube records metered spending events so costs can be attributed and budgeted per user, app, conversation, turn, agent, and provider. A turn has no fixed price; its cost is the sum of its spending events.
A small engineering team with more than ten years of building data and application platforms. KDCube grew from recurring production requirements: concurrent users, durable conversations, controlled execution, integrations, storage, deployment, and accountable spend.
Yes. We want builders to try the open-source runtime, tell us where integration is difficult, and contribute fixes or use cases. The MIT-licensed repository is the product you can run and inspect.
The code is MIT-licensed and source-available — it's yours regardless. We're invested in this for the long arc, but a community that owns the platform doesn't depend on us being around.
They can be complementary. Keep the agent graph or orchestration you already built and host it behind a KDCube app boundary. KDCube contributes the surrounding application framework and runtime: serving, ordered conversation delivery, streaming, identity, files, isolated execution, integrations, deployment, and economics. KDCube with agent frameworks →
Use a managed runtime when outsourcing operations and accepting its cloud, service, and extension boundaries is the right tradeoff. Use KDCube when you need a self-hosted, inspectable, MIT-licensed runtime and want to choose the models, storage, tools, UI surfaces, and infrastructure. See one comparison →
KDCube is code-first and centers deployable apps with backend and frontend surfaces, one or many agents, explicit provider/consumer contracts, isolated execution, and runtime economics. Visual flow products optimize a different authoring experience. Choose based on whether your team wants a visual assembly surface or an application/runtime SDK it can extend in code. See the application-builder comparison →
GitHub Issues for bugs and feature requests. GitHub Discussions for everything else — design questions, ideas, "is this the right approach", and general Q&A. Pull requests welcome.
Have a question we missed? That's the one we want.
Continue on GitHub Discussions →