2026.09.14
bex: Bringing a Git Deployment Control Plane to Your Infrastructure
bex is an Apache-2.0 licensed, self-hosted PaaS for teams that want Git-based deployments and one control plane for people and coding agents. Its scope is broad, but the project explicitly says it is not ready for production workloads.
What the project is for
bex targets developers and platform teams that want a hosted-PaaS-style workflow without placing the entire application control plane on an external provider. Its central path is to take source from Git, build it, deploy it, and run the resulting services on infrastructure owned or managed by the user. Coding agents are treated as first-class users: the dashboard, REST, GraphQL, MCP, CLI, and Kubernetes resources operate against the same control plane rather than making important actions dashboard-only.
The project is licensed under Apache-2.0. Its README describes it as an AI-native alternative to Render, but that should be read as a project direction, not as a guarantee of feature parity or production maturity.
Image source: bex. Published by the project; the interface may vary by version.
Known capabilities
bex lists Dockerfile deployments as well as native build paths for Go, Node.js, Python, Ruby, Rust, and Elixir. It supports Render-style render.yaml Blueprints. The service model includes web and private services, background workers, cron jobs, and static sites. Data services listed by the project include managed PostgreSQL and a Valkey-compatible Key Value service.
Operational features represented in the project include deployment history, cancellation and rollback, logs and live tailing, metrics, events, suspend, resume, restart, custom domains, TLS, SSH, and a browser shell. Delivery features include a GitHub App, private repositories, push-to-deploy, multi-resource Blueprints, registry credentials, and outbound webhooks. Team and agent-oriented features include workspaces, projects and environments, roles, OAuth 2.1, API keys, audit logs, usage metering, MCP, managed sandboxes, and machine-readable state.
This list does not mean every interface is available by default. The README says some capabilities require optional backing services or explicit configuration. The project’s parity ledger is the stated source of truth for the exact REST, GraphQL, MCP, and UI status of each capability.
Image source: bex. Published by the project; the interface may vary by version.
Who may benefit
bex is relevant to engineers exploring self-hosted PaaS design, GitOps, Kubernetes Operators, or deployment workflows for coding agents. It may also suit teams experimenting with a shared developer control plane across local and self-managed cloud infrastructure. Its design is particularly relevant when deployment actions need to be exposed to automation while Kubernetes resources and structured state remain available.
Limitations before adoption
The most important limitation comes from the project itself: bex is in active development and is not ready for production workloads. APIs and configuration may change. A feature table in the README should therefore not be treated as evidence that bex is a mature replacement for an established production platform. Compatibility should be checked capability by capability rather than inferred from the phrase “Render alternative.”
Self-hosting also brings infrastructure and component responsibility. The local quickstart lists Docker or OrbStack, Go 1.25+, kubectl, kind, and clusterctl. The architecture involves Kubernetes, Cluster API, an Operator, a control-plane database, and a registry. Teams should plan for cluster operations, storage, networking, domains, TLS, credentials, backups, and access control, and confirm that any optional backing services required by their target features are configured.
For evaluation, start with the project’s examples and local production-shaped cluster, then verify the required interfaces, resource lifecycles, logs, rollback behavior, data services, and agent permissions. The official release page records bex CLI 0.2.1, but that release detail does not establish production readiness for the platform as a whole.
Sources
Sources checked: 2026-09-14