Job secrets-env-file-to-secret-store-with-rotation-checklist · revised 11 October 2026
Move one app's secrets out of its env file into your platform's secret store
One app stops reading secrets from a plain env file and reads them from its platform's secret mechanism. It is tested starting from the new source, and you get a rotation checklist and keep every key.
You might be seeing
- Secrets sit in a plain file next to the code on the server
- Printing the container or process configuration shows secret values
- Nobody has a list of which secrets exist or who last changed them
No passwords, keys, card details or admin invites needed to start.
What usually happened
An env file is easy to copy, easy to print and easy to forget. Docker warns that secrets passed as environment variables can be visible to every process and appear in logs when debugging. The platform's own mechanisms read secrets from files with permissions instead. Kubernetes stores Secrets unencrypted by default unless encryption at rest is configured, and base64 is not protection. Moving the values is the easy part; the rest is app configuration that reads the new location and a rotation order that does not break the app.
Who it’s for: A founder or developer whose app on a server or cluster gets its API keys and database passwords from a .env file or from environment variables written into a Compose file or unit.
Usually starts when: An env file was copied to a laptop, shared in a chat, baked into an image or read by a contractor, and the team wants secrets handled properly before it grows.
The result: One app on one platform (Docker Compose, systemd or Kubernetes) starts and passes its health check reading each named secret from the platform's secret mechanism. The env file no longer holds those values, the effective configuration shows no secret value, and you receive a rotation checklist that you run with keys that you generate and hold.
Check whether this job fits
Four checks that decide whether this fixed job fits. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
List the names without the values
On the machine that holds the env file, print only the names of the variables. It first removes any Windows line endings, then prints a line only when it starts with a name and an equals sign followed by a value, and prints just the name, so comments, blank lines and the inside of a multi-line key or credential are not printed. Names with an empty value are not listed. Never paste the values anywhere.
tr -d '\r' < .env | sed -nE 's/^[[:space:]]*(export[[:space:]]+)?([A-Za-z_][A-Za-z0-9_]*)=[^=].*/\2/p'Look for: A list of names only. If any line looks like part of a value, stop and do not send it. Then pick out the names that are secrets, such as passwords, tokens and keys, and those that are plain settings. Send the secret names only.
Check the systemd version
Only needed if the app runs as a systemd service. It prints the version and changes nothing.
systemctl --version | head -n 1Look for: A version number of 247 or higher.
What you get
- The changed configuration with no secret values, and a table of secret name, where it is now read and who may read it
- The rotation checklist: how to generate a new value, where to place it, how to restart the app and how to revoke the old one, with a shorter-overlap path for a key you know is exposed
- The startup test output and the search result showing no value in the delivered files
Included
- One app and up to ten secrets, on one platform: Compose secrets, systemd credentials or a Kubernetes Secret
- The change to how the app reads each secret: a file path or a variable that points to a file, supported by the app or the image
- Removal of the values from the env file, the Compose file or unit, and the image build context, and a search for them in what we deliver
- A rotation checklist with the order that avoids downtime, and a before and after startup test
Not included
- Removing a secret from a Git repository's history, or deciding which exposed keys must be revoked: that is the committed-secret job
- Generating, holding or rotating your keys: you do that with the checklist
- Setting up a hosted secrets service, a key-management product or a vault server
- Changing application code beyond reading a secret from a file or from a variable that points to one
- Encryption at rest for a Kubernetes cluster, which the cluster administrator controls
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
With throwaway values placed in the new secret locations, the app starts and its health check passes, and with a location emptied the app fails its health check.
Evidence: The startup and health-check output with the values present, and the failure with one removed.
A search of the delivered configuration, the env file template and the image build context finds none of the throwaway values (run by the reviewer on the delivered files), and none of your real values (run by you on your own machine, because we never receive them).
Evidence: The reviewer's command and its empty result for the throwaway values, your own confirmation for the real ones, and the same command run on the old env file, which must list it. The command prints only the names of files that contain a value, never the matching lines.
grep -v '^$' values.txt | grep -rlF -f - delivered/The effective configuration printed by the platform shows secret names or file paths and no secret values.
Evidence: The redacted output of the configuration listing for the app.
The secret files are readable only by the app's user or service, and a different user or service on the same host cannot read them.
Evidence: File permission listing and a denied read attempt as another user.
The rotation checklist covers every named secret with its consumers, the new-value step, the restart step, a verification step and a revocation step, and has a shorter-overlap path for a key known to be exposed.
Evidence: The completed checklist table with one row per secret.
Sign-off. You sign off after the startup tests, the value search and the permission check pass in your test environment and you have the checklist. Payment follows sign-off.
If it fails. If the app cannot read a secret from the new source within the scope, we say which setting blocks it and what change would be needed, you do not pay for that part, and the original configuration stays as it was.
When it fits, and when we stop
It fits when
- The app or image can read each secret from a file, or from a variable that names a file
- On systemd, the version is 247 or later, which we confirm at intake; an older version is quoted separately
- You can generate new values for every secret in scope, even if you rotate later
- You control the platform configuration and can restart the app in an agreed window
- A person on your side can say which secrets are real and which are placeholders
We stop and tell you if
- The app can read a secret only from a plain environment variable and its code cannot be changed or wrapped
- You cannot restart the app to test it
- A secret is shared with another system that nobody can identify, so rotation would break something unknown
- The task is mainly to clean a repository's history, not to change how the app reads secrets
- The app runs under a systemd older than version 247 and the quote has not been agreed for another route
What could go wrong
The previous env file configuration is kept in the handover. Restoring it and restarting the app returns it to reading the env file. Rotation is a separate step run by you: for a planned rotation the checklist keeps the old value valid until the new one is confirmed working, then revokes it; for a key known to be exposed it shortens that overlap and revokes the old value as soon as the new one is confirmed.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The app starts but reads an empty value because the file path is wrong. | The startup test uses throwaway values that the app must use to pass its health check; an empty value fails it. |
| A secret mounted for one service becomes readable by another service or user. | Grant access per service, set file permissions, and have the reviewer check who can read each file. |
| Rotating a shared key breaks another system that uses it. | The checklist starts with finding every consumer of each key, and keeps the old value valid until the new one is confirmed. |
An independent reviewer checks that no secret value appears in the delivered files, that the secret files are readable only by the app's user, and that the rotation order cannot take the app offline.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the app, the platform, the list of secret names and the rotation owner in writing
- Find how the app and image read each setting and choose the file-based route that fits
- Change the configuration so each secret is delivered as a file with restricted permissions, using throwaway values
- Remove the values from the env file, the Compose file or unit and the build context, and search the deliverables for any value
- Independent review of file permissions, who can read the secrets, and anything that could print them
- Hand over the change and the rotation checklist; you apply them and rotate with your own keys
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
This job changes where the app reads secrets and hands over the rotation checklist, which you run with keys that you generate and hold. It does not include rotation reminders or ongoing checks.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Docker documents Compose secrets, including the file mounted at /run/secrets and the *_FILE variables official images accept. docs.docker.com
- systemd documents service credentials as an alternative to environment variables for a service on a Linux host. systemd.io
Questions
Do you need my real keys?
No. We work with throwaway values that you create for the test. You place the real ones and rotate them with the checklist.
Is a platform secret store the same as a vault?
No. It keeps secrets out of a plain file and limits who can read them. It is not a key-management service, and the handover says what it does not protect against.
What if a key has already leaked?
Rotate it first. That is outside this job, and a committed key also needs its history addressed by the committed-secret job. The checklist includes a shorter-overlap path for a key you know is exposed.
Will the app have downtime?
A restart is needed. The rotation order is chosen so the old value stays valid until the new one is confirmed.
Send an enquiry
Send us
- The names of the secrets (not the values), what each is used for and the platform
- How the app reads them today and whether it supports reading from a file
- Whether any of them has ever been shared outside the team
- Do not send the env file, any secret value or a server login in the first enquiry
Later, once you agree
- A copy of the configuration with values replaced by placeholders, and a test environment with throwaway secret values you create
- Who will rotate each real secret, and when
- An administrator on your side to apply the change and restart the app
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the app, the platform and every secret value. We only ever work with placeholder values that you create for the test, never with your real keys. You apply the change and rotate the real secrets with the checklist. Where an agreed live step is needed, you run it or open a time-limited account that you revoke afterwards, agreed in writing.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “secrets-env-file-to-secret-store-with-rotation-checklist” as the subject.