Use case
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.
Who this is for
Search intent: sync .env files between machines.
The code is easy to move; the environment is what breaks. You clone cleanly on a new box and then nothing runs, because .env, .env.local, and a dozen keys live only on your old machine. So you scp them around, paste keys into chats, or keep a private gist you hope is current.
Before and after
The status quo, and what changes once bowline is keeping this workspace in sync.
Today
- You scp .env files between machines or paste keys into a notes app to move them.
- A fresh clone runs and immediately fails on a missing DATABASE_URL, STRIPE_SECRET, and half your integrations.
- Secrets sprawl across machines with no record of which copy is current.
- An agent host or CI box needs the same keys, so you re-enter them by hand every time.
With bowline
- .env, .env.local, and .env.* travel with the project, encrypted in transit and at rest.
- Open the project on a second machine or an agent host and pnpm dev just runs, because the keys are already there.
- No bowline shell, no re-pasting API keys, no wrapper around your process.
- Secrets rematerialize as normal files only on devices you have explicitly approved, and trust is revocable.
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 new box, then bowline login.
bowline connect laptop-2Approve the device once; project env comes with the tree.
cd ~/Code/acme/web && pnpm devReads the synced .env and starts, with no key-copy step.
What makes it work
The bowline capabilities that carry this workflow.
Env files travel with the project, encrypted, and decrypt only on trusted devices.
No shell wrapper: your .env is a real file that pnpm, node, and your tools read directly.
Revocable per-device trust means a lost laptop can be cut off from your secrets.
Recovery keys you hold let you regain access without trusting the relay with plaintext.
Common questions
Short answers to the questions this setup raises first.
Are my secrets readable by Bowline's servers?
No. Env files and secrets are encrypted in transit and at rest and rematerialize as plaintext only on devices you have approved. The security-critical code (device trust, recovery keys, workspace encryption) is open source under Apache 2.0.
Do I have to run my app inside a special shell to load the env?
No. Your .env stays an ordinary file on disk. pnpm dev, node, and every other tool read it exactly as they do today. bowline puts the file there; it doesn't wrap your process.
What happens to the secrets if I lose a device?
Revoke that device's trust and it can no longer decrypt your workspace. You hold recovery keys, so you keep access from your remaining machines.
Does this cover per-environment files like .env.local and .env.production?
Yes. .env, .env.local, and .env.* travel with the project so the right variables are present on each machine, matching how your framework already loads them.
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.