This is aimed at the case where the code is easy to change but the environment is not — a staging cluster with real databases and real service dependencies. Setup is the cost: one proxy per environment plus a sidecar and an entrypoint change per deployment, after which the loop is a single tool call.
A hot-reload bridge between your local editor and interpreted code running in a remote container. The MCP server runs on your machine; a websocket proxy and a sidecar run in the remote environment. An edit becomes an rsync patch, the proxy routes it to the right deployment, the sidecar writes it to a shared volume and signals the app to restart — no image build, no CI round trip.
- `push_changes` — send the current local working tree to a named remote deployment, respecting your `.gitignore` so build output and secrets stay out of the patch
- Per-developer targeting: `app_id` and `deployment_id` in a `.bifrost.json` file at your project root decide which remote container receives the patch, so several people can each drive their own environment through one proxy
- A restart path that needs no Dockerfile rewrite — the app entrypoint is wrapped by `rsync-launcher.sh`, which syncs the volume in and handles the restart
An API key you choose, shared by the proxy and the sidecar. Locally the client launches `uvx code-sync-mcp` with `BIFROST_API_KEY`, `BIFROST_WS_API_URL` and `BIFROST_API_URL` set to your proxy. Remotely you deploy the proxy with `PROXY_API_KEY`, add the sidecar container alongside your app with `BIFROST_API_URL`, `BIFROST_API_KEY`, `BIFROST_APP_ID` and `BIFROST_DEPLOYMENT_ID`, and replace the app entrypoint with the launcher wrapper. Local rsync must be 3.4.1 or newer. Non-root containers need the app directory chowned to the app user.
One command — uvx code-sync-mcp