← 返回内容列表
GGitHub采集原文

bex:面向开发者与智能体的自托管部署

发布时间未知 · 北京时间

AI 编程

有实践材料可继续查看

代码仓库安装说明使用说明示例代码

原文与观测指标

1 个来源
GGitHub

bex:面向开发者与智能体的自托管部署

bex-co
查看原文
星标574采集时的累计值
每小时增长待观察星标 / 小时 · 观测区间平均值
最近提交10-26 17:34提交时间不是项目发布时间

发布时间:未知 · 首次发现 10-26 17:35 · 北京时间

指标采集:10-26 17:35 · 指标已取得

项目文档有线索安装说明有线索使用说明有线索示例有线索

仅反映文档与示例线索,未实际运行项目。

简短概述

bex 是开源自托管部署平台,通过 Git 仓库和声明式配置完成构建、部署及 HTTPS 配置,并向开发者与智能体提供统一接口。项目明确仍在积极开发,不适合生产负载。

AI 概述,仅依据已采集材料,未经独立核验。
采集原文 展开 / 收起

bex

The open-source Render alternative — AI-native. Git push → build → deploy on your own infrastructure; agents are first-class users.
项目说明 展开 / 收起
bex 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. Quickstart · Features · Screenshots · Architecture · Render parity · Contributing 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. From repo to URL Declare a service with the same render.yaml shape many developers and tools already understand: 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 or the full deployment contract. 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—not this summary—as the source of truth. See bex in action Deploy from Git or an image Follow every deploy Tail and filter live logs Correlate metrics with deploys Manage environment and secrets Bring a domain; get TLS 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: 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: 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: 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 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; for the Go workspace and development commands, see 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) 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) 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 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 · KeyVal