bex Is in Public Alpha: What Ships Today, What It Costs, and What 'Alpha' Means for the Open-Source, Agent-Operable Render Alternative

Today we are calling it what it is: bex is in public alpha. Anyone can sign up at dashboard.bex.co, connect a GitHub repository or paste a render.yaml, and get a health-gated HTTPS service on <name>.onbex.co — or clone the Apache-2.0 repository and run the identical platform on a laptop or a €9 Hetzner box. This is the product manager's version of the announcement: not the pitch, but the ledger. What is in the alpha, what is deliberately not, what it costs, what "alpha" commits us to, and what has to be true before we call it 1.0.

The alpha in one table​

Here is the deliverable up front. Every row below is live on hosted bex.co today and in the open-source repository; the right-hand column names the record that proves it, because "Render-compatible" is a claim we track row by row, not a slogan.

And the other half of the ledger, which a launch post usually leaves out:

If your workload needs anything in the second table, the honest advice is to wait or to self-host and watch the parity ledger.

What "public alpha" actually means​

Alpha is a word teams use loosely, so here is the precise definition bex is shipping under. Five statements, each backed by a decision record in the repository.

1. Signup is open, and billing is real. Hosted bex.co is a paid product. Registration is card-free, but a bound payment method is required before any resource is created — including free-tier resources. That is a deliberate abuse gate for a compute platform, not a growth tactic, and it comes with a first-class exit: every payment wall in the dashboard links to "Self-host bex instead." The open-source project is the free path, and it is not a demo; the hosted product runs the same code (ADR075, ADR046).

2. It is not for production workloads. The README says so in a warning box, and we mean it. APIs and configuration can change. The core platform is continuously tested and has been serving our own sites since July, but the promise we are making is "explore, contribute, and tell us where it breaks," not "put your revenue on it."

3. Platform services carry no version numbers yet. Until 1.0, the operator, API, SSH gateway, and dashboard are identified by image digest plus git SHA in a GitOps pin ledger, deployed continuously from main. The bex CLI rides its own bex-cli/v0.x train, and 0.x explicitly means "pre-convergence." At 1.0 everything jumps to one shared bex/vX.Y.Z version, Kubernetes-style, with a documented skew policy (ADR058).

4. Compatibility is a ledger, not a promise. ADR018 records every Render capability across REST, GraphQL, MCP, and the dashboard with a pointer to the code or spec that proves each cell. The unmodified Render CLI (v2.27.0 at the time of writing) is graded per command against a live bex. Divergences are written down rather than hidden: previews are refused, the region flag is stamped by the platform, Datadog forwarding returns a named 400.

5. The exit is git clone. The hosted service and the self-hosted platform are the same repository at the same commit. Your app definition is a portable render.yaml. If bex disappoints you, leaving is a redeploy, not a migration project.

What ships: a short tour​

The vision document lists five pillars, and all five are marked shipped: Render-compatible REST and GraphQL, agent-readable state, an MCP server, deploy-from-chat, and E2B-compatible sandboxes. Here is what that looks like from the reader's side.

One manifest, every interface​

A service is declared with the render.yaml shape many teams already have. This is the repository's own multi-resource example: a web service and a worker wired to a managed Postgres, with the connection string resolved to a Kubernetes secret reference so the credential never appears in the file.

services:
  - name: web
    type: web
    runtime: docker
    repo: https://github.com/bex-co/bex
    rootDir: examples/stack-demo
    plan: free
    healthCheckPath: /healthz
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: db
          property: connectionString
  - name: worker
    type: worker
    runtime: docker
    repo: https://github.com/bex-co/bex
    rootDir: examples/stack-demo
    envVars:
      - key: ROLE
        value: worker
      - key: DATABASE_URL
        fromDatabase:
          name: db
          property: connectionString
databases:
  - name: db
    plan: free

The Blueprint compiler turns that into App and Database custom resources. The Go operator builds the source with in-cluster BuildKit workers, pushes to a Zot registry, rolls the workloads out, configures Traefik routing and cert-manager TLS, and reports structured status back. Blueprints compile fail-closed: anything bex cannot honor is refused up front with a named error, never silently dropped.

The same create is available from the dashboard form above, the REST API, GraphQL, the bex CLI, an MCP tool, or kubectl apply. There are no dashboard-only actions. That rule is structural: every adapter is a thin layer over one Go core, so authorization and lifecycle behavior cannot drift by interface.

Deploys you can follow and undo​

Every deploy is a first-class object with an eleven-state lifecycle, real transition timestamps, the git commit it built, and a rollback button that redeploys a prior resolved image. The screenshot is one of our own services: 90 revisions in, deployed from a GitHub push, with the previous deploys one click from being live again.

Under it sit the operational surfaces Render users expect: live log tailing with structured request-log filters, CPU and memory metrics with deploy markers, an event feed, suspend and resume, scaling, and SSH into a running instance through a gateway with a pinned host key.

State an agent can read​

The App resource reports the three facts an operator or an agent needs without scraping anything:

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

That contract — phase, revision, url — is treated as stable even in alpha, because it is the thing agents retry and reason about.

Agents are first-class operators, not an integration​

The founding thesis is that the next wave of deployments will not be typed by humans. So bex-api serves the whole verb set over MCP at https://api.bex.co/mcp, using the standard MCP authorization flow: an unauthenticated call returns a 401 with an RFC 9728 resource-metadata hint, the client self-registers via dynamic client registration, runs an authorization-code PKCE flow against the dashboard login, and lands on a consent screen that names the agent and the scopes it asked for.

For Claude Code that is one line:

claude mcp add --transport http bex-api https://api.bex.co/mcp

Scopes are granular: bex.read for reads, bex.write for mutations, bex.sensitive for secrets. Identity-only scopes never confer API authority, and workspace roles still apply to every call. Headless clients and CI exchange an API key for a 15-minute bearer token instead.

Counting the tool registrations in the backend source gives 179 MCP tools at the time of writing: the Render-shaped ones (list_services, get_service, create_web_service, trigger_deploy) plus bex extensions Render's own MCP server does not have — rollback_deploy, scale_service, update_service with a dryRun preview, get_usage with the cost estimate, webhook and API-key management, Postgres users and recovery, and the sandbox and agent-session verbs. The deploy tool takes a repository plus a render.yaml and returns a live URL in one call. A local mcp-stdio mode serves the same tools to an agent on the same host with no OAuth at all.

Two consequences follow. First, an agent can rotate its own credentials, because API keys are a workspace-scoped, revocable resource over the API rather than a dashboard-only setting. Second, the 12-factor-agents argument we made in July is now testable against a real server: declarative intent in, converged state out, and every error a structured code an agent can branch on.

What the alpha costs​

Hosted bex.co is priced off Render's public sheet as captured on 2026-07-13, at 30% below Render on workspace plans, compute, Postgres, Key Value, build minutes, and storage, and 90% below on bandwidth. The hosted platform runs on Hetzner-class infrastructure where egress is cheap, and the bandwidth line passes that through rather than marking it up.

The fine print, because it is where evaluations go wrong:

• Free tiers exist but are capped. Free compute is 0.1 CPU and 512 MB, limited to one running instance, and sleeps after 15 minutes without traffic. Free Postgres is 256 MB with 1 GB of storage and no backups, matching Render. Free Key Value is 128 MB. Background workers are paid-only and default to the starter tier.
• A card is required even for free resources. See the definition of alpha above.
• The dashboard estimate is advisory. Every surface shows a month-to-date estimate priced from the rate sheet; Stripe's invoice is the authoritative number and can differ on billing period, credits, and tax.
• Self-hosting is free forever. There are no open-core gates. The pricing page has a side-by-side estimator if you want to plug in your own service list.

Durability and security posture​

An alpha with real billing has to say what happens to your data. Every platform store and every paid datastore has a scheduled backup and a scripted restore, and each restore has been drilled against production, with the date recorded next to the mechanism (ADR031).

Free Postgres has no backups and free Key Value has no off-cluster recovery point, again matching Render's free tiers. Backups are age-encrypted client-side where bex controls the pipeline, and backup writers hold write-only credentials so a leaked key cannot read the archive.

On isolation: each workspace is its own Kubernetes namespace with default-deny network policy, per-tenant resource quotas, per-workspace registry credentials, and secrets held in OpenBao rather than in git or the database. The platform has been through 23 documented security-review rounds, each triaged in a public decision record with per-finding dispositions and regression tests; the GLM and Kimi scan write-up and the Claude Fable scan write-up describe how that loop runs. Two accepted residuals are worth restating rather than letting someone discover them: onbex.co is not yet on the Public Suffix List, and several operator runbooks still assume a single trusted operator.

Get started in ten minutes​

There are three doors, and they lead to the same platform.

Hosted. Sign up, verify your email in place, bind a card on the payment step, and create a service from a repository or a Blueprint. The hosted setup guide walks the readiness steps, and billing setup covers recovery from a PAYMENT_REQUIRED refusal.

Self-hosted, locally. The quickstart boots a production-shaped substrate — a kind management cluster, Cluster API, and an app cluster whose machines are Docker containers — and runs the operator from source:

git clone https://github.com/bex-co/bex.git
cd bex
bash scripts/mock-cluster.sh
export KUBECONFIG="$PWD/infra/local/bex.kubeconfig"
cd lego/operator && make install && BEX_RUNTIME=kubernetes make run

Then, in a second terminal, kubectl apply -f examples/whoami-app.yaml and kubectl get apps.app.bex.co -w. Swap the Docker overlay for the Hetzner one and the same operator runs on real machines; the quickstart has the details.

CLI and agents. The bex CLI is the upstream Render CLI with bex defaults. The installer verifies a Sigstore-signed checksum file, so cosign must be on your PATH; login is a browser device flow:

curl -fsSL https://raw.githubusercontent.com/bex-co/bex/main/scripts/install-bex.sh | sh
bex login
bex services -o json

Coming from Render? The migration guide starts from your existing render.yaml, and the agent guide covers Claude Code, Cursor, and headless clients.

The road to 1.0​

The 1.0 bar is not a feature list; it is a set of obligations. Per ADR058, launch means self-host delivery: a versioned install artifact that installs on a fresh cluster from the docs alone, upgrades from the previous release with CRD and control-plane database migrations, and carries a documented version-skew policy. The CLI leaves 0.x and joins the shared number at that moment.

The gates, as written in the internal launch document, are:

1. The self-host artifact exists, installs from documentation alone, and upgrades from a prior release candidate.
2. Billing runs end to end on real Stripe, from metered usage through sealed export to invoice.
3. The workspace-scoped artifact-identity migration completes before external tenants share registry and object-storage namespaces.
4. The parity ledger and CLI checklist are re-verified at the release-candidate digest set, with divergences published.
5. Restore drills are current for every store in the table above.

Hosting reaches 1.0 first. The agent products — hosted coding-agent sessions and sandboxes with hibernation — are in the alpha and moving fastest, so they will get their own announcement when they clear the same bar rather than dragging an unstable contract into a 1.0 promise.

What we are asking for during the alpha is exactly what an alpha is for: deploy something real but not critical, migrate a Render Blueprint and tell us which row of the ledger lied, connect an agent and tell us which tool description misled it. Roughly 3,000 commits and 88 decision records in the 102 days since the first commit got the platform to this point; the next stretch is decided by what breaks in your hands.

bex is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repository on GitHub, sign up for the hosted alpha, or run the local cluster tonight.