bex vs Render
bex is a Render-compatible platform you run on your own servers. The compatibility is deliberate — it is what makes moving over a copy of your manifest rather than a rewrite — so this page is about where the two genuinely differ, including the places where Render is still the better answer.
bex and Render, capability by capability
| Capability | bex | Render | Source |
|---|---|---|---|
| Runs on servers you own | Yes | No | 1 |
| Whole-stack deploys from one manifest file | Partial
bex reads render.yaml itself (bex.yml survives only as a deprecated filename alias), but as a fail-closed subset: a field bex cannot honor is refused, not silently ignored. The render.yaml checker shows which fields in your file that affects. | Yes | 2 |
| REST API in Render's own shape | Yes | Yes | 3 |
| Official MCP server for AI agents | Yes | Yes | 4 |
| Private images from any container registry | Yes | Partial
Private images pull from a fixed list: Docker Hub, GitHub Container Registry, GitLab Container Registry, Google Artifact Registry and Amazon ECR. | 5 |
| Managed Postgres with high availability, read replicas and point-in-time recovery | Yes | Yes | 6 |
| SSH into a running instance | Yes | Yes | 7 |
| Native runtime builds, no Dockerfile | Yes | Yes | 8 |
| Blueprint env groups and generated secrets | Yes | Yes | 9 |
| Projects and environments grouping | Yes | Yes | 10 |
| Outbound event webhooks | Partial
Signed webhook deliveries with create, list and history over the API; a truthful subset of 32 of Render's 67 event types today | Yes | 11 |
| Key Value eviction policy | Yes | Yes | 12 |
| Persistent disks attached to a service | Yes | Yes | 13 |
| Automatic www ↔ apex domain pairing | Yes | Yes | 14 |
Where Render is the better fit
Notes
- bex mirrors Render on purpose. It reads render.yaml as its Blueprint format, the REST and GraphQL surfaces are built against Render's published API spec, and the MCP tools follow Render's own — so moving over is repointing a base URL and copying a manifest, not a rewrite.
- You can check a specific render.yaml before signing up: the bex.co render.yaml checker reads the same capability registry bex validates against and reports, line by line, which fields bex accepts and why it rejects the rest.
- Every line above is tracked in a public parity ledger: one row per Render capability across REST, GraphQL, MCP and the dashboard, each cell backed by a pointer to code or to Render's own spec. Where this page and the ledger disagree, the ledger is right.
- Some Render features are deliberate non-goals rather than gaps — external log and metric drains, dedicated outbound IPs, platform-scheduled maintenance runs, Workflows, and static-site CDN cache purge. Each one has its reasoning recorded in the ledger.
Sources
- 1.render.com/docs/regions checked August 16, 2026
- 2.render.com/docs/blueprint-spec checked August 16, 2026
- 3.api-docs.render.com/reference/introduction checked August 16, 2026
- 4.render.com/docs/mcp-server checked August 16, 2026
- 5.render.com/docs/deploy-an-image checked August 16, 2026
- 6.render.com/docs/postgresql checked August 16, 2026
- 7.render.com/docs/ssh checked August 17, 2026
- 8.render.com/docs/native-environments checked August 17, 2026
- 9.render.com/docs/blueprint-spec checked August 17, 2026
- 10.render.com/docs/projects checked August 17, 2026
- 11.render.com/docs/webhooks checked August 17, 2026
- 12.render.com/docs/key-value checked August 17, 2026
- 13.render.com/docs/disks checked August 16, 2026
- 14.render.com/docs/custom-domains checked August 16, 2026
- 15.render.com/docs/preview-environments checked August 16, 2026
- 16.render.com/docs/web-services checked August 16, 2026
- 17.render.com/docs/log-streams checked August 16, 2026
- 18.bex.co/docs/platform/migrate-from-render checked August 16, 2026
- 19.bex.co/tools/render-yaml-checker checked September 25, 2026
- 20.github.com/bex-co/bex/blob/main/docs/ADR018-render-parity.md checked August 16, 2026
- 21.render.com/pricing checked August 16, 2026