---
id: platform/faq
title: FAQ
description: Answers about Bex setup, Kubernetes access, Render compatibility, persistence, deployment readiness, and troubleshooting.
keywords: [bex, faq, questions, render alternative, kubernetes, self-hosted]
last_updated: 2026-09-23
---

## How do I deploy on hosted bex.co?

Follow [Hosted setup](./hosted-setup.md) for account, invitation, and workspace
selection, then [Billing setup](./billing-setup.md) if the dashboard asks for a
payment method. Create the service with [Web services](./web-services.md).

The local [quickstart](./quickstart.md) 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](./compatibility.md) before building an integration.

## What does Bex need to run?

The local [quickstart](./quickstart.md) 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:

```bash
cd lego/operator
make install
BEX_RUNTIME=kubernetes make run
```

Follow 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](./app-resource.md) 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](./render-parity.md) and
[Migrate from Render](./migrate-from-render.md) for checks before migration.

## Where should my application store data?

Use [Postgres](./postgres.md), [Key Value](./key-value.md), an appropriate external
store, or a [persistent disk](./persistent-disks.md) 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](./health-checks.md), then inspect
the returned URL and [domain/TLS state](./custom-domains.md). 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](./how-deploys-work.md) and [logs](./logging.md) 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](https://github.com/bex-co/bex/issues).
Do not include tokens, connection strings, or secret values in a public report.