Bex provides a Render-style platform with many Render-shaped APIs and Blueprints. Compatibility is checked per operation; it is not a promise that all Render features, plans, clients, or operational guarantees carry over.
Bex is in active development and is not currently recommended by its upstream project for production workloads. Use this page to scope an evaluation, then verify the workflows your application needs on the installation you will run.
Parity at a glance
| Area | Status | Bex workflow | Boundary to check |
|---|---|---|---|
| Git and builds | Supported | GitHub integration, Dockerfile and supported native-runtime builds | Repository authorization, runtime commands, monorepo paths, and auto-deploy policy; no assumption of every Git provider. |
| Image deployment | Supported | Docker images, including registry credentials | Registry access and the runtime's image/architecture requirements. |
| Blueprints | Supported | render.yaml validation and apply | Pinned schema, unsupported fields, and no automatic deletion of removed entries. |
| Domains and TLS | Supported | Domain verification and certificate management, including www/apex pairing | Configured routing and issuer, ownership TXT records, and DNS for each hostname. |
| Configuration | Supported | Environment variables, secret files, and groups | Credential-store availability, permissions, replacement semantics, and rollout effects. |
| Service operations | Supported | Restart, suspend, resume, scaling, deploy history | Type/plan restrictions, asynchronous status, and storage-dependent downtime. |
| Health and observability | Supported | Health checks, logs, metrics | Backend configuration, retention, and what readiness actually proves. |
| Rollback | Supported | Redeploy a prior resolved image | Does not restore historical environment/settings or data; auto-deploy remains enabled unless changed separately. |
| Postgres | Supported | Managed databases, connections, backups/recovery, and capacity features | Plan, backup storage, recovery window, network access, and upgrade downtime. |
| Key Value | Supported | Managed Valkey, eviction and persistence controls | Persistence differs from a user-accessible backup/restore workflow. |
| Persistent storage | Supported | Persistent disks, growth, and configured snapshots | Paid eligible services, one instance, no autoscaling, and deployment interruption. |
| Team organization | Supported | Workspaces and roles, projects and environments | Plan limits, role/scopes, and protected-environment restrictions. |
| Running-instance access | Supported | SSH and dashboard shell for eligible paid services | Configured gateway; requires sensitive-resource access, not merely permission to restart. |
| Notifications | Partial | Deploy preferences and signed webhooks | Configured delivery providers and the actual advertised event set. |
Availability in one adapter does not establish identical arguments or behavior in REST, GraphQL, MCP, and the dashboard. Use the guide and the schema for the interface you call.
Known gaps and non-goals
Plan separately for PR preview environments, enterprise SAML/SCIM provisioning,
external log/metric streams, dedicated outbound IPs, and Render Workflows.
Bex implements one-off jobs, but their containers do not
inherit the parent service's environment, volumes, registry credentials, or
resource requests. The accepted planId is recorded, not applied to container
resources. Running-instance SSH and scheduled cron jobs are different workflows.
Maintenance mode and workspace audit logs are implemented with their documented access and installation requirements.
Render-specific regions, instance plans, and infrastructure/compliance programs are not portable guarantees. Bex does have its own plan and resource constraints, including free-tier limits, even when you operate the infrastructure yourself. Use the installation's available capabilities rather than copying a Render plan name and assuming equivalent resources.
The live ledger is the source of truth
The Render parity matrix (ADR018) on GitHub records per-surface evidence and known differences. Read the linked code for the Bex version you run: older narrative notes can lag behind implementation changes. A checked row is evidence for its stated scope, not proof of an untested migration.
For a high-level product comparison, see Bex vs Render. For execution steps, use Migrate from Render. If the docs and your installation disagree, report the version and a redacted reproduction in the issue tracker.