envd Development Environments
Build reproducible, cached container environments for AI/ML workloads across local machines and Kubernetes.
- Source repo
- tensorchord/envd
- Stars
- ★ 2.2k
- Last updated
- 16d ago
- License
- Apache-2.0
- Primary language
- Go
- FA score
- 62/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platform
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An AI/ML team standardizing Python, Conda, CUDA, and system dependencies can keep the environment definition in build.envd instead of scattered setup scripts.
- Not a fit if
- Teams without Docker 20.10.0 or newer available
- Projects still on v0 syntax that cannot migrate build.envd
- Environments that must run fully offline without any registry access
- Source review
- 62/100 · Some gaps 2 safety controls not found
What does this agent do, and when should you use it?
envd is a command-line tool for defining AI/ML development environments in a build.envd file. The manifest can declare the base environment, language runtimes, packages, shell, and services such as Jupyter through Python-style functions. envd parses that declaration, uses BuildKit to construct an isolated environment, and produces an OCI-compatible image. The same envd up workflow can target a local machine or a Kubernetes cluster by switching contexts. It also supports remote builds, package caching, registry distribution, and reusable functions imported from Git repositories; Docker 20.10.0 or newer is required.
A user defines build() in build.envd with interfaces such as base, install.conda, install.python, install.python_packages, shell, and config.jupyter. envd up parses the manifest and dependencies, builds the container image through BuildKit, prepares the work directory, and attaches the user to the isolated environment; --detach leaves it running in the background. envd envs ls reports environment status, image, container ID, SSH target, and any Jupyter endpoint. envd context use local and envd context use cluster select the local or Kubernetes execution boundary. Remote builds can run on another machine and push the resulting image to a registry, while include loads reusable envd functions from Git repositories.
- An AI/ML team standardizing Python, Conda, CUDA, and system dependencies can keep the environment definition in build.envd instead of scattered setup scripts.
- A developer training, fine-tuning, or serving models can work inside an isolated environment packaged as an OCI-compatible image.
- An engineer with a resource-constrained workstation can build on a more powerful remote machine and push the image to a registry.
- A team working across laptops and Kubernetes clusters can switch envd contexts while retaining the same envd up workflow.
- A project that frequently rebuilds environments can reuse BuildKit-backed PyPI and APT caches instead of downloading every package again.
- A team maintaining standard components such as TensorBoard can publish envd functions in Git and import them with include.
How do you install or deploy this agent?
The documented runtime requirement is Docker 20.10.0 or newer. Install or upgrade envd with pip:
pip install --upgrade envdBootstrap it after installation:
envd bootstrapA docker.io mirror can be configured during bootstrap:
envd bootstrap --dockerhub-mirror https://docker.mirrors.sjtug.sjtu.edu.cnA downloadable binary release is also mentioned, although the supplied material does not provide a direct download command.
How do you use this agent?
Clone the quick-start project:
git clone https://github.com/tensorchord/envd-quick-start.gitIts build.envd can contain:
def build():
base(dev=True)
install.conda()
install.python()
# Configure the pip index if needed.
# config.pip_index(url = "https://pypi.tuna.tsinghua.edu.cn/simple")
install.python_packages(name = [
"numpy",
])
shell("fish")Build and enter the environment:
cd envd-quick-start && envd upTo enable Jupyter, add this call inside build():
config.jupyter()Start in detached mode and retrieve the endpoint:
envd up --detach
envd envs lsSelect local or cluster execution with:
envd context use local
envd up
envd context use cluster
envd upWhat are this agent's strengths and limitations?
- The Python-style build.envd interface declares Conda, Python packages, shells, and Jupyter without introducing a separate environment DSL.
- The resulting environment image follows the OCI image specification and can be distributed through registries such as Harbor or Docker Hub.
- One CLI workflow covers local machines and Kubernetes clusters, with remote building also supported.
- BuildKit-backed PyPI and APT caches can reuse prior downloads and shorten repeated builds.
- The include function imports shared environment functions from Git repositories, reducing copied Dockerfile instructions.
- Docker 20.10.0 or newer is a hard documented prerequisite, so adoption depends on an available container runtime.
- The local and cluster workflows share an interface, but the supplied material does not fully specify the Kubernetes setup and operational prerequisites.
- Version 1.0 changed both the default build.envd syntax and the default builder, creating migration work for projects that still use v0.
- Remote builds and image sharing require additional infrastructure such as a remote build machine and container registry.
- There is no documented native integration with ChatGPT, Codex, Claude, or their model APIs; a repository topic alone is not evidence of such support.
How does this agent compare with similar options?
Compared with Dockerfile v1, envd explicitly supports PyPI caching and expresses the environment through Python-style build.envd declarations. Within envd, v1 adds the moby builder and documents stronger support for serving, custom base images, and installing multiple languages. Both v0 and v1 support development mode and CUDA, while the comparison table marks serving, custom images, and multi-language installation as limited in v0 and states that v0 does not support the moby builder.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| envd Development Environments This agent | 62 · Some gaps | CLIFree | ★ 2.2k | 16d ago | Go | — |
| Cynative Security Agent Framework | 74 · Some gaps | CLIFree + model costs | ★ 223 | today | Go | OpenAI API · Claude API |
| Sico Digital Worker Platform | 72 · Some gaps | Self-hosted serviceFree + model costs | ★ 283 | 1mo ago | Python | OpenAI API · Claude API |
| Archestra | 71 · Some gaps | Self-hosted serviceFreemium | ★ 4.4k | today | TypeScript | Codex · Claude Code · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
The README exposes container isolation, host mounts, port publication, SSH-key installation, remote builds, registries, and cluster interaction, while the license and contributor records provide meaningful attribution. Deductions apply because the example shell runs as sudo and the supplied files show no least-privilege model, hazardous-action confirmation, permission inventory, or rollback procedure. Telemetry is visible only indirectly through a CI opt-out variable, without documented payloads, destinations, or defaults. Handling guarantees for credentials, SSH keys, and registry authentication are also absent. Go modules are versioned, but the dependency surface is large and CI uses master, latest, and tag-only Actions without supplied vulnerability-scanning or supply-chain mitigation evidence.
The product description, build.envd examples, envd up workflow, and CI build, unit-test, and two end-to-end test jobs form a reasonably consistent static account. Docker's minimum version and principal Go dependencies are documented. Points were deducted because operation depends on Docker, BuildKit, package indexes, Git repositories, registries, and optional cloud services without describing degraded or offline behavior. User-facing failure diagnostics, error categories, and recovery guidance are sparse; most shown output is a successful run.
The evidence thoroughly identifies AI/ML developers, team reuse, Python/R/Julia, local and remote builds, Kubernetes, Jupyter, training, and serving scenarios. Docker 20.10+, the v0/v1 comparison, and a host-directory permission note establish useful boundaries, but the platform matrix, resource requirements, network constraints, and unsuitable scenarios remain incomplete. Actions are precisely initiated through explicit manifest functions and commands such as envd bootstrap, envd up, and context use. Local and cluster contexts, OCI compatibility, Linux CI, and a macOS build provide strong environment-fit evidence.
The README has a strong progression from purpose and benefits through installation, quick start, Jupyter, migration, documentation, roadmap, and contribution guidance, with directly usable commands and manifests. Naming is clear, although the v0-to-v1 change altered the default syntax and builder and is mitigated mainly by migration documentation. Examples are extensive, but no substantive FAQ is supplied. Known limitations are scattered across the Docker requirement, permission note, and syntax table rather than collected explicitly. The complete Apache-2.0 license and TensorChord copyright notice justify full license credit. A tag-triggered changelog workflow demonstrates version-history machinery, but no changelog contents or compatibility policy are supplied. Contribution routes and credited maintainers are visible, while security ownership, support commitments, and a definitive maintenance owner are not; registry-unverified publisher identity is treated as unknown rather than adverse.
The documented outputs are usable container development environments, OCI images, Jupyter endpoints, and reusable build manifests, supported by concrete commands and representative output. Declarative multilingual setup, caches, remote building, reusable team functions, and portable local/cluster contexts offer clear marginal value over maintaining raw Dockerfiles. Full cost-benefit credit is withheld because efficiency claims are not benchmarked and the large dependency graph, Docker bootstrap, image transfers, and optional cluster infrastructure impose unquantified costs.
Most central capabilities map to commands, build.envd snippets, terminal output, dependency declarations, or CI jobs, giving moderate claim traceability. The README, go.mod, and workflows corroborate the Go implementation, container-building role, tests, and external dependencies. Deductions apply because this review did not execute anything, badges and example logs do not establish the state of the specified revision, and claims such as faster, efficient, seamless, and reproducible are presented largely as product assertions without explicit separation from measured facts or inference.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- envd can mount host directories, install SSH keys, expose ports, push images, and affect remote or Kubernetes environments. Review untrusted build.envd files and included Git repositories before use, and constrain credentials and host paths.
- CI exposes an ENVD_ANALYTICS opt-out, but the supplied user documentation does not explain telemetry defaults, fields, recipients, or retention.
- The dependency and CI Action surface is large, with master, latest, and tag-only references. Independently check provenance, digest pinning, and known vulnerabilities before adoption.
- No first-class preview, confirmation, or rollback workflow is evidenced. Apply external change control and recovery measures to image publication, cluster deployment, mounts, and cache changes.
- This assessment is static and limited to the supplied files; no build, test, security scan, or example output was independently executed or verified.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Changelog Bug Fix 🛠 * 9d575b354ce17a02ef9698b6ff0d5d14296c5734: fix: prevent TOCTOU in requirements file reads (#2119) (@kemingy) Documentation 🖊️ * 64bfe688f2a55173366a3eccb877622991dae41d: docs: updated CHANGELOG.md (#2117) (@github-actions[bot]) Others: * 968bc49d577e6c3c5bbb9e6587542c9ddfe66dad: chore(deps): bump the all-dependencies group across 1 directory with 2 updates (#2118) (@dependabot[bot])View on GitHub ↗ -
Release notes excerpt
Changelog Bug Fix 🛠 * 4ca4fdd262d266e446484522a117033765d54f43: fix: always create the compdef before r-w-o zshrc (#2084) (@kemingy) * f576c92c1e6dcb9b00b60995534aeb2a83b0b407: fix: restrict install.python_packages paths to the build context (#2112) (@kemingy) Documentation 🖊️ * 376d0713fdc27abe63e23af59f047169fb51ecc6: docs: add AGENTS.md with repo layout and development guide (#2115) (@kemingy) * e8254329e9f338c221cc0d1c54b2a3032349c05e: docs: updated CHANGELOG.md (#2077) (@github-actions[bot]) Others: …View on GitHub ↗ -
Release notes excerpt
Changelog Exciting New Features 🎉 * c49ed2cb7fdeaa5d966ca36181b7ce27bc6fdf6a: feat: add the build.envd file to this repo (#2082) (@kemingy) * 3cac99fd121961eae2ce0bb634a026891b8e77df: feat: get the latest github release tag for codex (#2081) (@kemingy) * d7379df920a3305191f834e1539f3b4bfd9f084f: feat: support --cap for envd up (#2078) (@kemingy) Others: * 38015c99198dc8490301c9662c1bdce7d650e4df: chore(deps): bump pypa/cibuildwheel from 3.3.0 to 3.3.1 in the all-actions group (#2079) (@dependabot[bot])View on GitHub ↗