Bex is an open-source application platform for deploying Git repositories and container images. Use it to run web services, private services, background workers, scheduled jobs, and static sites alongside PostgreSQL and Key Value. Developers and coding agents can operate the platform through the dashboard, CLI, REST, GraphQL, or MCP.
Bex is a public alpha under active development. The project README describes its current readiness; API and configuration contracts can change.
Choose your starting point
- Deploy on hosted Bex: Hosted setup covers account, invitation, workspace selection, and payment readiness, then hands off to Web services.
- Outbound events: Outbound webhooks registers a signed HTTPS receiver; Notifications covers personal email and push preferences.
- Deploy an application you already have a workspace for: start with Web services, or compare service types for workers, static sites, and jobs.
- Deploy from an agent: Connect an agent covers authentication and the MCP interface.
- Keep configuration in Git: use a Render-style
render.yamlBlueprint. Validate the file against Bex before applying it. - Try the operator locally: the Quickstart provisions a Docker-backed Kubernetes cluster and runs a sample container.
- Downloadable examples: the examples catalog lists complete runnable projects by task, with guides and ZIP archives — no private CMS checkout required.
- Understand spend before the invoice: Month-to-date usage reads the workspace's metered totals with coverage states and an advisory estimate, so the invoice never surprises you.
- Host the platform yourself: follow the source repository's infrastructure runbook. After install, rehearse isolated restores with Platform recovery.
From source to a running service
For a Git-backed service, Bex builds the selected source revision and deploys the resulting artifact. For an image-backed service, it deploys the supplied container image. Service type determines how that artifact runs: an HTTP service, a long-running worker, a scheduled job, or published static content.
Public web services use the instance's configured platform domain, such as
onbex.co, and can also use custom domains. Public routing
and TLS depend on the instance's domain, ingress, and certificate
configuration. The local operator quickstart uses port forwarding to reach its
sample; it does not provision a public HTTPS endpoint.
After deploying, use logs, metrics, and health checks to understand application behavior. See How deploys work for the release lifecycle, or CI deploys a tested image digest when GitHub Actions must promote the exact image it tested.
How the platform fits together
The Bex API stores product configuration and projects desired state into
Kubernetes resources. The operator reconciles those resources into workloads,
networking, and build activity. Applications use App resources; managed
PostgreSQL and Key Value have their own resource types.
Cluster API provisions the machines underneath the app cluster. The local setup uses Docker-backed machines; the Hetzner setup uses a different provider configuration. A complete platform installation also needs the API and its backing services. Running the operator alone is useful for development, but does not install the dashboard or authenticated product APIs.
For implementation details, read the architecture.
Coming from Render
Bex offers familiar deployment workflows and a compatible subset of Render's Blueprint contract. Compatibility varies by feature and interface; a field accepted by Render is not automatically supported by Bex. Start with Migrate from Render and the compatibility guide.