push_changesLABSCO SUMMARY
Editing locally, running where the data is.
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.
What it is
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.
What you get
push_changes— send the current local working tree to a named remote deployment, respecting your.gitignoreso build output and secrets stay out of the patch- Per-developer targeting:
app_idanddeployment_idin a.bifrost.jsonfile 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
Requirements
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.
Setup effort
One command — uvx code-sync-mcp
USE CASES
01
Testing against real staging data
Edit locally, push the change into the staging container, and see the behaviour against the services and data that only exist there.
02
Skipping CI for a one-line fix
Get a small change running remotely in seconds instead of waiting for a build and deploy pipeline to confirm it.
03
Giving each developer their own remote target
Point each person's project file at their own deployment id so pushes land in separate containers behind the same proxy.
1 tool
Listed in project docs. Your client may show a different list.
BEFORE YOU INSTALL
What to know first
Tools you get
1 tool named in the project's documentation.
Requires
uvx code-sync-mcp on PATH
INSTALLATION
Connect your client
Server setup
TERMINAL
uvx code-sync-mcpMCP Clients
Cursor
CURSOR · JSON
{
"mcpServers": {
"code-sync": {
"command": "uvx code-sync-mcp",
"env": {
"BIFROST_API_KEY": "<YOUR_BIFROST_API_KEY>",
"BIFROST_WS_API_URL": "ws://<YOUR_PROXY_URL>",
"BIFROST_API_URL": "http://<YOUR_PROXY_URL>"
}
}
}
}Cursor — local
CURSOR — LOCAL · JSON
{
"mcpServers": {
"code-sync": {
"command": "uvx code-sync-mcp",
"env": {
"UV_PYTHON": "3.13",
"BIFROST_API_KEY": "test-secret-key",
"BIFROST_WS_API_URL": "ws://localhost:8000",
"BIFROST_API_URL": "http://localhost:8000"
}
}
}
}
