Deploy OpenMuse on Render

Why deploy openmuse on Render?

OpenMuse is an open-source personal AI agent that combines a controllable browser you can take over, file storage, and background tasks that keep running. It solves the problem of running autonomous agent workflows that require persistent state, web automation, and human intervention, using a Hono API, an Expo web UI, and a Playwright-based browser worker.

This template wires OpenMuse's full stack together on Render automatically: the Hono API runs as a Node web service with PGlite persisted on a disk, the Expo UI deploys as a static site, and the Playwright Chromium worker runs as a private service with no public URL—all three built straight from CopilotKit/openmuse main. Instead of manually provisioning a browser worker, attaching persistent disks for the workspace database and browser profiles, and generating access keys and encryption secrets by hand, Render creates the access key, encryption key, and browser token for you on Apply—you only supply your OPENAI_API_KEY and CPK_INTELLIGENCE_API_KEY. Pushes to upstream main redeploy the API, web, and worker together, so you get the live app in one click while keeping plan, disk, and env changes as tracked commits in the Blueprint.

Architecture

What you can build

After deploying, you'll have a private AI agent running at your own URL where you can chat to assign tasks, review and approve its plans, and pause, resume, or retry work it's doing in the background. It drives a persistent Chromium browser you can take control of mid-session—signing into sites, keeping cookies and profiles across runs—and stores the PDFs and data it generates on disk. Access is gated behind a single generated key, so it's a one-owner workspace rather than something you expose publicly.

Key features

• Upstream-tracked builds: Each service sets repo to CopilotKit/openmuse at branch main, so Render clones and builds upstream directly instead of vendoring source, and pushes to that branch trigger redeploys.
• Takeover browser sessions: A private Chromium worker (apps/worker/Dockerfile) on port 8790 maintains persistent browser profiles on disk, and 'Take control' opens the same live session the agent is using.
• Resumable task worker: An in-process worker on the Node API runs tasks that support plans, pause, resume, cancel, retry, and approvals so long-running jobs survive beyond a single request.
• PGlite on persistent disk: The API persists its workspace database, PDFs, and signing key on a 1 GB disk at /var/data, requiring the Standard plan since Starter's 512 MB OOM-kills PGlite startup.
• Auto-generated secrets: The Blueprint uses generateValue to create OPENMUSE_ACCESS_KEY, TOKEN_ENCRYPTION_KEY, and WORKER_TOKEN once on first apply, leaving only the CopilotKit and OpenAI keys to supply manually.

Use cases

• Analyst runs overnight web-scraping tasks that pause for login approvals
• Founder delegates competitor research while taking browser control for CAPTCHAs
• Developer self-hosts a private AI agent with persistent Chromium profiles
• Researcher queues long-running document tasks that survive restarts on disk

What's included

Prerequisites

• CopilotKit Intelligence API Key: Server-only key that authorizes OpenMuse to call the CopilotKit Intelligence service powering the agent.
• OpenAI API Key: API key used by the default model (openai/gpt-5) to generate responses.

Next steps

1. Open the openmuse-web static site URL and sign in with the OPENMUSE_ACCESS_KEY value copied from the openmuse-api service's environment — You should pass the access-key gate and land in the OpenMuse chat workspace instead of being bounced back to the sign-in prompt
2. Start a browser task in chat, then click Take control to open the live Chromium session backed by openmuse-browser — You should see the same persistent browser session in your window and be able to drive it, confirming the API reached the private worker on port 8790 with the shared WORKER_TOKEN
3. Upload a PDF in the Documents area and then reference it in a chat task — The file should persist on the API's 1 GB disk at /var/data and reappear in the document list after you reload the page, confirming the disk is mounted and retained

Resources

• OpenMuse official site