Skip to content

Render blueprint - #86

Merged
jerelvelarde merged 5 commits into
CopilotKit:mainfrom
ojusave:render-blueprint
Sep 29, 2026
Merged

jerelvelarde merged 5 commits into
CopilotKit:mainfrom
ojusave:render-blueprint

Conversation

@ojusave

@ojusave ojusave commented Sep 29, 2026

Copy link
Copy Markdown
Contributor

What changed

Adds a Render Blueprint so OpenMuse can be deployed with 1 click.

render.yaml defines three services:

  • openmuse-api: Node web service on Standard, with a 1 GB disk at /var/data (DATA_DIR=/var/data/openmuse). Live mode, because sample mode rejects the non-loopback host Render binds. Render generates OPENMUSE_ACCESS_KEY and TOKEN_ENCRYPTION_KEY. The deploy form asks for OPENAI_API_KEY and CPK_INTELLIGENCE_API_KEY.
  • openmuse-web: static site from the Expo web export, with an SPA rewrite to /index.html. EXPO_PUBLIC_API_URL is taken from the API service at build time.
  • openmuse-browser: private Docker service from apps/worker/Dockerfile, with a 1 GB disk at /data. The API calls it at http://openmuse-browser:8790 with a generated WORKER_TOKEN. To deploy without browsing, delete this service and the BROWSER_WORKER_URL and WORKER_TOKEN entries on the API.

The README Deploy section covers the button, first run (copy the access key, sign in, send a message), and the env vars. It also notes why the API is on Standard: at 512 MB the process runs out of memory while PGlite loads. The disk holds the database, PDFs, and the signing key. Chat threads stay on CopilotKit Intelligence. The Docker computer and Google mail or calendar are unchanged and are not started by this Blueprint.

Verification

Deployed this commit in a Render workspace as new services, including both disks:

  • All three services went live. GET /api/health returned ok: true, mode: live, agentConfigured: true, browserConfigured: true.
  • Signed in with the generated OPENMUSE_ACCESS_KEY. The workspace reported the browser connection as connected.
  • API disk: created a draft, redeployed openmuse-api, and the same session still authenticated. GET /api/drafts returned that draft.
  • Browser disk: opened https://example.com, closed the session, and redeployed openmuse-browser. The same session id came back with its title and URL, and reopen returned it active on example.com.
  • The static site returned 200 for / and for a client route through the rewrite.
  • render blueprints validate render.yaml passed.

These services were created from this render.yaml through the Render API. The Deploy button reads render.yaml from the default branch, so it works after this merges.

Integration limits

  • The deploy needs CPK_INTELLIGENCE_API_KEY (npx copilotkit@latest login, then project select) and OPENAI_API_KEY. Another provider means changing MODEL and supplying that key.
  • The API and the browser are both Standard, each with a 1 GB disk.
  • The Docker computer and Google are not part of the Blueprint.
  • If the private hostname is not openmuse-browser (this happened in the test workspace), set BROWSER_WORKER_URL to http://<that-host>:8790.

The API does not serve the Expo bundle, so the Blueprint is a Standard
Node service with a persistent disk plus a static site. Deploy buttons
point at CopilotKit/OpenMuse.
Put sign-in steps and the env var table ahead of plan, disk, and
live-mode limits, and say which features this Blueprint does not start.
The API already runs without it. Removing the service and its two env
vars leaves chat and tasks working, and skips Chromium.
@jerelvelarde

Copy link
Copy Markdown
Collaborator

Thanks @ojusave, this is great. It covers everything from the Slack thread, and adding the browser worker was a nice bonus.

I checked render.yaml against the server and worker config. The env var names, the live-mode checks, the generated key and token lengths, the worker's fixed port 8790, and the Docker context all line up.

One fix before merge:

  • README.md: the intro still says the Blueprint "deploys two services", and First run step 1 only waits for openmuse-api and openmuse-web. Both predate the browser commit. Could you change it to three services and add openmuse-browser to step 1? Otherwise someone can sign in before the browser service is up. The workspace would already show the browser as "connected", because that status only checks that the URL and token are set, but page reads would fail.

Optional:

  • You mentioned the private hostname wasn't openmuse-browser in your test workspace. A line in the README on setting BROWSER_WORKER_URL to http://<host>:8790 when that happens would save people some debugging.
  • The default MODEL is openai/gpt-4o-mini. We'd prefer a current default, for example openai/gpt-5, which the repo uses elsewhere.

The browser and browser-container failures are a flaky network test: example.com didn't load inside Chromium. They're unrelated to this PR, and I'll re-run them.

jerelvelarde and others added 2 commits September 29, 2026 20:24
The intro and first-run step still described only the API and web app, so someone could sign in before the browser service was up. The default model now matches the gpt-5 id used elsewhere in the repo.
@jerelvelarde
jerelvelarde merged commit d0b3a6b into CopilotKit:main Sep 29, 2026
7 checks passed
sunshaoan0808 pushed a commit to sunshaoan0808/openmuse that referenced this pull request Sep 30, 2026
上游 5 个提交:JEV(CopilotKit#42)、无 scheme worker 地址(CopilotKit#92)、web 输入框焦点(CopilotKit#89)、
worker 测试健壮性(CopilotKit#90)、render 蓝图(CopilotKit#86)。

冲突解决(4 文件 9 块)与本地适配:
- conversation.ts:以上游 JEV 结构(runInternal/choices 分支/noteEvidence)为基座,
  换回我们的中性工具层(forAgUi + chatTools),并把 noteEvidence 改成经 ChatToolContext 回调;
  prompt 用我们的 chatInstructions() + JEV 段 + computerInstructions;恢复 maxSteps=10 与
  sample 分支的 threadId 注入
- agent.ts:保留我们的 mastra 引擎分支,两处 ConversationAgent 注入 sharedJevAdapter()
- chat.tsx:我们的卡片(搜索/浏览器操作/审批)与 JEV 卡片并存,去重 delegate_task 渲染器
- config.ts:去掉 cherry-pick 造成的 browserWorkerUrl 重复定义
- mastra-engine.ts:JEV 工具与指令补到 mastra 路径(上游只挂自带引擎,我们线上跑 mastra)
- jev/tools.ts:抽出 presentChoicesSpec 中性规格,两条引擎共用同一份校验逻辑

验证:pnpm test 321/321 通过(含上游 JEV 全部测试)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants