Bex is in active development. Its upstream project currently states that it is not ready for production workloads and that APIs and configuration can change. This page describes compatibility boundaries; it does not promise a fixed support window or permanent compatibility for every existing request.
These rules concern Bex platform. Bex router's blockchain RPC access keys and network endpoints are a separate product; do not use router credentials to authenticate to platform services.
API versions and clients
The platform REST API uses /v1; GraphQL uses /graphql and MCP uses /mcp.
The REST prefix is an API namespace, not a guarantee that every behavior beneath
it is frozen. See API authentication for token exchange and access.
Bex implements many Render-shaped operations. Check endpoint URLs and response shapes against the installed version; compatibility is specific to each operation and field:
- Use resource IDs returned by Bex rather than assuming names are IDs.
- Tolerate additional response fields, but validate fields your workflow needs.
- Inspect HTTP errors, GraphQL
errors, and MCP tool errors separately. - Do not rely on undocumented ordering, exact human-readable error text, or another API adapter's input names.
- Check permissions and OAuth scopes as well as request shape.
A Render client recognizing a response does not prove its entire workflow is supported. Render parity links the implementation evidence; Migrate from Render covers the practical checks. For per-command CLI grades, see the CLI reference. For per-operation REST grades, see the API reference.
Blueprint compatibility
Use render.yaml with the current Blueprint grammar.
bex.yml is a deprecated filename alias, not a second manifest dialect.
Bex validates against its pinned schema and supported capabilities. Unknown or
unsupported fields can fail validation; they are not a reliable way to request
behavior that Bex silently ignores. For example, autoDeployTrigger: checksPass
requires CI-check gating that Bex does not implement.
Validate the exact manifest against the destination installation before applying it. A valid plan can still fail during provisioning or deployment because of capacity, credentials, networking, or a backend outage. Removing a resource from a manifest does not delete it automatically.
Before an upgrade
- Record the Bex version or commit, CLI version, and manifests you currently use.
- Review the upstream release/change notes and this site's changelog.
- Validate manifests and exercise your actual REST, GraphQL, and MCP workflows against the candidate version in a separate environment.
- Check authentication, create/update/read flows, deployment readiness, and data recovery requirements. Keep a recovery plan appropriate to the changes.
Do not infer an automatic migration or rollback guarantee from an unchanged API URL. A workload image rollback also does not roll back the Bex control plane, configuration schema, or application data.
Why no versioned docs
This site maintains one current documentation set; there are no versioned documentation trees. It does not implement a compatibility-date mechanism. Self-hosted installations can lag behind these pages, so compare the docs with the source and release notes for the version you run.
Report a reproducible discrepancy with the Bex version, endpoint or tool name, and a redacted request in the Bex issue tracker.