envio: encrypted environment variable profiles for the command line

envio replaces the plaintext .env file with an encrypted profile

envio is a command-line tool for managing environment variables, and its central idea is that the variables for a project live in an encrypted profile rather than in a .env file sitting in the working tree. The project description calls it a secure tool for managing environment variables, and the operations it offers are the ones you would expect from that premise: create encrypted profiles holding the variables for a specific project or use case, start a new shell session with the profile values injected, and run a program with the profile applied.

That is a narrower scope than a configuration management system, and the narrowness is the point. envio is not trying to become a secret manager with roles, audit logs and rotation policies. It is a single binary that holds a set of variables, decrypts them on demand and hands them to a process. The feature list in the README is short: encrypt profiles using different encryption methods, start new shell sessions with profile environment variables injected, run programs with your profiles, and more.

How a profile reaches a running process

The data flow has two ends, and they are where the design choices sit. On the writing side, a profile is created for a specific project or use case, and the values inside it are encrypted. On the reading side there are two distinct paths, and the difference matters in practice. Starting a shell session injects the profile environment variables into that session, so every command you then run sees them, including the interactive ones. Running a program applies the profile to that one invocation, so a build script or a test runner gets the values without a shell being involved.

A tool that only did the second thing would be a thin wrapper around export. The shell session mode is what makes envio interesting, because it removes the step where you export variables by hand in every terminal you open. The project also describes the low level blocks as reusable pieces, and mentions completions, man pages and a usage guide in the repository layout, which is the usual set of files for a tool that is meant to live inside a shell workflow rather than be run occasionally from a menu.

One Rust package that is both a binary and a library

envio ships as a Cargo package named envio, and the manifest makes it clear that the crate is meant to be consumed two ways. The package defines a library target and a binary side by side:

[package]
name = "envio"
version = "0.8.0"
rust-version = "1.93.0"
edition = "2024"
license = "MIT/Apache-2.0"

[lib]
name = "envio"
path = "src/lib.rs"
doctest = false

The application feature is enabled by default and is described in the manifest as the feature that is disabled when envio is used as a library. In other words, the heavy command-line stack is optional, and a Rust program that wants the profile handling can depend on the crate without pulling in the whole terminal interface. The feature list itself reads like a description of what the command-line program does: clap for the argument parsing, colored for output, comfy-table for tabular listings, indicatif for progress, inquire for prompts, ratatui for a full terminal interface, keyring for credential storage, and yaml, toml-free serialization through serde_yaml plus postcard for compact binary encoding. The presence of ratatui and indicatif is the clearest signal that this is meant to be an interactive terminal program rather than a script you pipe into.

Encryption and key storage: what the dependency list shows

envio states that it can encrypt profiles using different encryption methods, and the dependency list gives a fairly precise picture of the crypto underneath. Two crates stand out:

argon2 = { version = "0.5.3", features = ["zeroize"] }
chacha20poly1305 = { version = "0.10.1", features = ["stream"] }
keyring = { version = "4.1.2", features = ["v1"], optional = true }

Argon2 carries the zeroize feature, which is about clearing secrets from memory, and ChaCha20-Poly1305 is enabled in its stream mode, which suits encrypting a profile incrementally rather than as one buffer. The optional keyring dependency points at the operating system credential store as a place to keep something key related. What the README does not do is describe the key management flow, so how a profile key is derived, where it is stored and what happens when that store is empty are questions the dependency list raises but does not answer. The usage guide in docs/usage.md is the place to look for that, and the project points readers there for detailed instructions.

For a tool whose entire pitch is security, that gap is the first thing to check before you trust it with a real credential.

Installing envio on Linux, macOS and Windows

Installation is the best documented part of this project. Pre-built binaries for Linux, macOS and Windows are available on the releases page, and the install script covers Linux and macOS:

curl -fsSL https://raw.githubusercontent.com/humblepenguinn/envio/main/install.sh | bash

The script takes two environment variables. ENVIO_INSTALL_DIR sets the target directory, and the default is ~/.local/bin:

curl -fsSL https://raw.githubusercontent.com/humblepenguinn/envio/main/install.sh | ENVIO_INSTALL_DIR=/usr/local/bin bash

ENVIO_VERSION pins a specific release instead of taking the latest. The same script handles removal:

curl -fsSL https://raw.githubusercontent.com/humblepenguinn/envio/main/install.sh | bash -s -- uninstall

The other routes are the usual ones for a Rust CLI. Cargo installs from crates.io:

cargo install envio

On macOS the formula is:

brew install envio

On Arch Linux an AUR helper installs the package, with a second package for the pre-built binary:

paru -S envio      # or envio-bin for pre-built binary

On Debian and Ubuntu a .deb package is published, and the command takes the version and architecture placeholders:

sudo dpkg -i envio_<version>_<arch>.deb

On Windows you download the MSI installer or the zip archive from the releases page. One inconsistency is worth flagging: the .deb and Windows instructions point at a releases page under a different GitHub organisation than the project itself, so verify which repository you are downloading from before installing a package on a machine that matters.

Building from source and running envio in a container

The repository carries the full Rust build setup. The manifest pins rust-version 1.93.0 and edition 2024, so a recent stable toolchain is needed. The Makefile wraps the common cargo tasks, and the underlying commands are the standard ones:

cargo build $(CARGO_FLAGS)
cargo fmt
cargo clippy $(CARGO_FLAGS) --all-targets
cargo install --path . $(CARGO_FLAGS)

A Dockerfile is included, and it builds in two stages from rust:1.93.0-slim-bookworm, then copies the release binary into debian:bookworm-slim. The final image is deliberately unprivileged: it creates a user called envio, chowns the working directory to it, switches USER to envio, and sets HOME accordingly, so a container that holds decrypted variables does not run them as root. The compose file that goes with it is minimal:

services:
  envio:
    build:
      context: .
      dockerfile: Dockerfile
    image: envio:latest

The image name and service name are both envio, and the container starts a shell rather than a fixed command, which is the sensible choice for a tool whose main job is to launch a shell session with variables loaded. A Dockerfile at the root plus a docker-compose.yml means the tool can live inside a development container without secrets being written into the image or the compose file.

Where envio's documentation runs out

The README is short by design, and it is explicit about where the rest of the information lives. Usage is delegated to a usage guide at docs/usage.md, contribution guidance to CONTRIBUTING.md, and there is a SECURITY.md in the repository alongside a code of conduct and a changelog. The completions, man and scripts directories at the top level suggest shell completion and packaged manual pages are handled, and Cross.toml points at cross-compilation for release builds.

The gap that matters for an adopter is that the README never lists the commands. It says the tool provides operations to manage profiles, to load them into terminal sessions and to run programs with them, but the concrete subcommands, the profile file format and the location on disk are all in the usage guide. Anyone evaluating envio will have to read that guide to answer the question that actually matters, which is whether a profile can be created and unlocked non-interactively, since that is what a CI job would need. The README also does not document how encryption methods are selected, how a profile is named or shared between machines, or how the keyring entry behaves when the underlying credential store is unavailable on a headless machine.

Editorial conclusion

envio suits developers and small teams who need more than one set of environment variables and would rather not keep them in plaintext in a repository, and it suits anyone who wants the environment loaded into a shell rather than pasted into a command. It does not suit teams that need shared secret rotation, a team-wide variable catalogue or an audited pipeline, since the project does not describe any of those. Before adopting it, read docs/usage.md to see how profiles are created and unlocked, confirm that your platform is covered by the install path you intend to use, and check whether the key storage model on your machine is workable, because the README does not document how the encryption key is protected. The last push was on 2026-06-23 and the current release is v0.8.0.

Frequently asked questions

Official sources

1. humblepenguinn/envio on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases