ShippedSecrets
Your app needs credentials. Your repository does not. Give each service the protected configuration it needs to run.
Store values separately from source
Add database passwords, API tokens, and other sensitive values through secret configuration instead of hard-coding them in the application. Reference the configuration where the service needs it. Direct source shipping excludes common secret-bearing local files by default, but you should still review the uploaded files and avoid committing credentials into source history.
Use the right values in each environment
Keep staging and production credentials separate, and give each service only the access it requires. A test worker should not send mail through production credentials simply because it shares application code. Bind secrets to the appropriate service and environment so changing a deployment target does not silently carry every live integration along with it.
Rotate credentials as an application change
When a provider token or database credential changes, update the protected value and make sure the application picks it up through the appropriate deployment or restart. Check dependent services before revoking the previous credential. Keep sensitive values out of logs and agent conversations, where they can be copied beyond the service that needs them.
A little more detail
Questions about Secrets?
Can frontend environment variables hold private API keys?
No. Values compiled into browser code are visible to visitors even when they began as environment variables. Keep private credentials in a backend service and expose only the application operations the frontend is allowed to request.
Does excluding environment files catch every secret?
No. Credentials can appear in arbitrary source, fixtures, or generated files. Review the source you ship and rotate any credential that has been exposed; exclusion rules are not a substitute for that review.
From your workspace to the web