Use case
Develop on a remote server with your laptop first-class
Use a remote build or GPU box without moving into it. Edit on your laptop, run on the server, and keep the same ~/Code and .env on both. No cloud IDE.
Who this is for
Search intent: remote development without living in a VM.
You have a beefy remote box, maybe a GPU host or a build server closer to your data. You want its compute, not its environment. Cloud IDEs and devboxes answer this by moving you into the remote machine, so your laptop stops being where you actually work.
Before and after
The status quo, and what changes once bowline is keeping this workspace in sync.
Today
- Remote work means SSH plus a remote editor, or living inside a cloud IDE where your local setup no longer applies.
- You keep two environments in your head: what's on the laptop, what's on the server, and which one is right.
- Moving a change between them is scp, a commit, or an rsync script you maintain forever.
- Your local editor extensions, shell config, and keybindings don't come with you to the remote box.
With bowline
- Edit in your local editor on the laptop; the same ~/Code is live on the remote box, ready to build or train.
- Your laptop stays first-class: you are not living inside the server, you are syncing with it.
- Run the heavy job on the remote box; the outputs and edits land back on the laptop automatically.
- No cloud IDE, no remote filesystem to babysit. Both machines hold ordinary local directories.
The setup
Install once, approve the device, and open the folder. No manifests and no keys to copy between machines.
curl -fsSL https://install.bowline.sh | shInstall on the remote server, then bowline login.
bowline connect gpu-boxApprove the server once from your laptop.
cd ~/Code/acme/model && python train.pyRuns on the server against the same tree you edit on the laptop.
What makes it work
The bowline capabilities that carry this workflow.
Your laptop stays the machine you work on: bowline syncs real directories instead of moving you into a VM.
Edits flow both ways: change on the laptop, run on the server, get the outputs back.
Env and secrets follow the project, so the server can reach the same databases and APIs.
bowline status flags a stale base on either side before a long job runs against the wrong tree.
Common questions
Short answers to the questions this setup raises first.
How is this different from VS Code Remote or a cloud devbox?
Those move your working session into the remote machine. bowline keeps your laptop first-class: you edit locally with your own tools, and the same ~/Code is live on the server. Neither side is a mount or a remote filesystem.
Do build outputs and generated files come back to my laptop?
Edits and outputs sync back to every trusted device. Heavy local caches like node_modules stay per-machine and regenerate, so you get the results without dragging build junk across the network.
What if the server has a different OS than my laptop?
bowline runs on macOS and Linux and keeps the source, config, and env in sync across them. Machine-specific artifacts regenerate locally per platform rather than crossing over.
Can I still just SSH into the box?
Yes. bowline changes nothing about how you reach the server. It only makes the code, env, and working state already be there when you arrive.
Your ~/Code, on every machine and every agent.
Install bowline and your projects follow you. It just works.
curl -fsSL https://install.bowline.sh | shmacOS app · Linux CLI. Then run bowline login.