Deploy services from Git

[!WARNING]

bex is in active development and is not ready for production workloads. APIs and configuration can change. The core platform works and is continuously tested; use it today to explore, contribute, and help shape the project.

Why bex

Render, Heroku, and Railway proved the experience developers want: connect a repo, get a URL, and avoid operating Kubernetes by hand. bex makes that experience open source, self-hostable, and programmable by agents.

• A familiar PaaS workflow. Deploy Dockerfiles or native Go, Node.js, Python, Ruby, Rust, and Elixir projects from Git. Use Render-style render.yaml Blueprints and a Render-compatible CLI and API.
• One control plane for humans and agents. The dashboard, REST, GraphQL, MCP, CLI, and Kubernetes resources operate the same core. There are no dashboard-only deployment actions.
• More than a container launcher. Web services, private services, workers, cron jobs, static sites, managed Postgres, managed Key Value, logs, metrics, deploy history, rollbacks, domains, TLS, and SSH are already represented.
• Your infrastructure and your data. Run the same Go operator against Docker-container machines locally or Hetzner machines in production-shaped clusters. The provider overlay changes; the product does not.
• Inspectable by design. The platform is Apache-2.0, its intent is declarative, and its compatibility claims are tracked in an evidence-backed Render parity ledger.

From repo to URL

Declare a service with the same render.yaml shape many developers and tools already understand:

services:
  - name: api
    type: web
    runtime: docker
    repo: https://github.com/your-org/your-app
    branch: main
    plan: free
    healthCheckPath: /health

databases:
  - name: app-db
    plan: free

The Blueprint API compiles that intent into App and Database resources. The operator builds the source, rolls out the workloads, configures routing and TLS, and reports structured status back through every interface. An agent can perform the same deployment with the MCP deploy tool—repo plus manifest in one call.

See the hello-world examples or the full deployment contract.

What ships today

Area	Capabilities
Services	Web and private services, background workers, cron jobs, static sites, Dockerfiles, native builds, health checks, pre-deploy commands, manual and policy-driven autoscaling
Data	Managed PostgreSQL with backups/PITR, HA and read replicas; managed Valkey-compatible Key Value with persistence and backups
Operations	Deploy history, cancel and rollback, logs and live tail, metrics, events, suspend/resume/restart, custom domains and TLS, native SSH and browser shell
Delivery	GitHub App integration, private repositories, push-to-deploy, multi-resource Blueprints, registry credentials, outbound webhooks
Teams	Workspaces, projects and environments, roles with OpenFGA, OAuth 2.1, API keys, audit logs, usage metering and billing integration
Agents	Remote and stdio MCP, OAuth consent, deploy-from-chat, managed sandboxes, cloud coding-agent sessions, structured machine-readable state

Some capabilities require optional backing services or explicit configuration and fail closed when unavailable. For the exact REST · GraphQL · MCP · UI status of every capability, use the parity ledger—not this summary—as the source of truth.

See bex in action

Quickstart

This boots the production-shaped local substrate: a kind management cluster, Cluster API, and an app cluster whose machines are Docker containers.

Prerequisites: Docker or OrbStack, Go 1.25+, kubectl, kind, and clusterctl.

In terminal 1:

git clone https://github.com/bex-co/bex.git
cd bex

# Provision the local Cluster API substrate.
bash scripts/mock-cluster.sh
export KUBECONFIG="$PWD/infra/local/bex.kubeconfig"

# Install the CRDs and run the operator from source.
cd lego/operator
make install
BEX_RUNTIME=kubernetes make run

In terminal 2:

cd bex
export KUBECONFIG="$PWD/infra/local/bex.kubeconfig"

# Deploy a prebuilt image and watch it converge.
kubectl apply -f examples/whoami-app.yaml
kubectl get apps.app.bex.co -w

An App reports the state an operator or agent needs without scraping logs:

NAME      PHASE     REVISION   URL
whoami    Running   rev-1      http://whoami.default.svc:8080

Then add a tenant machine and scale the workload across it:

bash scripts/mock-cluster.sh scale 2
kubectl patch apps.app.bex.co whoami --type merge -p '{"spec":{"replicas":6}}'
kubectl get pods -l app.bex.co/app=whoami -o wide

The first bootstrap downloads the Kubernetes and Cluster API dependencies and can take several minutes. For a full platform deployment, start with infra/README.md; for the Go workspace and development commands, see lego/README.md.

Use the interface that fits

Interface	Best for
Dashboard	Human-friendly service, data, environment, team, usage, and security workflows
bex CLI	Interactive operations and scripts using the upstream Render CLI command implementation (install and compatibility notes)
REST + GraphQL	Product integrations and custom control-plane clients
MCP	Claude Code, Cursor, and other agents over OAuth 2.1 or a headless API key (connect an agent)
Kubernetes CRDs	GitOps, low-level debugging, and direct operator development

All product adapters are thin layers over the same Go core, so authorization, lifecycle behavior, and resource identity do not drift by interface.

How it works

flowchart TB
  developer@{ shape: tri, label: "developer" }
  agent@{ shape: tri, label: "coding agent" }
  dashboard["dashboard (web service)"]
  cli["bex CLI (local client process)"]

  subgraph app_cluster["app cluster"]
    api["bex-api"]
    store[(control-plane Postgres)]
    crds["App · Database · KeyValue (Kubernetes objects)"]
    operator["bex operator"]
    registry["Zot registry"]
    runtime["tenant runtime (Kubernetes workloads and routes)"]
    capi["Cluster API controllers"]
    nodes["worker nodes (machines)"]
  end

  developer --> dashboard
  developer --> cli
  agent -->|MCP| api
  dashboard -->|GraphQL| api
  cli -->|REST| api
  api --> store
  api -->|projects desired state| crds
  operator -->|watches and reconciles| crds
  operator -->|builds and pushes images| registry
  runtime -->|managed by| operator
  runtime -->|pulls images| registry
  runtime -->|runs on| nodes
  nodes -->|provisioned by| capi

Arrows point from a consumer to what it depends on. bex-api owns durable product intent; the database-free operator turns projected Kubernetes objects into workloads; Cluster API provisions the machines beneath them; and operator → types ← backend remains the one-way code dependency described in the architecture panorama.

lego/
  types/       App, Database, and KeyValue CRD contracts
  operator/    Kubernetes manager: reconcile, build, runtime, config
  backend/     bex-api and the isolated SSH gateway
  cli/         bex CLI launcher (imports the pinned upstream Render CLI)
dashboard/     TanStack Start + Apollo + shadcn web application
mobile/        Expo client for safe supervision workflows
infra/         Terraform + Cluster API: local CAPD and Hetzner CAPH
deploy/gitops/ Argo CD platform infrastructure
examples/      Image, Git, static, cron, and multi-resource samples
docs/          Architecture decisions, contracts, runbooks, and evidence
scripts/       Local-cluster, deployment, security, and verification tools

Project status

bex is a working public alpha with a live, production-shaped architecture and broad Render compatibility. It is also a large surface area under rapid development. The project makes that tradeoff explicit:

• Vision and product thesis
• Evidence-backed Render parity and known gaps
• Architecture and trust boundaries
• CLI compatibility checklist
• Contributing guide

Help build the open cloud

If you want a PaaS that agents can operate and developers can own, star the repository, try the local cluster, and tell us where the experience breaks. Issues and pull requests are welcome; agent-authored contributions are welcome when the author has reviewed the diff and the tests pass.

Apache-2.0 licensed. See CONTRIBUTING.md and the Code of Conduct.