# bex: a self-hosted, agent-first PaaS that speaks Render's language

> bex is an Apache-2.0 Go operator that turns a Kubernetes cluster into a Render-style PaaS, with a Blueprint API, MCP access for agents, and a stated goal of Render parity. It is not production-ready yet, but the architecture is concrete enough to evaluate today.

**bex-co/bex** — The open-source Render alternative — AI-native. Git push → build → deploy on your own infrastructure; agents are first-class users.

- Repository: https://github.com/bex-co/bex
- Website: https://bex.co
- Stars: 569 · Forks: 64
- Language: Go
- License: Apache-2.0
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/bex-co-bex

## What bex actually is

bex is an open-source platform that aims to reproduce the Render experience on infrastructure you control. The README positions it as an AI-native alternative to Render, Heroku, and Railway, meaning it treats coding agents as first-class users, not an afterthought. The project is written in Go and licensed under Apache-2.0. The core is a Kubernetes operator that compiles a Render-style render.yaml blueprint into App and Database resources, then builds source, rolls out workloads, configures routing and TLS, and reports structured status back through every interface. The target audience is developers who want the convenience of a PaaS without handing over their data or infrastructure to a hosted vendor. It is also for teams that want to give their agents the same control plane as their human developers, with no dashboard-only actions.

## The Blueprint API and the operator's job

The central mechanism is the Blueprint API. You declare a service in a render.yaml file with fields like name, type, runtime, repo, branch, plan, and healthCheckPath. The README shows a minimal example: a web service named api with a Docker runtime and a free plan, plus a database named app-db. The operator takes that intent and compiles it into App and Database resources. From there it builds the source, rolls out the workloads, configures routing and TLS, and reports status. The status is structured, not just log lines. The README shows an App resource reporting PHASE, REVISION, and URL in a table format. That structured state is what an operator or an agent can consume without scraping logs. The same deployment can be triggered by an agent through the MCP deploy tool, which takes a repo and a manifest in one call. This is a meaningful design choice: the control plane is not a separate API for humans and another for machines. It is one core, exposed through multiple interfaces.

## Getting it running: a multi-step local bootstrap

The quickstart in the README is not a single command. It requires Docker or OrbStack, Go 1.25 or newer, kubectl, kind, and clusterctl. Terminal 1 clones the repo, runs scripts/mock-cluster.sh to provision a local Cluster API substrate, exports a kubeconfig from infra/local/bex.kubeconfig, then installs CRDs and runs the operator from source with BEX_RUNTIME=kubernetes make run. Terminal 2 applies an example manifest with kubectl apply -f examples/whoami-app.yaml and watches it converge with kubectl get apps.app.bex.co -w. The README warns that the first bootstrap downloads Kubernetes and Cluster API dependencies and can take several minutes. Scaling is also done through kubectl: you patch the App resource to change replicas, then check pods with a label selector. This is not a turnkey installer. It is a developer workflow for people who already know Kubernetes. The project also points to infra/README.md for a full platform deployment and lego/README.md for the Go workspace, but those files are not included in the material I have.

## What ships today and what fails closed

The README lists a broad feature set: web and private services, workers, cron jobs, static sites, Dockerfiles, native builds for Go, Node.js, Python, Ruby, Rust, and Elixir, health checks, pre-deploy commands, autoscaling, managed Postgres with backups and read replicas, managed Valkey-compatible Key Value, deploy history, rollbacks, custom domains with TLS, SSH, and a browser shell. It also mentions a GitHub App integration, private repositories, push-to-deploy, webhooks, workspaces with OpenFGA roles, OAuth 2.1, API keys, audit logs, usage metering, and billing integration. On the agent side, it lists remote and stdio MCP, OAuth consent, deploy-from-chat, managed sandboxes, and cloud coding-agent sessions. But the README is careful to say that some capabilities require optional backing services or explicit configuration, and they fail closed when unavailable. That is an honest caveat. It means you cannot assume a feature works just because it is listed. You have to check the parity ledger, which is the source of truth, not the summary table.

## The Render parity ledger: a real commitment or a marketing device?

The project maintains a Render parity ledger at docs/ADR018-render-parity.md. The README says it is evidence-backed and tracks compatibility claims for the REST, GraphQL, MCP, and UI status of every capability. This is an unusual move for an open-source project. Most projects just claim compatibility and let users discover gaps. bex tries to make the gaps explicit and tracked. That is a genuine strength for evaluation. But it also reveals a limitation: the project is not aiming for a superset of Render. It is aiming for parity, which means there will be features in Render that bex does not have, and the ledger is where you find out which ones. The README explicitly says to use the ledger as the source of truth, not the summary. That is a good sign for transparency but a warning for anyone expecting a drop-in replacement today. The ledger itself is not in the material I have, so I cannot say which specific features are missing. The point is that you must check it before adopting.

## Where bex is the wrong tool

The README is blunt: bex is in active development and not ready for production workloads. APIs and configuration can change. That alone rules it out for teams that need a stable platform for customer-facing services. The local quickstart also assumes you are comfortable with kind, clusterctl, and Kubernetes concepts. If you are a developer who just wants to deploy an app without learning Kubernetes, bex is not for you. The project is also wrong for teams that need a fully managed service with no operational burden. The whole point is to run it on your own infrastructure, so you take on the operational cost of running a Kubernetes operator. Finally, if you need a feature that is not in the parity ledger, you will have to wait for the project to add it or build it yourself. The fail-closed design means missing backing services will disable features silently, which could be a trap if you do not read the ledger.

## The alternative: Render itself, or a Kubernetes-native PaaS like Kubevela

The obvious alternative is Render, the hosted service that bex is trying to match. Render gives you the same render.yaml workflow, but you do not own the infrastructure. That is a real difference in approach: Render is a managed multi-tenant platform, while bex is a self-hosted operator that runs on your own machines. If you want to avoid operating Kubernetes, Render is the better choice. If you want to keep data and control, bex is the direction. Another alternative is Kubevela, which is also a Kubernetes-based application delivery platform, but it does not use Render's blueprint format and it is not agent-first by design. Kubevela focuses on platform engineers building internal developer platforms, not on giving coding agents a direct control plane. bex's MCP support and its explicit goal of making agents first-class users are the differentiators. If your main need is agent-driven deployment, bex is more aligned. If you need a mature, battle-tested platform, Kubevela or a hosted PaaS is safer.

## Maintenance, licensing, and what to verify before you commit

The project is Apache-2.0, which means you can use it, modify it, and distribute it without paying a license fee, as long as you preserve the license notice. That is a permissive license, which is good for adoption, but it also means there is no warranty or support guarantee. The README shows recent releases, including bex-cli/v0.1.0 from August 2026, and the last push is the same day, so the project appears active. But activity does not equal stability. The README's warning about API changes is the key maintenance cost: you will need to track updates and adapt your blueprints and configuration as the project evolves. The project also has a CONTRIBUTING.md, which suggests the maintainers expect outside contributions, but that is not a promise of long-term maintenance. Before you commit, verify the parity ledger for the exact capabilities you need, test the MCP deploy tool in a local sandbox, and check whether the project has a roadmap for production readiness. The quickstart itself is a good first test: if you cannot get the whoami example running, the project is not ready for you.

## Conclusion

Adopt bex if you want a self-hosted PaaS that treats coding agents as first-class users and you are comfortable with early-stage software: the README warns it is not production-ready, APIs may change, and the local setup requires Go 1.25+, kind, clusterctl, and a multi-step bootstrap. Do not adopt it if you need a stable, supported platform for critical workloads today; Render, Heroku, or Railway remain safer choices. Before committing, verify the Render parity ledger (docs/ADR018-render-parity.md) for the exact status of the REST, GraphQL, MCP, and UI capabilities you depend on, and test the MCP deploy tool in a sandbox to see if agent workflows actually meet your needs. The core operator runs, but its future depends on how quickly the project moves past the warning in its own README.

## FAQ

### What is bex?

It is an open-source alternative to Render that deploys from Git to HTTPS on infrastructure you own. A Blueprint API compiles render.yaml into App and Database resources, and a Go operator builds the source, rolls out workloads, and configures routing and TLS.

### Is bex ready for production workloads?

The project says it is not ready for production workloads, that APIs and configuration can change, and that the core platform works and is tested. It invites you to use it to explore, contribute and help shape the project.

### How do I run bex locally?

You need Docker or OrbStack, Go 1.25 or newer, kubectl, kind and clusterctl. Then run bash scripts/mock-cluster.sh, export KUBECONFIG from infra/local, cd lego/operator, run make install and BEX_RUNTIME=kubernetes make run, and in a second terminal apply examples/whoami-app.yaml and watch the App resource converge.

### Why does bex point at a parity ledger instead of its own feature list?

Because the summary table is not the source of truth. The ledger is named as the authority for the exact REST, GraphQL, MCP and UI status of every capability, since some capabilities need optional backing services or explicit configuration and fail closed when those are unavailable.

### How does bex handle TLS certificates and SSH keys?

Both are passed as file paths rather than as key material. The certificate and unencrypted key are uploaded into the protected production-deploy environment by a script, the deploy workflow installs the certificate over standard input, and bex never calls the DNS provider.

## Sources

- [Official documentation](https://bex.co)
- [Official README](https://github.com/bex-co/bex#readme)
- [Project repository](https://github.com/bex-co/bex)
- [Release notes](https://github.com/bex-co/bex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bex-co-bex