Sharing environment variables securely with your team: what dotvault is, and where this series takes you

The person receiving a .env from dotvault signs in once with dotvault login, and from then on it is one command: dotvault pull. Nothing is pasted into Slack. In November, dotvault opens to everyone, free: unlimited projects and keys for an individual, and 10 people, 25 projects and 14 days of audit log for a team.

This is part 1 of 12. It defines what dotvault is, why I built it, the vocabulary, and what each of the following parts lets you do. It contains no setup steps; those start in part 2, one screenshot at a time.

The short version

• dotvault stores the secrets in your .env, your config files and your key/value pairs server-side, encrypted, and hands them to any authorised person, CI job or AI agent with one command. Users sign in with email and password. The login token goes into the OS keychain (on macOS, Keychain), not into a plain-text file.
• Once you are signed in, receiving is one command: dotvault pull. If you do not want a .env file on disk, dotvault run -- <command> injects the values into the child process instead. Part 2 walks through it.
• CI and AI agents authenticate without a human password. CI gets one service token. An AI agent gets two tokens, one to create projects and one to read secrets. Parts 7 and 8.
• Inviting people, limiting what they see and shutting a leaver out happen on the same screens. Four roles: owner / admin / writer / reader. Parts 9 and 10 show, with screenshots, how to decide who sees what.
• dotvault becomes free for everyone in November. The dotvault I introduced in an earlier article was only available to accounts we created and handed out. Letting anyone create an account and use it for free is what "release" means in this series.

Before you read on

• Who this is for. Developers who want to automate their work, sole proprietors and small teams. Not secret-management specialists; people who still hand a .env to a colleague by hand.
• Dates. Screens and numbers were checked on October 17, 2026 against production at app.dotvault.io and the latest published CLI, 0.15.7. The free-plan numbers are the values decided for the release; part 12 re-checks them on the live screens on release day.
• Demo account. Every email address and value on the screenshots belongs to a demo account made for this series. No customer organisation or value is shown.
• Vocabulary. "Secret" in this article means any value that must not leak: API keys, passwords, connection strings. A .env is a file that lists them as KEY=VALUE, one per line.

What dotvault is

dotvault keeps your .env, any config file, and key/value secrets on the server side, encrypted, and lets an authorised person, CI job or AI agent fetch them with one command. You use it through an admin console in the browser and a CLI in the terminal.

The console sign-in screen has two fields: an email address and a password.

In the CLI, the first line of dotvault --help describes it on its own:

dotvault — sync .env / .npmrc / .gitconfig and any config file across machines and CI/CD. No AWS account required.

So it is not only .env. An .npmrc, a .gitconfig or a kubeconfig travels through the same path. The login token is stored in the OS keychain, so you do not end up with another plain-text credential file next to the .env you were trying to get rid of.

Why I built it

For years I kept secrets in AWS Parameter Store and typed aws ssm put-parameter every time a value changed. A new team member got their .env as a Slack DM. You are not allowed to distribute secrets, and you have to distribute them anyway; that contradiction is the whole story of the earlier article.

I looked at Doppler and Infisical before writing anything. Three things I wanted did not come together in one product: teams under an organisation, an audit log on the free plan, and no cap on the number of versions a value keeps. So I built one around the shape of our own organisation.

The idea behind it, one place for storage, permissions and audit, is explained with four screenshots in the earlier article, and I will not repeat it here. In one paragraph: secrets live on the server, not in the repository; each project is split into development, staging and production; people and machines each get access to specific projects; and actions such as inviting people and granting or revoking access are recorded in an Audit Log. This series does not re-explain that. It shows the screens and adds one operation per part.

What the receiving side does

In the user's own words, dotvault has three goals.

• One command to receive, once you are signed in. On a new machine, run dotvault login once. From then on, dotvault pull in the project folder writes the secrets you are allowed to see into .env. If you would rather not have the file at all, prefix your start command: dotvault run -- npm run dev.
• CI and AI agents authenticate without a human. CI gets a service token limited by role, project and expiry. An AI agent gets two tokens, one to create projects and one to read secrets. Part 8 shows how to hand project creation, import and pull to the agent with them.
• No plain-text secret where it does not belong. The login token sits in the keychain. dotvault run does not write a .env file; it passes values only to the child process. dotvault scan finds secrets in files before you commit them.

The whole CLI fits on one screen of dotvault --help, and nearly every command this series presses is on it.

The seven lines under Common workflows are this series in miniature. First-time setup and Local dev are part 2, Roll back a secret is part 4, Share a key org-wide is part 6, CI/CD pull and Mint a CI token are part 7, and Audit history is part 10.

The vocabulary, on one screen

The sidebar of the admin console carries every term this series uses. This is what you see when you sign in to a Personal organisation, the kind you get for yourself.

The terms nest from the outside in.

Term	Meaning	Part
Organization	The outermost container. Personal is just you, with no permission settings. Company is where you invite people. Part 9 shows how to switch from Personal to Company	2, 9
Project	One app or repository. Your .env lives under it	3
Environment	development, staging and production inside a project, plus Common (named _shared in the CLI), which every environment reads. You can add your own	3
Key	One KEY=VALUE line. Every write keeps a version, and you can roll back	4
File	Something you ship whole, such as .npmrc or a kubeconfig	5
Global Keys	Keys shared across the organisation, bound to each project explicitly	6
Service token	A token for CI or an AI agent, limited by role, project and expiry	7, 8
Project roles	owner / admin / writer / reader; part 9 shows how to assign them	9
Organisation roles	org_admin / member / guest; part 9 shows what each one can see	9
Audit Log	A record of organisation actions such as inviting people and granting or revoking access. Part 10 shows what is recorded	10

In a Personal organisation the sidebar hides Teams and My Organizations. Switch to a Company organisation and the heading becomes Workspace, with those two added. Part 9 shows that screen.

Where this series takes you

Parts 2 to 12, each one named after the problem it removes and what you can do once you have read it. Each part adds one operation.

Part	The problem	What you can do afterwards
2	Hunting for a .env on every new machine	Get your project's .env in four steps: install, login, init, pull / run. Appendix: password reset, language, logout
3	Keeping development and production .env files apart by hand	Create a project, use three environments plus Common, compare and copy values between them, archive and delete a project
4	Overwriting a value by mistake	Write keys from the console and the CLI, pull them, list versions and roll back
5	Passing .npmrc and kubeconfig from person to person	Push whole files, and stop leaks before a commit with scan
6	Pasting the same SENTRY_DSN into eight projects	Store an organisation-wide key once in Global Keys and bind it per project
7	A human password sitting in CI	Mint a service token, pull production values from GitHub Actions, revoke it from the console
8	Pasting .env into Claude Code	Give an AI agent two tokens and let it create a project, import and pull unattended
9	Not knowing how to cut off someone who left	Switch to a Company organisation, invite by email, grant four roles per environment, grant by Team, shut a leaver out in 60 seconds
10	Not being able to tell who changed what	Read the Audit Log and a Team's access history, and check your usage against the free plan
11	Stopping a leaked key in one command	Retire a leaked key immediately and read version states
12	A new member pulling on day one, in five minutes	Reproduce the whole path on a fresh account and hand the write-up to your team. This part is release day

At the end you can do five things yourself: keep your project's .env in dotvault and pull it on any machine with one command; keep human passwords out of CI; stop pasting secrets into AI agents; invite people, limit what they see and shut a leaver out right away; and retire keys and projects safely when you are done with them.

Free for everyone from November

dotvault opens for self-service sign-up in November. The free plans:

• Personal (just you). Unlimited projects, up to 10 environments per project, unlimited keys.
• Company, free plan (your team). Up to 10 people, 25 projects, 10 environments per project, unlimited keys, 14 days of audit log.

The reason for giving it away is plain. I want fewer teams handing secrets around by hand, and I want the people who try it to find our other products afterwards.

Next

Part 2: "Four steps to your first .env out of dotvault, in five minutes." A Personal organisation, from install to the first pull, one screenshot per step.