Download the PHP package phattarachai/laravel-env-secrets without Composer
On this page you can find all versions of the php package phattarachai/laravel-env-secrets. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download phattarachai/laravel-env-secrets
More information about phattarachai/laravel-env-secrets
Files in phattarachai/laravel-env-secrets
Package laravel-env-secrets
Short Description Encrypt .env.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package laravel-env-secrets
Laravel Env Secrets
One artisan command — secrets:provision — to run the encrypted-.env deploy pattern end to end:
mint an encryption key, encrypt .env.<env> with Laravel's own env:encrypt, and install the key on
your deploy box over ssh. The key is generated with a CSPRNG and never touches stdout, your shell
history, or a process argument — it reaches the server over ssh stdin and your clipboard via pbcopy.
Why
Committing a plaintext .env.production puts every credential your app has into git history forever.
The alternative most teams reach for — a secrets manager, Vault, SSM — is a whole moving part to run.
Laravel ships a middle ground: env:encrypt / env:decrypt.
You commit an encrypted .env.<env>.encrypted, keep the single decryption key off git, and decrypt
at deploy time. The secrets live in the repo (safe — they are ciphertext), and the only thing you have
to distribute out-of-band is one short key per environment.
The fiddly part is the key lifecycle: generating it safely, encrypting with that key (not a fresh one
env:encrypt prints to your terminal and scrollback), and getting it onto the box without it leaking
through a command argument or ps. secrets:provision does exactly that and nothing else.
How the pattern works
- You hold the plaintext
.env.uat/.env.productionlocally (git-ignored — see below). These are the editable source of truth. secrets:provision <env>mints a 32-hex-char key, runsenv:encrypt --key=… --env=<env>, and produces.env.<env>.encrypted. You commit that file.- The same key is installed on the deploy box at
<dir>/<slug>.<env>.key(mode600, owned by the ssh user) and copied to your clipboard to paste into your password manager as a backup. - Your deploy script exports the key from that file and runs
env:decryptto regenerate.envon the box before the app boots.
The key is the only secret that ever leaves your machine, and it only ever moves over ssh stdin.
Install
It is a dev-time provisioning tool — you run it from a developer machine, so --dev is the right place
for it. The package auto-registers its service provider.
Publish the config to set your defaults:
Every value is overridable per run with --host, --dir, --slug. When an option is omitted the command
uses the config value; when the config slug is null it derives one from config('app.name') (falling
back to the application directory name).
Two infra snippets you add yourself
The package encrypts and distributes the key. The two ends of the pattern live in your repo and your deploy pipeline — add them once.
1. Git-ignore the plaintext env files so only the .encrypted versions are ever committed. In .gitignore:
(.env.<env>.encrypted is not ignored — that is the whole point; it gets committed.)
2. Decrypt at deploy. Before copying the decrypted file into place, export the key from the box and run
env:decrypt. In your deploy step (adjust <dir>, <slug>, <env>):
env:decrypt reads the key from LARAVEL_ENV_ENCRYPTION_KEY, decrypts .env.<env>.encrypted back to
.env.<env>, and you copy that to the active .env.
Usage
Provision UAT — encrypt .env.uat, install the key on the configured host, copy it to your clipboard:
Production, overriding the host and key location for this run:
Encrypt only, without touching any server (e.g. rotating the committed ciphertext locally):
After a successful run: commit the updated .env.<env>.encrypted, and confirm the key landed in your
password manager (it is already on your clipboard).
Options
| Option | Default | Purpose |
|---|---|---|
env |
(required) | Environment to encrypt, e.g. uat, production. |
--host |
config('env-secrets.host') |
ssh host alias of the box that stores the key. |
--dir |
config('env-secrets.dir') |
Directory on the box that holds the key files. |
--slug |
config, else app name | Filename stem — key is <slug>.<env>.key. |
--local |
off | Encrypt locally only; skip installing on the box. |
Security notes
- The key is minted with
random_bytes(CSPRNG) and passed toenv:encryptvia--key, soenv:encryptnever generates or prints its own key. - The key is streamed to the server over ssh stdin and to the clipboard over pbcopy stdin — never
as a shell argument, so it stays out of
ps, shell history, and CI logs. - On the box the key file is created
600, owned by the connecting ssh user, in a700directory. env,slug, anddirare validated ([a-z0-9-]/ absolute path) before any process runs.
Testing
Credits
License
The MIT License (MIT). See LICENSE.md.
All versions of laravel-env-secrets with dependencies
spatie/laravel-package-tools Version ^1.16
illuminate/console Version ^12.0|^13.0
illuminate/contracts Version ^12.0|^13.0
illuminate/support Version ^12.0|^13.0