Q&A
Most of these come up as the fleet grows — once one AI mini-app becomes several. Bring more on GitHub Discussions; push back on the answers.
The work shifts from building to operating. Each app needs its own operational layer, and that layer multiplied across the fleet becomes the engineering problem. KDCube is what we built for that. Read the full story →
When you ship the second app — or the second customer with different constraints. One bundle on its own: optional. Two sharing tenancy, budgets, and audit: KDCube pays off. See in comparison →
You can. Six to twelve months of focused engineering, give or take. KDCube exists because we did exactly that, several times, before extracting it. If you'd rather start from a runtime and modify what doesn't fit, fork — that's what MIT is for. See the full feature matrix →
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.
It runs in real production deployments today. A few subsystems (managed multi-region, hosted control plane, advanced compliance forwarders) are still maturing on the roadmap.
Bring your own. LangGraph, CrewAI, plain Python — anything that runs inside a bundle. ReAct v3 is the included loop, not the required one; it's there because we needed it ourselves. KDCube vs. LangGraph →
An app's code, its surfaces (REST, widgets, full UI, MCP, scheduled jobs), and its config — packaged as one unit. Hot-reloadable; deploy without restarting workers. Bundle docs →
Bundles run against a (tenant, project, user) context resolved at admission. Per-customer configs and secrets live in the deployment descriptor, not the code; storage, budgets, and audit inherit that scope automatically.
Self-hosted today — Docker Compose, Kubernetes, or ECS/Fargate via Terraform. A managed KDCube.cloud service is on the roadmap; it'll run the same open-source runtime, not a fork.
Stays in your VPC. Postgres, Redis, S3 — all yours. The only outbound traffic is what you choose to send to LLM providers and external tools, with your own keys. vs. Bedrock (AWS-managed) →
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.
Infrastructure-only — Postgres, Redis, your own LLM provider keys. No license fee, no per-seat pricing, no usage tier. A laptop is enough to develop; production cost depends on your workload.
A small team with more than ten years of building data and apps platforms across customers. We've watched the same problem hit on different platforms — apps multiply, the operational layer becomes the bottleneck. KDCube is the runtime we kept rebuilding underneath them, finally extracted into one place. By choice we operate in shadow mode — we'd rather the deliverable speak for itself than the personalities behind it.
Yes — and we say that openly. We want users, contributors, and feedback from people who've hit the same wall. Nothing is gated behind a paid tier; the open-source runtime is the product.
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.
Different shape. Those are agent-loop libraries — you decide how to host them, how to isolate tenants, how to bill, how to deploy. KDCube is the runtime around the loop: tenancy, budgets, audit, deploy. Run LangGraph or CrewAI inside a bundle and KDCube handles the rest. vs. LangGraph → · vs. CrewAI →
Yes, on AWS, with Bedrock as the substrate and limited surface choices. KDCube runs on your infra (Compose, Kubernetes, ECS/Fargate), is MIT-licensed, exposes its internals, and lets you bring your own LLM provider keys. Use Bedrock Agents if you want the AWS-managed answer; use KDCube if you want a runtime you can reason about and rehost. vs. Bedrock AgentCore →
Closer in shape than the others, but those lean no-code / low-code-first and are organised around prompt flows. KDCube is code-first (a Python SDK) and treats tenancy, budgets, and isolated execution as platform primitives, not workspace settings. If you want flow-builder UX, look at them; if you want a runtime your engineers will live in, look here. See LLM-app-platform tab →
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 →