Env profiles: client vs personal

Env profiles are how you stop copying .env through Slack. Fill from .env.example, name the profile, switch when the project context changes. Continuity can sync the encrypted shape of your setup across Macs. Secrets stay local. Client keys do not belong in a personal-dotfiles repo — habit beats hope.

The problem profiles solve

Without profiles, studios invent folklore:

A .env.local that is really the client’s staging keys.
A personal laptop that still has last quarter’s Acme Stripe test key.
A worktree that silently shares one melted .env across branches.
An agent that “fixes” config by pasting secrets into chat.

Rig’s lanes and env profiles bind environment to the context you meant: client vs personal, feature branch vs main, port and branch together so switching lanes does not destroy a shared file. See Lanes, env profiles, and worktrees.

Client vs personal — make it boring

Client profile. Named for the client or engagement. Contains only what that project needs. Used on the studio Mac (and Continuity restore onto a travel Mac when you deliberately choose that). Rotated when the engagement ends.

Personal profile. Side projects, open source, experiments. No client API keys. No production-adjacent tokens “just for debugging.”

Agency shared shape. Templates and .env.example live in git. Real values do not. Fill-from-example is the onboarding path so a new Mac does not require a DM with secrets.

If you only remember one rule: the profile name should make the blast radius obvious. acme-staging and personal-oss beat default and default-2.

Continuity without magical thinking

Continuity backs up setup — catalog shape, env profile structure, ports, preferences — encrypted on-device before upload with a key Rig does not hold. It is how another Mac can restore *how you work* without uploading the repo.

What Continuity is not:

A licence to put production keys in every profile “because it syncs.”
A git host.
Permission to skip OS access control on the receiving Mac.

When you restore onto a personal laptop for a weekend firefight, prefer a client profile that is scoped and temporary — then remove it when the firefight ends. Syncing the shape is not the same as needing every secret on every machine forever.

Lanes, worktrees, and ports

Parallel features want isolation. A worktree with its own lane can bind:

Branch / checkout folder
Env profile
Port

so Acme on :3000 does not collide with Northwind on :4321, and so .env does not thrash when you jump branches. If you skip lanes and share one env file across worktrees, you will eventually ship the wrong APP_URL to the wrong process and blame the framework.

Agents and env

Scoped MCP should inspect and operate projects without becoming a secret exfiltration channel. Do not ask an editor to dump env into the chat log. Do not store tokens in prompts. Prefer “switch to the acme-staging profile and restart” over “here is the key again.”

If an agent needs a value, it should read from the local profile the same way the process does — on the machine, under your supervision — not from a pasted block in Slack.

Practical setup steps

Start from .env.example (or the framework equivalent). Fill gaps deliberately.
Create a profile named for the context (client-acme, personal, demo-sanitized).
Attach the profile to the lane/project you will actually run.
Start the group; confirm the process sees the expected APP_ENV / keys via a safe check (health, not printenv in a ticket).
For a second Mac, restore Continuity only when you intend that machine to hold those secrets.
When the client engagement ends, delete or rotate the profile values; do not leave them “for next time.”

Edge cases

Homedir dotfiles repos. Convenient for shell aliases; catastrophic for client .env files committed by accident. Keep secrets out of git entirely.

Shared studio login accounts. Prefer per-user profiles and seats over one Mac user with every client key in one folder named envs.

Sanitized demo data. A demo profile with fake keys is fine for Live Link rehearsals. Label it demo so nobody points it at a real billing API.

Procfile hard-coding. Keep secrets in lanes/env profiles — not hard-coded in the Procfile. The Procfile starts processes; profiles supply config.

Travel Mac firefight. Restoring Continuity so you can ship a hotfix is fine. Leaving the client profile on that laptop for three months is how personal and client contexts blur. After the firefight: switch back to personal, remove or rotate what you do not need, and confirm the next morning group still starts with the right profile name visible on the board.

Onboarding a contractor. Give them fill-from-example plus a time-boxed profile, not your full vault. When the contract ends, rotate the values they held — do not rely on “they deleted the folder.” Profiles make that rotation a named action instead of archaeology in ~/old-projects.

Fill from example. Name the blast radius. Switch on purpose. Sync the shape when you mean to — not because hope said the personal laptop would never see client keys.

One more habit that pays rent: when you start a group, glance at the active profile name the same way you glance at the branch. Wrong branch ships the wrong code; wrong profile ships the wrong credentials — often with fewer obvious clues until a webhook fires somewhere you did not intend.

https://userig.app/blog/env-profiles-client-vs-personal