Body: <p>Ok, to start off, I am web developper that happens to have to do devOps, so I am currently reading on the subject to get better at this stuff.</p>
  <p>I was reading the <a href="https://www.12factor.net/build-release-run" rel="nofollow noreferrer">V. Build, release, run</a>, and the release part didn't really make sense to me.</p>
  <p>On 12factor.net they say: &quot;The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment&quot;.</p>
  <p>Their definition of config is basically every environment variables. Does that mean that every secret (database connection, redis credentials, any other api keys) must be put into the release? So every environment will have a release for it (prod, staging, etc)?</p>
  <p>That would not make sense as to what I know, because I thought that a release was a build that was hand-picked and was tested and greenlit for a potential deployment (Eg: Releases are deployed, not builds). My understanding was that a release was agnostic of a deployment environment, which the 12factor app seems to say otherwise.</p>
  <p>If I take for example ElasticSearch. I have deployed this app in different environments. When I download the version 8.8.0 of ElasticSearch, my understanding is that this is a release? The release 8.8.0 of ElasticSearch. There are no dev/production ElasticSearch that I can download, it's just 8.8.0. The distinction of dev vs prod, it's all managed with flags and configurations that lie on the end server.</p>
  <p>Also if I look at how Kubernetes work (I have never deployed a live app with Kubernetes), they have some kind of service to manage secrets. IIRC, pods launch a release (usually a tagged version of a docker container) and gets configured through docker's environ variables pulled from the secret management service from Kubernetes and the secrets are not part of the container itself. (I might be off here, because I don't have lots of experience with Kubernetes, but you can get my point).</p>
  <p>All this text and yet no formal question!</p>
  <p>Should my secrets be part of my release or not?
  Why would I put my secrets in my release and how to manage it if I should do it?</p>
  
Comments: CC BY-SA 4.0
Comments: 2023-06-16T05:09:13.780Z
Comments: Hi! There is an actual question at the end -- could you update the title of the question with the actual question? Thanks!
Comments: Bruce Becker
Comments: CC BY-SA 4.0
Comments: 2023-06-21T19:07:29.927Z
Comments: No, use secret manager. Ideally make your application "secrets aware" so you don't need to inject secrets through environmental variables. Good luck.
Comments: Kyslik
Tags: <deployment><release-management><release>
Title: Should my secrets be part of my release or not? Trying to understand "V. Build, release, run" from the twelve-factor app
UserDisplayName: Lunfel
ThreadText: # Should my secrets be part of my release or not? Trying to understand "V. Build, release, run" from the twelve-factor app
  
  (Asked by: username_0 on 2023-06-15)
  
  Ok, to start off, I am web developper that happens to have to do devOps, so I am currently reading on the subject to get better at this stuff.
  
  I was reading the [V. Build, release, run](https://www.12factor.net/build-release-run), and the release part didn't really make sense to me.
  
  On 12factor.net they say: "The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment".
  
  Their definition of config is basically every environment variables. Does that mean that every secret (database connection, redis credentials, any other api keys) must be put into the release? So every environment will have a release for it (prod, staging, etc)?
  
  That would not make sense as to what I know, because I thought that a release was a build that was hand-picked and was tested and greenlit for a potential deployment (Eg: Releases are deployed, not builds). My understanding was that a release was agnostic of a deployment environment, which the 12factor app seems to say otherwise.
  
  If I take for example ElasticSearch. I have deployed this app in different environments. When I download the version 8.8.0 of ElasticSearch, my understanding is that this is a release? The release 8.8.0 of ElasticSearch. There are no dev/production ElasticSearch that I can download, it's just 8.8.0. The distinction of dev vs prod, it's all managed with flags and configurations that lie on the end server.
  
  Also if I look at how Kubernetes work (I have never deployed a live app with Kubernetes), they have some kind of service to manage secrets. IIRC, pods launch a release (usually a tagged version of a docker container) and gets configured through docker's environ variables pulled from the secret management service from Kubernetes and the secrets are not part of the container itself. (I might be off here, because I don't have lots of experience with Kubernetes, but you can get my point).
  
  All this text and yet no formal question!
  
  Should my secrets be part of my release or not?
  Why would I put my secrets in my release and how to manage it if I should do it?
  
  **Tags:** deployment, release-management, release
  
  > **Comments:**
  > **username_1**: Hi! There is an actual question at the end -- could you update the title of the question with the actual question? Thanks!  
  > **username_2**: No, use secret manager. Ideally make your application "secrets aware" so you don't need to inject secrets through environmental variables. Good luck.  
  
  ---
  
  ## 0 answers
  
  