dotenvx is a cross-platform tool designed to simplify environment variable management for developers and DevOps teams. Built by the creator of dotenv, dotenvx enhances security and flexibility with encrypted variables, multi-environment support, and seamless integration across programming languages and frameworks.
Key Features:
Cross-platform compatibility, supporting Windows, macOS, Linux, and other environments.
Multi-environment configuration, allowing users to manage different .env files for development, testing, and production.
Encrypted environment variables, ensuring sensitive data is protected both at rest and in transit.
CLI-based interface enabling direct execution of scripts or commands with injected environment variables.
Support for a wide range of programming languages (Node.js, Python, Go, Rust, Java, etc.) and frameworks (Next.js, Rails, Laravel).
Audience & Benefit:
Ideal for developers working on projects that require secure and efficient management of environment variables. dotenvx helps teams streamline workflows, reduce configuration errors, and enhance security by encrypting sensitive data. It is particularly beneficial for organizations deploying applications across multiple environments or using diverse programming languages.
The tool can be installed via winget on Windows, making it easy to integrate into existing development pipelines.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of the Git SCM to Windows while providing appropriate user interfaces for experienced Git users and novices alike.
GitHub CLI (gh) is a command-line tool that brings pull requests, issues, GitHub Actions, and other GitHub features to your terminal, so you can do all your work in one place.
NuGet is the package manager for .NET. It enables developers to create, share, and consume useful .NET libraries. NuGet client tools provide the ability to produce and consume these libraries as "packages".
The Azure command-line interface (Azure CLI) is a set of commands used to create and manage Azure resources. The Azure CLI is available across Azure services and is designed to get you working quickly with Azure, with an emphasis on automation.
The AWS CLI is an open source tool built on top of the AWS SDK for Python (Boto) that provides commands for interacting with AWS services.
With minimal configuration, you can start using all of the functionality provided by the AWS Management Console from your favorite terminal program.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of the Git SCM to Windows while providing appropriate user interfaces for experienced Git users and novices alike.
GitHub CLI (gh) is a command-line tool that brings pull requests, issues, GitHub Actions, and other GitHub features to your terminal, so you can do all your work in one place.
NuGet is the package manager for .NET. It enables developers to create, share, and consume useful .NET libraries. NuGet client tools provide the ability to produce and consume these libraries as "packages".
The Azure command-line interface (Azure CLI) is a set of commands used to create and manage Azure resources. The Azure CLI is available across Azure services and is designed to get you working quickly with Azure, with an emphasis on automation.
The AWS CLI is an open source tool built on top of the AWS SDK for Python (Boto) that provides commands for interacting with AWS services.
With minimal configuration, you can start using all of the functionality provided by the AWS Management Console from your favorite terminal program.
// index.ts
import chalk from 'chalk'
console.log(chalk.blue(`Hello ${process.env.HELLO}`))
$ npm install
$ echo "HELLO=World" > .env
$ dotenvx run -- npx tsx index.ts
Hello World
Deno ๐ฆ
$ echo "HELLO=World" > .env
$ echo "console.log('Hello ' + Deno.env.get('HELLO'))" > index.ts
$ deno run --allow-env index.ts
Hello undefined
$ dotenvx run -- deno run --allow-env index.ts
Hello World
> [!WARNING]
> Some of you are attempting to use the npm module directly with deno run. Don't, because deno currently has incomplete support for these encryption ciphers.
>
> > $ deno run -A npm:@dotenvx/dotenvx encrypt > Unknown cipher >
>
> Instead, use dotenvx as designed, by installing the cli as a binary - via curl, brew, etc.
Bun ๐ฅ
$ echo "HELLO=Test" > .env.test
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
$ bun index.js
Hello undefined
$ dotenvx run -f .env.test -- bun index.js
Hello Test
$ echo "HELLO=local" > .env.local
$ echo "HELLO=World" > .env
$ dotenvx run -f .env.local -f .env -- node index.js
[dotenvx@1.X.X] injecting env (1) from .env.local,.env
Hello local
Note subsequent files do NOT override pre-existing variables defined in previous files or env. This follows historic principle. For example, above local wins โ from the first file.
--overload flag
$ echo "HELLO=local" > .env.local
$ echo "HELLO=World" > .env
$ dotenvx run -f .env.local -f .env --overload -- node index.js
[dotenvx@1.X.X] injecting env (1) from .env.local,.env
Hello World
Note that with --overload subsequent files DO override pre-existing variables defined in previous files.
--verbose flag
$ echo "HELLO=production" > .env.production
$ dotenvx run -f .env.production --verbose -- node index.js
[dotenvx][verbose] injecting env from /path/to/.env.production
[dotenvx][verbose] HELLO set
[dotenvx@1.X.X] injecting env (1) from .env.production
Hello production
--debug flag
$ echo "HELLO=production" > .env.production
$ dotenvx run -f .env.production --debug -- node index.js
[dotenvx][debug] configuring options
[dotenvx][debug] {"envFile":[".env.production"]}
[dotenvx][verbose] injecting env from /path/to/.env.production
[dotenvx][debug] reading env from /path/to/.env.production
[dotenvx][debug] parsing env from /path/to/.env.production
[dotenvx][debug] {"HELLO":"production"}
[dotenvx][debug] writing env from /path/to/.env.production
[dotenvx][verbose] HELLO set
[dotenvx][debug] HELLO set to production
[dotenvx@1.X.X] injecting env (1) from .env.production
Hello production
--quiet flag
Use --quiet to suppress all output (except errors).
$ echo "HELLO=production" > .env.production
$ dotenvx run -f .env.production --quiet -- node index.js
Hello production
--log-level flag
Set --log-level to whatever you wish. For example, to suppress warnings (risky), set log level to error:
$ echo "HELLO=production" > .env.production
$ dotenvx run -f .env.production --log-level=error -- node index.js
Hello production
Available log levels are error, warn, info, verbose, debug, silly
Note the DOTENV_PRIVATE_KEY_CI ends with _CI. This instructs dotenvx run to load the .env.ci file. See the pattern?
combine multiple encrypted .env files
$ dotenvx set HELLO World -f .env
$ dotenvx set HELLO Production -f .env.production
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
$ DOTENV_PRIVATE_KEY="<.env private key>" DOTENV_PRIVATE_KEY_PRODUCTION="<.env.production private key>" dotenvx run -- node index.js
[dotenvx@1.X.X] injecting env (3) from .env, .env.production
Hello World
Note the DOTENV_PRIVATE_KEY instructs dotenvx run to load the .env file and the DOTENV_PRIVATE_KEY_PRODUCTION instructs it to load the .env.production file. See the pattern?
combine multiple encrypted .env files for monorepo
> secp256k1 is a well-known and battle tested curve, in use with Bitcoin and other cryptocurrencies, but we are open to adding support for more curves.
>
> If your organization's compliance department requires NIST approved curves or other curves like curve25519, please reach out at security@dotenvx.com.
ย
Advanced
> Become a dotenvx power user.
>
CLI ๐
Advanced CLI commands.
run - Variable Expansion
Reference and expand variables already on your machine for use in your .env file.
$ dotenvx run --debug -- node index.js
[dotenvx@1.X.X] injecting env (2) from .env
DATABASE_URL postgres://username@localhost/my_database
run - Default Values
Use default values when environment variables are unset or empty.
# .env
# Default value syntax: use value if set, otherwise use default
DATABASE_HOST=${DB_HOST:-localhost}
DATABASE_PORT=${DB_PORT:-5432}
# Alternative syntax (no colon): use value if set, otherwise use default
API_URL=${API_BASE_URL-https://api.example.com}
$ dotenvx run --debug -- node index.js
[dotenvx@1.X.X] injecting env (3) from .env
DATABASE_HOST localhost
DATABASE_PORT 5432
API_URL https://api.example.com
run - Alternate Values
Use alternate values when environment variables are set and non-empty.
# .env
NODE_ENV=production
# Alternate value syntax: use alternate if set and non-empty, otherwise empty
DEBUG_MODE=${NODE_ENV:+false}
LOG_LEVEL=${NODE_ENV:+error}
# Alternative syntax (no colon): use alternate if set, otherwise empty
CACHE_ENABLED=${NODE_ENV+true}
Note subsequent files do NOT override pre-existing variables defined in previous files or env. This follows historic principle. For example, above local wins โ from the first file.
run --env HELLO=String
Set environment variables as a simple KEY=value string pair.
$ echo "HELLO=World" > .env
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
$ dotenvx run --env HELLO=String -f .env -- node index.js
[dotenvx@1.X.X] injecting env (1) from .env, and --env flag
Hello String
run --overload
Override existing env variables. These can be variables already on your machine or variables loaded as files consecutively. The last variable seen will 'win'.
Note that with --overload subsequent files DO override pre-existing variables defined in previous files.
run - Environment Variable Precedence (Container/Cloud Deployments)
When deploying applications in containers or cloud environments, you often need to override specific environment variables at runtime without modifying committed .env files. By default, dotenvx follows the historic dotenv principle: environment variables already present take precedence over .env files.
# .env.prod contains: MODEL_REGISTRY=registry.company.com/models/v1
$ echo "MODEL_REGISTRY=registry.company.com/models/v1" > .env.prod
$ echo "console.log('MODEL_REGISTRY:', process.env.MODEL_REGISTRY)" > app.js
# Without environment variable set - uses .env.prod value
$ dotenvx run -f .env.prod -- node app.js
MODEL_REGISTRY: registry.company.com/models/v1
# With environment variable set (e.g., via Azure Container Service) - environment variable takes precedence
$ MODEL_REGISTRY=registry.azure.com/models/v2 dotenvx run -f .env.prod -- node app.js
MODEL_REGISTRY: registry.azure.com/models/v2
# To force .env.prod to override environment variables, use --overload
$ MODEL_REGISTRY=registry.azure.com/models/v2 dotenvx run -f .env.prod --overload -- node app.js
MODEL_REGISTRY: registry.company.com/models/v1
For container deployments: Set environment variables through your cloud provider's UI/configuration (Azure Container Service, AWS ECS, etc.) to override specific values from committed .env files without rebuilding your application.
DOTENV_PRIVATE_KEY=key run
Decrypt your encrypted .env by setting DOTENV_PRIVATE_KEY before dotenvx run.
$ touch .env
$ dotenvx set HELLO encrypted
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
# check your .env.keys files for your privateKey
$ DOTENV_PRIVATE_KEY="122...0b8" dotenvx run -- node index.js
[dotenvx@1.X.X] injecting env (2) from .env
Hello encrypted
DOTENV_PRIVATE_KEY_PRODUCTION=key run
Decrypt your encrypted .env.production by setting DOTENV_PRIVATE_KEY_PRODUCTION before dotenvx run. Alternatively, this can be already set on your server or cloud provider.
$ touch .env.production
$ dotenvx set HELLO "production encrypted" -f .env.production
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
# check .env.keys for your privateKey
$ DOTENV_PRIVATE_KEY_PRODUCTION="122...0b8" dotenvx run -- node index.js
[dotenvx@1.X.X] injecting env (2) from .env.production
Hello production encrypted
Note the DOTENV_PRIVATE_KEY_PRODUCTION ends with _PRODUCTION. This instructs dotenvx run to load the .env.production file.
DOTENV_PRIVATE_KEY_CI=key dotenvx run
Decrypt your encrypted .env.ci by setting DOTENV_PRIVATE_KEY_CI before dotenvx run. Alternatively, this can be already set on your server or cloud provider.
$ touch .env.ci
$ dotenvx set HELLO "ci encrypted" -f .env.ci
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
# check .env.keys for your privateKey
$ DOTENV_PRIVATE_KEY_CI="122...0b8" dotenvx run -- node index.js
[dotenvx@1.X.X] injecting env (2) from .env.ci
Hello ci encrypted
Note the DOTENV_PRIVATE_KEY_CI ends with _CI. This instructs dotenvx run to load the .env.ci file. See the pattern?
DOTENV_PRIVATE_KEY=key DOTENV_PRIVATE_KEY_PRODUCTION=key run - Combine Multiple
Decrypt your encrypted .env and .env.production files by setting DOTENV_PRIVATE_KEY and DOTENV_PRIVATE_KEY_PRODUCTION before dotenvx run.
$ touch .env
$ touch .env.production
$ dotenvx set HELLO encrypted
$ dotenvx set HELLO "production encrypted" -f .env.production
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
# check .env.keys for your privateKeys
$ DOTENV_PRIVATE_KEY="122...0b8" DOTENV_PRIVATE_KEY_PRODUCTION="122...0b8" dotenvx run -- node index.js
[dotenvx@1.X.X] injecting env (3) from .env, .env.production
Hello encrypted
$ DOTENV_PRIVATE_KEY_PRODUCTION="122...0b8" DOTENV_PRIVATE_KEY="122...0b8" dotenvx run -- node index.js
[dotenvx@1.X.X] injecting env (3) from .env.production, .env
Hello production encrypted
Compose any encrypted files you want this way. As long as a DOTENV_PRIVATE_KEY_${environment} is set, the values from .env.${environment} will be decrypted at runtime.
$ echo "HELLO=production" > .env.production
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
$ dotenvx run -f .env.production --debug -- node index.js
process command [node index.js]
options: {"env":[],"envFile":[".env.production"]}
loading env from .env.production (/path/to/.env.production)
{"HELLO":"production"}
HELLO set
HELLO set to production
[dotenvx@1.X.X] injecting env (1) from .env.production
executing process command [node index.js]
expanding process command to [/opt/homebrew/bin/node index.js]
Hello production
run --quiet
Use --quiet to suppress all output (except errors). (log levels)
Further, we recommend using DOTENV_ENV over NODE_ENVโ as dotenvx works everywhere, not just node.
$ DOTENV_ENV=development dotenvx run --convention=flow -- node index.js
[dotenvx@1.X.X] injecting env (1) from .env.development.local, .env.development, .env.local, .env
Hello development local
run -fk
Specify path to .env.keys. This is useful with monorepos.
$ mkdir -p apps/app1
$ touch apps/app1/.env
$ dotenvx set HELLO world -fk .env.keys -f apps/app1/.env
$ dotenvx run -fk .env.keys -f apps/app1/.env -- yourcommand
get KEY
Return a single environment variable's value.
$ echo "HELLO=World" > .env
$ dotenvx get HELLO
World
get KEY -f
Return a single environment variable's value from a specific .env file.
$ echo "HELLO=World" > .env
$ echo "HELLO=production" > .env.production
$ dotenvx get HELLO -f .env.production
production
get KEY -fk
Specify path to .env.keys. This is useful with monorepos.
$ mkdir -p apps/app1
$ touch apps/app1/.env
$ dotenvx set HELLO world -fk .env.keys -f apps/app1/.env
$ dotenvx get HELLO -fk .env.keys -f apps/app1/.env
world
get KEY --env
Return a single environment variable's value from a --env string.
$ dotenvx get HELLO --env HELLO=String -f .env.production
String
get KEY --overload
Return a single environment variable's value where each found value is overloaded.
Note that this exports newlines and quoted strings.
This can be useful for more complex .env values (spaces, escaped characters, quotes, etc) combined with eval on the command line.
$ echo "console.log('Hello ' + process.env.KEY + ' ' + process.env.HELLO)" > index.js
$ eval $(dotenvx get --format=eval) node index.js
Hello value World
Be careful with eval as it allows for arbitrary execution of commands. Prefer dotenvx run -- but in some cases eval is a sharp knife that is useful to have.
$ touch .env
$ dotenvx set HELLO World
set HELLO with encryption (.env)
set KEY value -f
Set an (encrypted) key/value for another .env file.
$ touch .env.production
$ dotenvx set HELLO production -f .env.production
set HELLO with encryption (.env.production)
set KEY value -fk
Specify path to .env.keys. This is useful with monorepos.
$ mkdir -p apps/app1
$ touch apps/app1/.env
$ dotenvx set HELLO world -fk .env.keys -f apps/app1/.env
set HELLO with encryption (.env)
Put it to use.
$ dotenvx get -fk .env.keys -f apps/app1/.env
Use it with a relative path.
$ cd apps/app1
$ dotenvx get -fk ../../.env.keys -f .env
set KEY "value with spaces"
Set a value containing spaces.
$ touch .env.ci
$ dotenvx set HELLO "my ci" -f .env.ci
set HELLO with encryption (.env.ci)
set KEY -- "- + * รท"
If your value starts with a dash (-), then place two dashes instructing the cli that there are no more flag arguments.
$ touch .env.ci
$ dotenvx set HELLO -f .env.ci -- "- + * รท"
set HELLO with encryption (.env.ci)
set KEY value --plain
Set a plaintext key/value.
$ touch .env
$ dotenvx set HELLO World --plain
set HELLO (.env)
encrypt
Encrypt the contents of a .env file to an encrypted .env file.
$ echo "HELLO=World" > .env
$ dotenvx encrypt
โ encrypted (.env)
โ key added to .env.keys (DOTENV_PRIVATE_KEY)
โฎ next run [dotenvx ext gitignore --pattern .env.keys] to gitignore .env.keys
โฎ next run [DOTENV_PRIVATE_KEY='122...0b8' dotenvx run -- yourcommand] to test decryption locally
encrypt -f
Encrypt the contents of a specified .env file to an encrypted .env file.
$ echo "HELLO=World" > .env
$ echo "HELLO=Production" > .env.production
$ dotenvx encrypt -f .env.production
โ encrypted (.env.production)
โ key added to .env.keys (DOTENV_PRIVATE_KEY_PRODUCTION)
โฎ next run [dotenvx ext gitignore --pattern .env.keys] to gitignore .env.keys
โฎ next run [DOTENV_PRIVATE_KEY='bff...bc4' dotenvx run -- yourcommand] to test decryption locally
encrypt -fk
Specify path to .env.keys. This is useful with monorepos.
$ dotenvx help
Usage: dotenvx run -- yourcommand
a secure dotenvโfrom the creator of `dotenv`
Options:
-l, --log-level set log level (default: "info")
-q, --quiet sets log level to error
-v, --verbose sets log level to verbose
-d, --debug sets log level to debug
-V, --version output the version number
-h, --help display help for command
Commands:
run inject env at runtime [dotenvx run -- yourcommand]
get [KEY] return a single environment variable
set set a single environment variable
encrypt convert .env file(s) to encrypted .env file(s)
decrypt convert encrypted .env file(s) to plain .env file(s)
keypair [KEY] print public/private keys for .env file(s)
ls [directory] print all .env files in a tree structure
Advanced:
pro ๐ pro
ext ๐ extensions
You can get more detailed help per command with dotenvx help COMMAND.
$ dotenvx help run
Usage: @dotenvx/dotenvx run [options]
inject env at runtime [dotenvx run -- yourcommand]
Options:
-e, --env environment variable(s) set as string (example: "HELLO=World") (default: [])
-f, --env-file path(s) to your env file(s) (default: [])
-fv, --env-vault-file path(s) to your .env.vault file(s) (default: [])
-o, --overload override existing env variables
--convention load a .env convention (available conventions: ['nextjs'])
-h, --help display help for command
Examples:
$ dotenvx run -- npm run dev
$ dotenvx run -- flask --app index run
$ dotenvx run -- php artisan serve
$ dotenvx run -- bin/rails s
Try it:
$ echo "HELLO=World" > .env
$ echo "console.log('Hello ' + process.env.HELLO)" > index.js
$ dotenvx run -- node index.js
[dotenvx@1.X.X] injecting env (1) from .env
Hello World
--version
Check current version of dotenvx.
$ dotenvx --version
X.X.X
Extensions ๐
CLI extensions.
ext genexample
In one command, generate a .env.example file from your current .env file contents.
$ dotenvx-radar login
press Enter to open [https://radar.dotenvx.com/login/device] and enter code [D9C1-03BC]... (Y/n)
โ น waiting on browser authorization
โ logged in [username] to this device and activated token [dxo_6kjPifIโฆ]
$ dotenvx-radar logout
โ logged out [username] from this device and revoked token [dxo_5ZrwRXVโฆ]
status
Check current status of radar - on or off (logged in or out).
$ dotenvx-radar status
on
settings
Check and configure various settings for radar - username, token, and more.
$ dotenvx-radar settings
Usage: dotenvx-radar settings [options] [command]
โ๏ธ settings
Options:
-h, --help display help for command
Commands:
username print your username
token [options] print your access token (--unmask)
hostname print hostname
help [command] display help for command
ย
Whitepaper
> Dotenvx: Reducing Secrets Risk with Cryptographic Separation
>
> Abstract. An ideal secrets solution would not only centralize secrets but also contain the fallout of a breach. While secrets managers offer centralized storage and distribution, their design creates a large blast radius, risking exposure of thousands or even millions of secrets. We propose a solution that reduces the blast radius by splitting secrets management into two distinct components: an encrypted secrets file and a separate decryption key.
>
> ...
>
> Read the whitepaper
ย
Guides
> Go deeper with dotenvx โ detailed framework and platform guides.
>
Dotenvx uses Elliptic Curve Integrated Encryption Scheme (ECIES) to encrypt each secret with a unique ephemeral key, while ensuring it can be decrypted using a long-term private key.
When you initialize encryption, a DOTENV_PUBLIC_KEY (encryption key) and DOTENV_PRIVATE_KEY (decryption key) are generated. The DOTENV_PUBLIC_KEY is used to encrypt secrets, and the DOTENV_PRIVATE_KEY is securely stored in your cloud secrets manager or .env.keys file.
Your encrypted .env file is then safely committed to code. Even if the file is exposed, secrets remain protected since decryption requires the separate DOTENV_PRIVATE_KEY, which is never stored alongside it. Read the whitepaper for more details.
Is it safe to commit an encrypted .env file to code?
Yes. Dotenvx encrypts secrets using AES-256 with ephemeral keys, ensuring that even if the encrypted .env file is exposed, its contents remain secure. The encryption keys themselves are protected using Secp256k1 elliptic curve cryptography, which is widely used for secure key exchange in technologies like Bitcoin.
This means that every secret in the .env file is encrypted with a unique AES-256 key, and that key is further encrypted using a public key (Secp256k1). Even if an attacker obtains the encrypted .env file, they would still need the corresponding private keyโstored separately in a secrets managerโto decrypt anything.
Breaking this encryption would require brute-forcing both AES-256 and elliptic curve cryptography, which is computationally infeasible with current technology. Read the whitepaper for more details.
Why am I getting the error node: .env: not found?
You are using Node 20 or greater and it adds a differing implementation of --env-file flag support. Rather than warn on a missing .env file (like dotenv has historically done), it raises an error: node: .env: not found.
This fix is easy. Replace --env-file with -f.
# from this:
./node_modules/.bin/dotenvx run --env-file .env -- yourcommand
# to this:
./node_modules/.bin/dotenvx run -f .env -- yourcommand
I've decided we should sunset it as a technological solution to this.
The .env.vault file got us far, but it had limitations such as:
Pull Requests - it was difficult to tell which key had been changed
Security - there was no mechanism to give a teammate the ability to encrypt without also giving them the ability to decrypt. Sometimes you just want to let a contractor encrypt a new value, but you don't want them to know the rest of the secrets.
Conceptual - it takes more mental energy to understand the .env.vault format. Encrypted values inside a .env file is easier to quickly grasp.
Combining Multiple Files - there was simply no mechanism to do this well with the .env.vault file format.
That said, the .env.vault tooling will still stick around for at least 1 year under dotenvx vault parent command. I'm still using it in projects as are many thousands of other people.
How do I migrate my .env.vault file(s) to encrypted .env files?
Run $ dotenvx ext vault migrate and follow the instructions.
ย
Contributing
You can fork this repo and create pull requests or if you have questions or feedback:
zoxide is a smarter cd command, inspired by z and autojump. It remembers which directories you use most frequently, so you can "jump" to them in just a few keystrokes. zoxide works on all major shells.
zoxide is a smarter cd command, inspired by z and autojump. It remembers which directories you use most frequently, so you can "jump" to them in just a few keystrokes. zoxide works on all major shells.
yq is a lightweight and portable command-line YAML, JSON and XML processor.
yq uses jq like syntax but works with yaml files as well as json, xml, properties, csv and tsv.
yq is a lightweight and portable command-line YAML, JSON and XML processor.
yq uses jq like syntax but works with yaml files as well as json, xml, properties, csv and tsv.
AI Shell is a CLI tool that brings the power of artificial intelligence directly to your command line! Designed to help you get command assistance from various AI assistants, AI Shell is a versatile tool to help you become more productive in the command line. We call these various AI assistant providers agents. You can use agents to interact with different generative AI models or other AI/ML/assistant providers in a conversational manner.
AI Shell is a CLI tool that brings the power of artificial intelligence directly to your command line! Designed to help you get command assistance from various AI assistants, AI Shell is a versatile tool to help you become more productive in the command line. We call these various AI assistant providers agents. You can use agents to interact with different generative AI models or other AI/ML/assistant providers in a conversational manner.
AI Shell is a CLI tool that brings the power of artificial intelligence directly to your command line! Designed to help you get command assistance from various AI assistants, AI Shell is a versatile tool to help you become more productive in the command line. We call these various AI assistant providers agents. You can use agents to interact with different generative AI models or other AI/ML/assistant providers in a conversational manner.