eduardoaraujo01/nova-env
A Laravel Nova tool for managing environment variables directly from the admin panel. View, edit, and organize .env entries without server access, making configuration changes simpler and safer for authorized Nova users.
This is a Nova tool from a very young package (v0.1.x, no dependents at time of writing), so treat it as a starting point you validate yourself rather than a battle-tested dependency.
composer require eduardoaraujo01/nova-env
app/Nova/NovaServiceProvider.php (or app/Providers/NovaServiceProvider.php in older layouts):
public function tools()
{
return [
new \EduardoAraujo01\NovaEnv\NovaEnv(),
];
}
src/ for the tool class, any service provider (NovaEnvServiceProvider), config file, and resources/js Vue components. Confirm:
php artisan vendor:publish --tag=nova-env-config or similar)?.env from — base_path('.env') or a configurable path?php artisan nova:publish and npm run dev/npm run prod in vendor/eduardoaraujo01/nova-env as the README dictates.Because the package is at 0.1.0 with zero dependents, read the source before deploying it to any environment where .env contains real secrets.
Gate edits behind a Nova policy or gate. Nova tools can be hidden per-user. Wrap visibility and ability with a Nova gate so only a trusted admin role sees the tool:
// AuthServiceProvider
Gate::define('editEnv', fn ($user) => $user->hasRole('super-admin'));
Then guard the tool registration and, more importantly, guard whatever controller or Nova action actually writes the file. Nova's sidebar hide is cosmetic — authorization must be enforced server-side.
Use it as a controlled toggle panel, not a general editor. The safe pattern is: define an allowlist of keys your tool is permitted to change (APP_TIMEZONE, MAIL_MAILER, QUEUE_CONNECTION), render those, and reject writes to anything else in the backend. If the package ships a freeform editor, wrap or fork it to filter allowedKeys from config before persisting.
Pair every write with a config cache clear. After php artisan config:cache is run in production, editing .env has no effect until the cache is rebuilt. Standard pattern:
Artisan::call('config:clear');
// or re-cache on the way out
Artisan::call('config:cache');
If the package doesn't do this automatically, hook it in your own wrapper controller or an event listener.
Back up before writes. Snapshot the current .env to storage/app/env-backups/.env.YmdHis before applying changes. It's the difference between a recoverable mistake and a 3 a.m. incident. Keep the last N backups and prune.
Scope per environment. Only register the tool when it makes sense:
public function tools()
{
return app()->environment(['local', 'staging'])
? [new NovaEnv()]
: [];
}
Production editing via a web UI is a deliberate risk decision — if you enable it, layer on a confirm step, audit log, and a second gate.
Integration tip: combine with Nova's action events to record who changed what. Listen for whatever event the tool fires (or wrap its write method) and store {user_id, key, changed_at} in an env_audit_logs table. This is the piece most env editors omit and the piece auditors ask for.
Atomic writes. If the tool uses file_put_contents, verify or wrap the write with LOCK_EX and a temp-file-plus-rename pattern:
file_put_contents($tmp, $contents);
rename($tmp, base_path('.env'));
A torn write during a deploy is a very bad day.
www-data (or similar). The .env file is typically 0640 owned by the deploy user. Granting the web user write access means loosening permissions — consider ownership adjustment or a privileged helper script rather than chmod 666.#, =, $, or " must be quoted correctly. A naive "split on first =" parser will corrupt values like PASSWORD="a#b=c". Test round-trips with hostile values before going live.\r\n in a file edited on Linux, or a stray trailing space, will silently break variables. Diff the file after editing (git diff locally, diff on the server) until you trust the writer..env holds DB passwords, API keys, APP_KEY. If the tool renders all variables, you're displaying secrets to anyone with the URL. Mask values by default (****) with an explicit reveal, and consider excluding keys matching *_KEY, *_SECRET, *_PASSWORD entirely..env. Changes are untracked and unreviewable. That's why backups and audit logging are non-negotiable..env on one web node does nothing for the other nodes or for immutable containers. If you run more than one server or any containerized workloads, this tool is inappropriate — use a secrets manager (Vault, AWS SSM, Doppler) or a proper config service instead..env on deploy, silently discarding UI edits. Document this loudly, or move runtime config to a DB-backed settings table rather than .env.composer.json, vendor a fork if you need fixes, and read the write path line by line. Also check that it declares support for your Nova version — Nova tools frequently break across major Nova releases due to Vue and mixin API changes..env path, an allowlist of editable keys, a policy/gate hook, and events on save. If none exist, add them via a thin wrapper class rather than patching vendor/.nova:publish) or a Vue mixin version mismatch with your Nova major version. Check the browser console first, then php artisan nova:publish.How can I help you explore Laravel packages today?