# Migrating from EnvKey: moving your environments

> EnvKey Cloud closed on February 1, 2025, and the open source code hasn't changed since. How to export what's left, flatten it, and keep the encryption model.

URL: https://crunu.com/blog/migrate-from-envkey
Language: en
Updated: 2026-10-30

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](https://crunu.com/alternatives/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](https://github.com/envkey/envkey)). 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](https://news.ycombinator.com/item?id=41134184)).

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](https://github.com/envkey/envkey/commits/main), [releases](https://github.com/envkey/envkey/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](https://crunu.com/learn/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.

*Figure: Diagram of who can decrypt EnvKey values, split into your side and the provider side. On your side, your team’s devices, your machines, and CI runners can decrypt. On the provider side, the EnvKey service stores only ciphertext and holds no key.*

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](https://github.com/envkey/envkey/blob/main/public/app/client/cli/src/commands/envs_cmd/export.ts)). The command sits in the `envs` group:

```sh
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:

```sh
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](https://crunu.com/docs/getting-started/first-project).

*Figure: Priya Natarajan dragged the .aws folder from her computer onto the payments-api production environment. Crunu recognized two files and proposes where each one goes: \~/.aws/config, marked as able to run commands, and \~/.aws/credentials. Only field names such as aws_access_key_id are listed; values are not shown. The cursor rests on Add (2).*

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`:

```sh
# 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](https://crunu.com/rotate/aws) 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](https://crunu.com/guides/who-can-decrypt-your-secrets) compares destinations by where values get decrypted.

## Sources

- [EnvKey README, GitHub](https://github.com/envkey/envkey), checked October 30, 2026.
- [EnvKey commit history, GitHub](https://github.com/envkey/envkey/commits/main), checked October 30, 2026.
- [EnvKey releases, GitHub](https://github.com/envkey/envkey/releases), checked October 30, 2026.
- [EnvKey CLI source: envs export, GitHub](https://github.com/envkey/envkey/blob/main/public/app/client/cli/src/commands/envs_cmd/export.ts), checked October 30, 2026.
- [EnvKey winding down, Hacker News](https://news.ycombinator.com/item?id=41134184), checked October 30, 2026.