Level 63
Why do you need to encrypt the .env file ? By default it is inaccessible.
Apr 17, 2025
5
Level 1
Best practice for deploying encrypted .env files to Vapor via GitHub Actions?
Hi everyone,
I have been using Vapor for years now with an encrypted environment file .env.production.encrypted. This has worked great when deploying from local, but I'm currently putting together a CI/CD pipeline through GitHub Actions, and I'm unsure of the best practice to deploy the encrypted .env file.
Up until now I have never committed the .env.production.encrypted to source control, and had written a local deploy script to encrypt my .env.production, update the LARAVEL_ENV_ENCRYPTION_KEY in Vapor's env, then run vapor deploy production. However the only way I can really think of doing this through CI/CD is to encrypt the file locally, then commit the encrypted .env to source control. The repo is private and only myself and one other developer has access to it.
Is this bad practice? How does everyone else do this? Any thoughts?
Thanks!
Level 80
@evan-55 Please use actual environment variables: https://docs.vapor.build/projects/environments#environment-variables
1 like
Level 1
@martinbean what do you mean actual environment variables? I've used up the 2000 character limit in the Vapor dashboard, so I'm unable to add more variables through this method, and therefore have had to resort to an encrypted file on top of the dashboard's .env file.
Due to AWS Lambda limitations, your environment variables may only be 4kb in total. To accommodate Vapor’s own injection of environment variables, users are limited to 2,000 characters of environment variables. You should use encrypted environment files in place of or in addition to environment variables if you exceed this limit.
Level 80
@evan-55 If that’s the case, then you can commit the encrypted .env file to your repository. Just so long as you don’t also encrypt the actual decryption key as well. If someone does get access to your repository, then they just have the encrypted file’s contents and can’t read the original contents.
You’ll then need to set your encryption key as a secret in your repository (https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository). Your GitHub Actions workflow can then use the key to decrypt the encryption .env file just like you would when deploying or whatever.
Level 1
@martinbean makes sense, thanks very much!
1 like
Please or to participate in this conversation.