A .env file feels convenient until it is copied into a repository, an image, a support archive, or a chat while someone diagnoses a deployment. The hard part is not memorizing a storage product. It is deciding which process needs each value, how it receives it, and how you replace it without turning a routine release into downtime.
The myth to retire is that moving a password out of source code makes it safe by definition. It only moves the question. Where does the value live now, who can read it, and which logs, backups or automation steps can reproduce it? Those are the questions that make a VPS deployment reviewable.
Myth: an environment variable cannot leak
Configuration is not automatically confidential
A secret is a value whose disclosure changes a security boundary: database passwords, signing keys, API tokens, webhook credentials and recovery codes are common examples. A value is not harmless merely because it appears in a configuration file. If it authorizes a production action, assume it will eventually be copied, backed up, logged or viewed by someone who did not need it.
The Twelve-Factor App guidance separates configuration from code, which is a useful starting principle for VPS deployments. It does not mean environment variables are magically safe. They can appear in process inspection, debug output, shell history, service definitions, crash reports, or an overly broad administrative account.
A repository is designed to preserve and distribute history. Deleting a committed .env file in a later commit does not erase copies already cloned, mirrored or cached. When a real credential enters version control, treat it as exposed: rotate it, investigate where it was used, and prevent the same path from being repeated.
If a production credential was committed to a repository, do not rely on a follow-up deletion. Rotate or revoke it first, because existing clones, forks, CI logs and backups may retain the earlier value.
Give each secret a controlled path
Delivery and permissions
Choose a delivery mechanism that matches the deployment model. A systemd credential or protected environment file may be reasonable for one service on one VPS. A dedicated secret manager can offer audit and rotation benefits for several services, but it also creates a service to operate. Complexity is not automatically maturity.
Store configuration and secret material separately even when both are deployed together. Non-sensitive settings can be reviewed in source control, while the secret reference or encrypted delivery step has tighter permissions. That division lets a reviewer understand how the service behaves without being given the ability to impersonate it.
File permissions matter but are not the entire answer. A root-readable file is still available to every process or administrator that gains root. Use a dedicated service account, limit directory traversal, avoid world-readable defaults, and make backup operators aware that secret files are sensitive data too.
Avoid sending secret values through command-line arguments. Process lists and monitoring tools may capture them. Likewise, redact values from deployment output and application error logs. A debugging habit that prints the complete environment can quietly turn a local incident into a long-lived data exposure.
- Inventory every credential by service, purpose, owner and environment.
- Keep secret values out of repository files and place only references or documented delivery steps in code review.
- Choose a delivery mechanism appropriate to the VPS and restrict its reader account.
- Deploy without echoing values in command lines, CI output or application diagnostics.
- Test a rotation and rollback path before the credential is urgently needed.
Rotation is a product requirement
Rotation needs a design before an incident. For a database credential, determine whether two credentials can coexist briefly; for a third-party token, determine the revoke-and-replace sequence; for an application signing key, determine the effect on existing sessions. ‘Change it later’ is not a rotation plan.
Use distinct secrets for development, staging and production. A staging compromise should not grant production access, and a developer laptop should not need the same token as an unattended production process. Environment separation also makes it safer to test a deployment rollback without touching customer-facing credentials.
Audit the path from source repository to running process. Ask who can read the CI variables, who can view deployment logs, which account owns the final file, and how an old VPS image is handled. A secret-management choice is credible only when the complete path has fewer trusted readers than the secret itself requires.
Location or mechanism | Useful property | Risk to manage |
Repository | Reviewable configuration | History distributes secrets widely |
Protected service file | Simple for one VPS | Permissions and backup scope matter |
CI secret store | Separates value from code | Log access and runner trust matter |
Secret manager | Central audit/rotation options | Adds availability and operational dependency |
Author's principle: a secret is managed only when its readers, delivery path, rotation owner and revocation step are all known.
Treat secret names as potentially sensitive context too. A variable called production-payment-master-key reveals more than a neutral deployment reference, even when its value is hidden. This does not require obscurity; it requires deciding what needs to appear in logs, tickets and monitoring labels.
Encryption at rest is useful when it is paired with sound key ownership. An encrypted file that is automatically decrypted by every broadly privileged account has not meaningfully reduced the reader set. Map who can obtain the decryption material and how that access is revoked during staff or system changes.
For container deployments, check the runtime path rather than trusting the compose file alone. A secret may enter through an environment, a mounted file, an orchestration object or a CI command. The running process, its service account and its diagnostics are the places that determine actual exposure.
A simple incident response record should say how to revoke each important token and where dependent configuration is updated. This makes a suspected leak actionable: rotate, redeploy, verify the new credential, then invalidate the previous one. It also reduces the temptation to postpone remediation because the path is unclear.
The durable outcome is not a particular product name but a repeatable rule: code can be reviewed freely, while credentials travel through a narrower, auditable route and can be changed without rewriting the application.
Conclusion
Start with an inventory and remove secrets from the paths designed to copy code. Then choose the smallest controlled mechanism your project can operate consistently; for infrastructure planning, review the relevant DeltaHost options at DeltaHost infrastructure options for a controlled deployment.