Migrating from EnvKey: moving your environments

EnvKey Cloud shut down on February 1, 2025, and the open source repository hasn't had a commit since the wind-down notice of August 1, 2024. If you still run a self-hosted EnvKey, or still have files exported during the wind-down, migrating means four things: export each environment with the EnvKey CLI while it still runs, flatten branches, inheritance and blocks into plain values, load those values into a tool that also encrypts on your devices, and replace envkey-source and every ENVKEY in servers and CI. Values move. History, access rules and EnvKey's structure don't.

If you're still choosing where to go, Crunu vs EnvKey compares the options. This post is about the move itself, and about keeping what made EnvKey worth choosing.

Where EnvKey stands

The README's notice is short: "as of August 1st, 2024, EnvKey Cloud is beginning a six month wind down. It will shut down on February 1st, 2025", and "new registrations are now disabled" (EnvKey README). The email to customers, posted on Hacker News and confirmed in the thread by the email's author, adds that "the EnvKey company will be dissolved" (Hacker News).

The code is MIT-licensed, but the README notes that "EnvKey's Cloud and Business Self-Hosted products include commercially licensed server-side extensions." On GitHub, the last commit is that README update of August 1, 2024, and the last release is cli-v2.5.0 from March 12, 2024 (commits, releases). A self-hosted install keeps working until something around it changes: an operating system update, a dependency with a security fix, a certificate. Each of those is now yours to handle.

What to keep from EnvKey's model

EnvKey described itself as "end-to-end encrypted with NaCl": values were encrypted on devices, a model known as client-side encryption, and the server held ciphertext. That property is easy to lose in a migration, because several well-known replacements decrypt on their own servers. Before you pick a destination, decide whether you're keeping it.

The things worth carrying over:

• Encryption on devices. The service stores ciphertext and can't read values. In Crunu, encryption happens only in the browser and in the crunu agent; the server stores ciphertext, public keys, signed documents and metadata such as names.
• Separate keys per environment. Access to development shouldn't open production. Crunu gives each environment its own key, sealed separately to each person and machine that may read it.
• Device-based access. EnvKey tied access to devices. In Crunu, each browser or computer you sign in from is a device in your account, and signing in needs your password and your Secret Key, which never leaves your devices.
• A command wrapper instead of files. envkey-source -- any-shell-command ran a program with the latest variables. crunu run does the same.

Plan the order before you export

A migration goes wrong in the gap between the export and the last consumer switching over. Values change in one place and not the other, and a server restarts with yesterday's database password. A few rules keep that gap short:

• Freeze changes in EnvKey from the moment you export. If a value must change, change it in both places and write it down.
• Move consumers from least to most critical. Developers' laptops and CI first, then staging servers, then production, one service at a time.
• Run both side by side until the last consumer has switched. EnvKey stays read-only during that time, not switched off.
• Name one owner for the migration who keeps the list of apps, environments and consumers, and ticks each one off.

Keep this window short: the longer it stretches, the more the two copies drift.

Step 1: export while it still runs

The EnvKey CLI has an export command. In its source, the syntax is export [app] [environment] [filepath], with --format set to json by default and also accepting yaml, env and json-pretty (EnvKey CLI source). The command sits in the envs group:

envkey envs export web-app development development.env --format env
envkey envs export web-app staging staging.env --format env
envkey envs export web-app production production.env --format env

web-app is an example app name. Do this on a trusted computer, into a directory that isn't synced or backed up, and keep a list of what you exported. If an environment is "not available for export", your account lacks access to it; export it as someone who has.

If the self-hosted server is already gone, your sources are the files exported during the wind-down. Treat them as the only copy: check where they've been stored since, because a file in a shared drive or a chat for two years has been readable by more people than the vault ever was.

Step 2: flatten branches, inheritance and blocks

EnvKey's README lists "re-usable blocks, branches, environment inheritance" among its features. Those are structure, and most destinations, Crunu included, don't model them. Crunu has no references between values and no inheritance between environments: each environment holds its own files.

The source of the export command defines no option to include or exclude inherited values, so check what you got. Compare the variable names in each export with the names your application really receives, without printing values:

envkey-source -- sh -c 'env | cut -d= -f1 | sort' > names-from-envkey.txt
grep -o '^[A-Za-z_][A-Za-z0-9_]*' development.env | sort > names-from-export.txt
diff names-from-envkey.txt names-from-export.txt

The first list also contains your shell's own variables such as PATH; ignore those. A name that's in the first list and not the second came from somewhere the export didn't cover, such as a block or a parent environment. Add it to the file by hand.

Branches need a decision rather than a command. A branch used for one developer's local overrides belongs in that developer's personal space. In Crunu, each member has a Personal project for their own files. A branch used for a long-lived variant, such as a second region, is a separate environment.

Step 3: load the values

In Crunu, create a project for each EnvKey app and an environment for each environment. When you create a project, dev and prod are selected; tick stage or name other environments, such as staging, in the same dialog. Then drag the exported .env files into the matching environments. Crunu reads env files as a table of variables, shows the names without values, and saves them as a signed, encrypted version. The full walkthrough is in your first project.

Then compare environments. Compare environments shows which variables exist in only one environment and which differ, with values hidden until you choose Show values. Missing names usually point to a block or inheritance you didn't flatten.

Access rules are rebuilt rather than copied. Give people roles per environment, Editor or Reader, and use access profiles for groups such as "developers get development and staging", so the next hire gets the same set in one step.

Step 4: replace envkey-source and every ENVKEY

Anywhere an app started with envkey-source, start it with crunu run:

# before
envkey-source -- npm start
# after
crunu run --env web-app/production -- npm start

EnvKey's "live reload for environment variables" maps to crunu run --restart on-change, which restarts the program after a value changes.

• Servers that held an ENVKEY get enrolled as machines. The agent runs as a service, keeps decrypted environments only in memory, and serves them to crunu run.
• CI gets a service token per pipeline, granted only the environments it uses. Tokens that read production should have a CI binding (OIDC), so they work only from the right repository and branch.
• Developers sign in on their own computers with crunu login.

Search your repositories, deploy scripts and infrastructure code for ENVKEY and envkey-source before you switch anything off.

Step 5: clean up

1. Delete the exported files and the name lists.
2. Revoke each old ENVKEY and shut down the self-hosted EnvKey servers once nothing reads from them.
3. Reissue values that sat in exports outside the vault. The rotation pages cover the providers you're likely to have.

What doesn't come with you

• History. It starts over: the oldest version in Crunu is the one you import. Keep the old exports' dates in your migration notes if you need to answer "when did this change" later.
• Access rules and audit logs. Recreate access deliberately; it's a chance to remove people who no longer need it. EnvKey's audit log stays with the old server.
• Structure. Blocks, branches and inheritance become plain values per environment.
• Platforms. The crunu agent runs on Linux and macOS. There's no Windows build, so Windows machines that used envkey-source need another arrangement.

The guide on who can decrypt your secrets compares destinations by where values get decrypted.

Sources

• EnvKey README, GitHub, checked October 30, 2026.
• EnvKey commit history, GitHub, checked October 30, 2026.
• EnvKey releases, GitHub, checked October 30, 2026.
• EnvKey CLI source: envs export, GitHub, checked October 30, 2026.
• EnvKey winding down, Hacker News, checked October 30, 2026.