Environment Variables and Secrets, the Right Way
Lesson 7 of 10: neo env set for quick changes, .neo.yml for defaults, and where real secrets belong instead of a committed .env.
Day-to-day commands
neo env my-app
lists the app's environment variables, with anything that looks like a secret masked in the output.
neo env set my-app LOG_LEVEL=debug
sets one and restarts the container so it takes effect — no separate redeploy needed for an env-only change.
neo env import my-app .env
bulk-imports an entire file at once, useful the first time you're bringing a project's existing .env under Neo's management.
Where defaults live
Non-sensitive values belong in .neo.yml, committed like everything else:
env:
APP_ENV: production
LOG_LEVEL: info
Where secrets don't belong
A plaintext .env with real credentials in it, committed to the repo, is the thing to avoid — it's the most common way a database password ends up in git history forever. If your project needs to ship secrets in the repo (so a fresh clone or CI has what it needs without a separate secrets-manager step), Neo supports encrypted env files: a committed .env.encrypted in Laravel's env:encrypt format, decrypted only in memory at deploy time.
That's a big enough topic to deserve its own lesson rather than a rushed paragraph here — see How to Commit Secrets Safely with Encrypted Environment Files for the full walkthrough, including how the decryption key itself is kept out of the repo. For now: neo env set for quick changes, env: in .neo.yml for defaults that aren't secret, and encrypted files for the ones that are.
Try it yourself — Neo is free, with every feature unlocked.
Get started free