Provides Git repository inspection tools (git_status and git_diff) for workspaces, allowing clients to review repository status and changes with bounded output.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Remote Coding Runtime Check the git state in workspace zero and show uncommitted changes."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Runmesh is provided under the PolyForm Noncommercial License 1.0.0. Commercial use requires separate written authorization. SeeCommercial License.
Runmesh connects ChatGPT, Claude, Cursor, and other MCP-compatible clients to computers you control. An AI client can inspect approved files, suggest or apply changes, run authorized commands, and follow long-running jobs.
Each execution machine runs a Runmesh Runner, which connects to the control plane over an encrypted outbound connection. Files and commands are handled on the machine, and requested output passes through the control plane to the authenticated client. The control plane stores configuration, bounded audit metadata and optional recent Job metadata.
Runmesh is useful for maintaining servers, sharing a controlled development machine with a team, running builds and operational tasks, and giving each client a precise set of machines, workspaces, and capabilities.
Related MCP server: cloud-to-local
If an administrator has given you an MCP URL:
Paste the complete URL into an MCP Streamable HTTP client.
Call runner_list to see available machines.
Call runner_current. If no machine is selected, call runner_select with the intended Runner ID, then confirm with runner_current.
Call workspace_list to see the workspaces approved for you.
Start with read or inspect; use edit, shell, or job only when needed.
The MCP URL is a credential, shown when a client is created or rotated. Store it securely and share it only with its intended user. See the user guide for the complete workflow.
Use the signed 0.1.4 stable release for production, with the corresponding activated main source for Worker deployment. Test upcoming changes in the separate dev environment described in the deployment reference.
Deploy a released production Worker from main, configure INTERNAL_CONTROL_SECRET and RUNNER_TOKEN_PEPPER, and set the first administrator password before exposing the instance to untrusted visitors.
Add a machine on the Runner page. Keep the default dedicated_user execution mode unless you need and accept host-level privileges.
Copy the one-time enrollment command and run it on the target machine.
Add approved workspaces and permissions in the Runner details page.
Create an MCP client with the least privileges needed; new clients default to coding:read. Copy its one-time URL.
Share the URL with its intended user, and rotate or revoke it when necessary.
The standard installer downloads a fixed, verified release, supplies the runtime, enrolls the Runner, and configures its service. If hosted installation is unavailable, the dashboard shows the offline-verifiable portable procedure. See the administrator guide.
The copied enrollment command contains a single-use credential; keep the complete command private. For hidden manual code entry, follow the interactive installation steps; Windows also requires removing -NonInteractive from the copied PowerShell command.
Ordinary production uses two independent long-lived secrets. Domain, history-backend and reviewed-release defaults are automatic. ADMIN_TOKEN is optional for advanced API administration. Preserve existing secret values during upgrades. The setup helper and reverse-proxy settings are documented in minimal runtime configuration.
Capability | What it does | Default behavior |
Read | Browse files and directories in approved workspaces | Read-only, paginated, and bounded |
Edit | Apply changes with baseline checks | Requires write permission; follow recovery guidance if the result is uncertain |
Inspect | View Git status, diffs, and bounded diagnostics | Read-only and limited to the permitted workspace |
Shell | Run commands as the Runner service identity | Requires execution permission and uses the service account's OS privileges |
Job | List, read, provide input to, or cancel long-running work | Paginated logs with bounded retention |
Context | Save and retrieve workspace handoff notes | Optional, permission-controlled local storage with explicit cleanup |
Effective permission is the intersection of the client, Runner, and workspace policies. Each operation stays on the selected Runner; switching machines is an explicit client action.
Copy MCP URLs when creating or rotating them, and keep enrollment codes and Runner profiles private. Revoke or replace credentials if they are exposed.
Administrators manage workspace roots; ordinary MCP workspace metadata omits those absolute paths. File contents and command output can still contain host paths. File-tool path checks reject traversal, device paths, and symlink escapes.
The admin UI uses secure cookies, CSRF and origin checks, and login throttling.
Run untrusted code inside a dedicated container or virtual machine with a restricted service account.
Production operators should configure edge log redaction and maintain a credential rotation procedure.
The latest published stable version is 0.1.4. See release notes for its improvements and release status for installation availability. Development uses a separate verified prerelease channel.
An upgrade has three steps: deploy the Worker, install the target Runner package, and refresh the MCP client's tool catalog. Verify a representative task afterward using the upgrade guide.
A new deployment provisions its own resources. For an existing v2 installation, preserve the Worker, live namespaces, D1 binding, secrets and enrolled Runners. Before rollout, check account quotas, service startup and shutdown, edge-log redaction, and the MCP clients you plan to use.
User guide: connect an MCP client, select a Runner, use workspaces, and manage jobs.
Administrator guide: deploy, enroll Runners, configure workspaces, and create clients.
Upgrade guide: update compatible installations and verify Worker, Runner and client together.
Troubleshooting: login, connectivity, installation, permissions, and job issues.
Security model: credential handling and trust boundaries.
Portable installation: offline verification and manual setup.
Deployment reference: Cloudflare and advanced operations.
Release notes: changes and known limits for each release.
The documentation index also links to architecture, protocol and maintainer references, with dated records available for historical context.
Community support from linux.do.
Runmesh is maintained by aloneio. Report security vulnerabilities through the private process in .github/SECURITY.md; use Issues for ordinary bugs and product feedback. See trademarks for name and logo usage.
This server cannot be deployed
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Securely control computers you explicitly pair through files, terminals, processes, screenshots, desktop UI/input, clipboard, browser automation, diagnostics, and document tools.
Cloudflare Workers MCP server: agent-workflow-engine
