How do I deploy on hosted bex.co?
Follow Hosted setup for account, invitation, and workspace selection, then Billing setup if the dashboard asks for a payment method. Create the service with Web services.
The local quickstart remains the operator path on your own machine; it does not replace hosted onboarding.
Is Bex ready for production?
Bex is in active development. Its upstream project currently says it is not ready for production workloads and that APIs and configuration can change. Use a non-production environment to evaluate it; review compatibility before building an integration.
What does Bex need to run?
The local quickstart runs a Kubernetes-based operator workflow. A complete platform additionally needs its API, identity, control-plane storage, build infrastructure, and the backends for the features you enable. Logs, backups, and public TLS depend on those services being configured.
From a Bex source checkout, the operator development path starts with:
cd lego/operator
make install
BEX_RUNTIME=kubernetes make runFollow the quickstart's cluster and tool prerequisites first. These two commands alone do not create a complete hosted dashboard/API installation.
Do I need kubectl to deploy an application?
Users of a configured Bex platform can use the dashboard, API, CLI, or MCP.
The platform manages Kubernetes resources behind those interfaces.
Operators using the direct App resource workflow can inspect
resources with kubectl. Do not patch API-managed resources directly: the
platform's stored configuration can overwrite those changes.
Can I use my Render manifest or API client unchanged?
Use render.yaml, then validate it against Bex. The structure is familiar but
unsupported fields and operational differences remain. Bex also uses its own
OAuth credentials and resource IDs. See Render parity and
Migrate from Render for checks before migration.
Where should my application store data?
Use Postgres, Key Value, an appropriate external store, or a persistent disk on an eligible service. Ordinary container filesystem changes are ephemeral. A persistent disk restricts replicas and changes deployment availability; persistence alone is not a backup.
Why is a service running but unreachable?
Check the listener host/port and health checks, then inspect the returned URL and domain/TLS state. A process running inside the cluster does not prove public routing or a certificate is ready. Workers and cron jobs do not become public HTTP services when they start.
Does a successful deployment mean my job succeeded?
No. Check the operation appropriate to the service type: an HTTP response, worker queue progress, or the result of a particular cron run. Review how deploys work and logs when deployment state and application behavior differ.
Where do I get help?
Start with the guide for the failing operation and collect the resource/deploy ID, Bex version, timestamps, and redacted errors. Report reproducible product issues in the Bex issue tracker. Do not include tokens, connection strings, or secret values in a public report.