bex-co/bex

bex-co のプロフィール

記録された最新のソース活動: 2026年10月6日 21:56

SkillsMP カタログ更新: 2026年10月17日 00:09

収集済み skills: 26

GitHub スター: 569
GitHub フォーク: 63

リポジトリの README

README の元ファイル：README.md

README の元ファイルを読む

README 全文を表示

<img src="dashboard/public/logo.png" width="88" alt="bex logo"> <h1 align="center">bex</h1> The open-source, AI-native alternative to Render. Deploy from Git to HTTPS on infrastructure you own—and give developers and coding agents the same first-class control plane. <a href="https://github.com/bex-co/bex/stargazers"><img src="https://img.shields.io/github/stars/bex-co/bex?style=flat&logo=github" alt="GitHub stars"></a> <a href="LICENSE"><img src="https://img.shields.io/badge/license-Apache--2.0-blue.svg" alt="Apache 2.0 license"></a> <a href="https://github.com/bex-co/bex/actions/workflows/deploy.yml"><img src="https://github.com/bex-co/bex/actions/workflows/deploy.yml/badge.svg" alt="Build and deploy status"></a> <a href="https://github.com/bex-co/bex/actions/workflows/docs.yml"><img src="https://github.com/bex-co/bex/actions/workflows/docs.yml/badge.svg" alt="Documentation status"></a> <a href="#quickstart">Quickstart</a> · <a href="#what-ships-today">Features</a> · <a href="#see-bex-in-action">Screenshots</a> · <a href="docs/ADR002-architecture.md">Architecture</a> · <a href="docs/ADR018-render-parity.md">Render parity</a> · <a href="CONTRIBUTING.md">Contributing</a> <a href="docs/assets/workspace-overview.webp"><img src="docs/assets/workspace-overview.webp" width="1200" alt="bex dashboard showing two running services in the bex.co project"></a> > [!WARNING] > > **bex is in active development and is not ready for production workloads.** APIs and configuration can change. The core platform works and is continuously tested; use it today to explore, contribute, and help shape the project. ## Why bex Render, Heroku, and Railway proved the experience developers want: connect a repo, get a URL, and avoid operating Kubernetes by hand. bex makes that experience open source, self-hostable, and programmable by agents. - **A familiar PaaS workflow.** Deploy Dockerfiles or native Go, Node.js, Python, Ruby, Rust, and Elixir projects from Git. Use Render-style `render.yaml` Blueprints and a Render-compatible CLI and API. - **One control plane for humans and agents.** The dashboard, REST, GraphQL, MCP, CLI, and Kubernetes resources operate the same core. There are no dashboard-only deployment actions. - **More than a container launcher.** Web services, private services, workers, cron jobs, static sites, managed Postgres, managed Key Value, logs, metrics, deploy history, rollbacks, domains, TLS, and SSH are already represented. - **Your infrastructure and your data.** Run the same Go operator against Docker-container machines locally or Hetzner machines in production-shaped clusters. The provider overlay changes; the product does not. - **Inspectable by design.** The platform is Apache-2.0, its intent is declarative, and its compatibility claims are tracked in an evidence-backed [Render parity ledger](docs/ADR018-render-parity.md). ## From repo to URL Declare a service with the same `render.yaml` shape many developers and tools already understand: ```yaml services: - name: api type: web runtime: docker repo: https://github.com/your-org/your-app branch: main plan: free healthCheckPath: /health databases: - name: app-db plan: free ``` The Blueprint API compiles that intent into `App` and `Database` resources. The operator builds the source, rolls out the workloads, configures routing and TLS, and reports structured status back through every interface. An agent can perform the same deployment with the MCP `deploy` tool—repo plus manifest in one call. See the [hello-world examples](examples/) or the full [deployment contract](docs/ADR004-app-deployment.md). ## What ships today | Area | Capabilities | | --- | --- | | **Services** | Web and private services, background workers, cron jobs, static sites, Dockerfiles, native builds, health checks, pre-deploy commands, manual and policy-driven autoscaling | | **Data** | Managed PostgreSQL with backups/PITR, HA and read replicas; managed Valkey-compatible Key Value with persistence and backups | | **Operations** | Deploy history, cancel and rollback, logs and live tail, metrics, events, suspend/resume/restart, custom domains and TLS, native SSH and browser shell | | **Delivery** | GitHub App integration, private repositories, push-to-deploy, multi-resource Blueprints, registry credentials, outbound webhooks | | **Teams** | Workspaces, projects and environments, roles with OpenFGA, OAuth 2.1, API keys, audit logs, usage metering and billing integration | | **Agents** | Remote and stdio MCP, OAuth consent, deploy-from-chat, managed sandboxes, cloud coding-agent sessions, structured machine-readable state | Some capabilities require optional backing services or explicit configuration and fail closed when unavailable. For the exact REST · GraphQL · MCP · UI status of every capability, use the [parity ledger](docs/ADR018-render-parity.md)—not this summary—as the source of truth. ## See bex in action <table> <tr> <td width="50%"> Deploy from Git or an image <a href="docs/assets/new-web-service.webp"><img src="docs/assets/new-web-service.webp" width="100%" alt="New service form with web, private, worker, cron, and static service types"></a> </td> <td width="50%"> Follow every deploy <a href="docs/assets/deploy-detail.webp"><img src="docs/assets/deploy-detail.webp" width="100%" alt="Live deploy detail with revision metadata, status timeline, rollback, and build logs"></a> </td> </tr> <tr> <td width="50%"> Tail and filter live logs <a href="docs/assets/live-logs.webp"><img src="docs/assets/live-logs.webp" width="100%" alt="Live service logs with search, range, and filter controls"></a> </td> <td width="50%"> Correlate metrics with deploys <a href="docs/assets/service-metrics.webp"><img src="docs/assets/service-metrics.webp" width="100%" alt="Service memory and CPU metrics with deployment event markers"></a> </td> </tr> <tr> <td width="50%"> Manage environment and secrets <a href="docs/assets/environment-secrets.webp"><img src="docs/assets/environment-secrets.webp" width="100%" alt="Environment variables and secret files with save-and-deploy workflow"></a> </td> <td width="50%"> Bring a domain; get TLS <a href="docs/assets/custom-domain.webp"><img src="docs/assets/custom-domain.webp" width="100%" alt="Custom-domain dialog with automatic TLS certificate issuance"></a> </td> </tr> </table> ## Quickstart This boots the production-shaped local substrate: a kind management cluster, Cluster API, and an app cluster whose machines are Docker containers. **Prerequisites:** Docker or OrbStack, Go 1.25+, `kubectl`, `kind`, and `clusterctl`. In terminal 1: ```bash git clone https://github.com/bex-co/bex.git cd bex # Provision the local Cluster API substrate. bash scripts/mock-cluster.sh export KUBECONFIG="$PWD/infra/local/bex.kubeconfig" # Install the CRDs and run the operator from source. cd lego/operator make install BEX_RUNTIME=kubernetes make run ``` In terminal 2: ```bash cd bex export KUBECONFIG="$PWD/infra/local/bex.kubeconfig" # Deploy a prebuilt image and watch it converge. kubectl apply -f examples/whoami-app.yaml kubectl get apps.app.bex.co -w ``` An `App` reports the state an operator or agent needs without scraping logs: ```text NAME PHASE REVISION URL whoami Running rev-1 http://whoami.default.svc:8080 ``` Then add a tenant machine and scale the workload across it: ```bash bash scripts/mock-cluster.sh scale 2 kubectl patch apps.app.bex.co whoami --type merge -p '{"spec":{"replicas":6}}' kubectl get pods -l app.bex.co/app=whoami -o wide ``` The first bootstrap downloads the Kubernetes and Cluster API dependencies and can take several minutes. For a full platform deployment, start with [infra/README.md](infra/README.md); for the Go workspace and development commands, see [lego/README.md](lego/README.md). ## Use the interface that fits | Interface | Best for | | --- | --- | | **Dashboard** | Human-friendly service, data, environment, team, usage, and security workflows | | **`bex` CLI** | Interactive operations and scripts using the upstream Render CLI command implementation ([install and compatibility notes](docs/bex-cli.md)) | | **REST + GraphQL** | Product integrations and custom control-plane clients | | **MCP** | Claude Code, Cursor, and other agents over OAuth 2.1 or a headless API key ([connect an agent](docs/ADR025-connect-an-agent.md)) | | **Kubernetes CRDs** | GitOps, low-level debugging, and direct operator development | All product adapters are thin layers over the same Go core, so authorization, lifecycle behavior, and resource identity do not drift by interface. ## How it works ```mermaid flowchart TB developer@{ shape: tri, label: "developer" } agent@{ shape: tri, label: "coding agent" } dashboard["dashboard (web service)"] cli["bex CLI (local client process)"] subgraph app_cluster["app cluster"] api["bex-api"] store[(control-plane Postgres)] crds["App · Database · KeyValue (Kubernetes objects)"] operator["bex operator"] registry["Zot registry"] runtime["tenant runtime (Kubernetes workloads and routes)"] capi["Cluster API controllers"] nodes["worker nodes (machines)"] end developer --> dashboard developer --> cli agent -->|MCP| api dashboard -->|GraphQL| api cli -->|REST| api api --> store api -->|projects desired state| crds operator -->|watches and reconciles| crds operator -->|builds and pushes images| registry runtime -->|managed by| operator runtime -->|pulls images| registry runtime -->|runs on| nodes nodes -->|provisioned by| capi ``` Arrows point from a consumer to what it depends on. `bex-api` owns durable product intent; the database-free operator turns projected Kubernetes objects into workloads; Cluster API provisions the machines beneath them; and `operator → types ← backend` remains the one-way code dependency described in the [architecture panorama](docs/ADR002-architecture.md). <details> <summary>Repository map</summary> ```text lego/ types/ App, Database, and KeyValue CRD contracts operator/ Kubernetes manager: reconcile, build, runtime, config backend/ bex-api and the isolated SSH gateway cli/ bex CLI launcher (imports the pinned upstream Render CLI) dashboard/ TanStack Start + Apollo + shadcn web application mobile/ Expo client for safe supervision workflows infra/ Terraform + Cluster API: local CAPD and Hetzner CAPH deploy/gitops/ Argo CD platform infrastructure examples/ Image, Git, static, cron, and multi-resource samples docs/ Architecture decisions, contracts, runbooks, and evidence scripts/ Local-cluster, deployment, security, and verification tools ``` </details> ## Project status bex is a working public alpha with a live, production-shaped architecture and broad Render compatibility. It is also a large surface area under rapid development. The project makes that tradeoff explicit: - [Vision and product thesis](docs/ADR008-vision.md) - [Evidence-backed Render parity and known gaps](docs/ADR018-render-parity.md) - [Architecture and trust boundaries](docs/ADR002-architecture.md) - [CLI compatibility checklist](docs/cli-compatibility-checklist.md) - [Contributing guide](CONTRIBUTING.md) ## Help build the open cloud If you want a PaaS that agents can operate and developers can own, [star the repository](https://github.com/bex-co/bex), try the local cluster, and tell us where the experience breaks. Issues and pull requests are welcome; agent-authored contributions are welcome when the author has reviewed the diff and the tests pass. Apache-2.0 licensed. See [CONTRIBUTING.md](CONTRIBUTING.md) and the [Code of Conduct](CODE_OF_CONDUCT.md).

リポジトリの README を読み込んでいます…

このリポジトリの skills

ソフトウェア開発者グラフィックデザイナーコンピュータシステムアナリストソフトウェア品質保証アナリスト・テスター

7 件の職業カテゴリ · 42% 分類済み

ソフトウェア開発者

Use when the user or agent needs to read, search, or look up Stripe documentation or API reference. Prefer this over curl or WebFetch for any docs.stripe.com content.

原文の言語: 英語

2026-07-31

収集済み skill 26 件中 26 件を表示しています。

AI アシスタントでインストール

このプロンプトをコピーして、使用中の AI アシスタントに送ってください。

Follow https://skillsmp.com/skill-install/prompt.md to install Agent Skills from https://github.com/bex-co/bex.