// the take
bex is a self-hosted PaaS that copies the Render/Heroku git-push-to-URL workflow on your own Kubernetes infrastructure, with a Go operator reconciling App/Database/KeyValue CRDs and Cluster API provisioning the underlying machines (Docker locally, Hetzner in prod). It's aimed at teams who want Render's UX without the vendor lock-in, and specifically markets itself as something coding agents can drive through MCP, not just humans through a dashboard. Good fit for someone evaluating self-hosted PaaS options who's comfortable running Kubernetes and wants agent-operable infra from day one.
The architecture separates concerns properly: bex-api owns durable intent, the operator is database-free and just reconciles projected K8s objects, Cluster API handles machine provisioning underneath — that's a real production-shaped design, not a toy wrapper around kubectl. All interfaces (dashboard, CLI, REST, GraphQL, MCP, raw CRDs) go through the same core, so there's no dashboard-only escape hatch that breaks agent or API-driven workflows. They track Render compatibility claims in an evidence-backed parity ledger (ADR018) instead of just asserting compatibility in the README, which is the right way to handle compat claims nobody can verify otherwise. MCP is treated as a first-class deploy path (repo + manifest in one call), not a bolted-on wrapper, which matches the stated thesis better than most 'AI-native' claims do.
The README says outright it's not ready for production workloads and APIs can still change — that's an honest warning, but it means anyone adopting now is signing up for churn. The surface area is enormous for a 574-star project: operator, Cluster API controllers, backend, dashboard, mobile app, GitOps platform infra, and a CLI — that's a lot to maintain and review with what's likely still a small contributor base, and the bus-factor risk is real. The CLI isn't bex's own code, it imports 'the pinned upstream Render CLI command implementation' — so CLI compatibility is borrowed from an external project bex doesn't control, and if that upstream changes or stops being maintained, bex inherits the problem. The quickstart is not actually quick: kind, Cluster API, clusterctl, and a multi-minute first bootstrap just to get a local cluster running, which is a much higher bar than Render's actual pitch of 'connect a repo, get a URL.' The feature table also notes several capabilities 'fail closed when unavailable' and need optional backing services, so the README's breadth overstates what you get without extra configuration work.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →