Use cases

Pick the setup that matches how you work

bowline has one job: keep a single real ~/Code in sync across every machine and agent you trust. These pages show what that looks like for the way you actually work.

Five ways developers use bowline

Each page is written for a specific setup: the pain today, what changes with bowline, and the commands to get there.

run coding agent on a remote host

Run coding agents on a remote or ephemeral host

Give a coding agent on a remote or ephemeral Linux host your real ~/Code and .env, and sync its edits back to every machine. Gate risky runs behind review.

Read the setup →

sync code between machines

The same ~/Code on every machine

Keep one ~/Code tree in sync across a laptop, desktop, and remote box, including uncommitted and untracked work. No commit-to-move dance, no re-clone.

Read the setup →

remote development without living in a VM

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.

Read the setup →

sync .env files between machines

Your .env and secrets follow the project

Stop copying .env files between machines. Your project's env and secrets travel with it, encrypted, so pnpm dev just runs on a new box or agent host.

Read the setup →

shared dev environment for a small team

Share one workspace namespace with a small team

Give a small team one workspace namespace with per-device trust, audit logs, and revocable access. Everyone's ~/Code and env stay consistent, with no setup docs.

Read the setup →

ready when you are

Your ~/Code, on every machine and every agent.

Install bowline and your projects follow you. It just works.

Get started

$curl -fsSL https://install.bowline.sh | sh

macOS app · Linux CLI. Then run bowline login.