I'm currently using Pre Deploy to trigger infisical to generate my .env file.
Splitting that concern out into infisical means i can keep .env out of the git repo and keep the secrets secret.
But because i've mentioned a env_file in the docker compose komodo wants to perform it's pull including that .env which doesn't exist yet.
I can get around that just by committing an empty .env for now. But it feels like there might be a more elegant solution.
Moving those infisical commands to a Pre Pull could work, just not sure how value that would be to others
I'm preferring to use the Reclone option to ensure that stack is exactly in sync with the repo, but disabling that and manually creating an .env would also be an option
Originally created by @cam-yates on GitHub (Feb 20, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/324
I'm currently using Pre Deploy to trigger [infisical](https://infisical.com/) to generate my .env file.
Splitting that concern out into infisical means i can keep .env out of the git repo and keep the secrets secret.
But because i've mentioned a env_file in the docker compose komodo wants to perform it's pull including that .env which doesn't exist yet.
I can get around that just by committing an empty .env for now. But it feels like there might be a more elegant solution.
Moving those infisical commands to a Pre Pull could work, just not sure how value that would be to others
I'm preferring to use the Reclone option to ensure that stack is exactly in sync with the repo, but disabling that and manually creating an .env would also be an option
Would love to see a way to integrate infiscial into the deployment process.
<!-- gh-comment-id:2867216098 -->
@ravensorb commented on GitHub (May 9, 2025):
Would love to see a way to integrate infiscial into the deployment process.
@cam-yates Having the pre-deploy run before the pull would be ideal in case we need a secret as part of the pull, and just for ease of not janking the script to make the .env permanently exist even as a blank as you've experienced.
In the interim, I'm populating secrets with pre-deploy, shredding it and touching a blank .env on post-deploy to set up for the next run.
<!-- gh-comment-id:2941363827 -->
@undaunt commented on GitHub (Jun 4, 2025):
@cam-yates Having the pre-deploy run before the pull would be ideal in case we need a secret as part of the pull, and just for ease of not janking the script to make the .env permanently exist even as a blank as you've experienced.
In the interim, I'm populating secrets with pre-deploy, shredding it and touching a blank .env on post-deploy to set up for the next run.
Pre-deploy
```
#!/usr/bin/env bash
set -eu pipefail
STACK_NAME="$(basename "$PWD")"
CLIENT_ID="[[INFISICAL_MI_ID_PROD]]"
CLIENT_SECRET="[[INFISICAL_MI_SECRET_PROD]]"
DOMAIN="[[INFISICAL_LOCAL_URL]]"
PROJECT_ID="[[INFISICAL_PROJECT_ID]]"
ENV="prod"
INFISICAL_TOKEN=$(docker exec infisical \
infisical login \
--method=universal-auth \
--client-id="$CLIENT_ID" \
--client-secret="$CLIENT_SECRET" \
--domain="$DOMAIN" \
--silent --plain)
docker exec infisical \
infisical export \
--format=dotenv \
--domain="$DOMAIN" \
--token="$INFISICAL_TOKEN" \
--projectId="$PROJECT_ID" \
--env="$ENV" \
--path="/$STACK_NAME" \
> secrets.env
chmod 600 secrets.env
echo "→ secrets.env created"
```
It's currently coded to use the name of the stack as the folder path in Infisical.
Post-deploy
```
set -eu; \
if [ -f secrets.env ]; then \
if command -v shred >/dev/null 2>&1; then \
shred -u secrets.env; \
else \
rm -f secrets.env; \
fi; \
echo "→ secrets.env removed"; \
else \
echo "→ No secrets.env found (nothing to do)"; \
fi; \
touch secrets.env; \
chmod 600 secrets.env; \
echo "→ blank secrets.env recreated (600)"
```
Eg:
Edit: Related https://github.com/moghtech/komodo/issues/467
@adrianipopescu commented on GitHub (Jun 4, 2025):
heh, I do it almost the same way, but it would be great to have an option to configure the actual docker command
i.e.:
pre would be getting the token, in my case I run the agent to maintain it or if it's a scoped execution (aka things get removed from memory/history after the job) set the env var
exec would be infisical exec - docker compose -p "stackname" up -d [other args]
that way you don't have secrets physically on the disk at all
<!-- gh-comment-id:2941622285 -->
@adrianipopescu commented on GitHub (Jun 4, 2025):
heh, I do it almost the same way, but it would be great to have an option to configure the actual docker command
i.e.:
- pre would be getting the token, in my case I run the agent to maintain it or if it's a scoped execution (aka things get removed from memory/history after the job) set the env var
- exec would be infisical exec - docker compose -p "stackname" up -d [other args]
- that way you don't have secrets physically on the disk at all
Rewrote the scripts to have fewer lines because my .toml was getting out of control. Removed shred and the file exists check from the post script. Added a second call to do root and then stack path to handle global variables.
Are you running an agent per stack @adrianipopescu or just one agent?
This also doesn't work for folder variables (I'm trying to completely get rid of my local .env files that aren't committed) since it will break the docker pull, unless I add placeholder fallbacks to them. :|
<!-- gh-comment-id:2941690640 -->
@undaunt commented on GitHub (Jun 4, 2025):
Rewrote the scripts to have fewer lines because my .toml was getting out of control. Removed shred and the file exists check from the post script. Added a second call to do root and then stack path to handle global variables.
```
set -eu pipefail
STACK=$(basename "$PWD"); ID="[[INFISICAL_MI_ID_PROD]]"; SECRET="[[INFISICAL_MI_SECRET_PROD]]"; DOMAIN="[[INFISICAL_LOCAL_URL]]"; PROJECT_ID="[[INFISICAL_PROJECT_ID]]"; ENV="prod"; \
TOKEN=$(docker exec infisical infisical login --method=universal-auth --client-id="$ID" --client-secret="$SECRET" --domain="$DOMAIN" --silent --plain)
docker exec infisical infisical export --domain="$DOMAIN" --token="$TOKEN" --projectId="$PROJECT_ID" --env="$ENV" > secrets.env
docker exec infisical infisical export --domain="$DOMAIN" --token="$TOKEN" --projectId="$PROJECT_ID" --env="$ENV" --path="/$STACK" >> secrets.env
chmod 600 secrets.env; echo "→ secrets.env populated"
```
```
set -eu pipefail
rm -f secrets.env; echo "→ secrets.env removed"; \
touch secrets.env; chmod 600 secrets.env; echo "→ blank secrets.env recreated (600)"
```
Are you running an agent per stack @adrianipopescu or just one agent?
This also doesn't work for folder variables (I'm trying to completely get rid of my local .env files that aren't committed) since it will break the docker pull, unless I add placeholder fallbacks to them. :|
@adrianipopescu commented on GitHub (Jun 4, 2025):
one agent / host, but I cobble my host stacks into a big one using includes, and I have another one per host with common utilities (think traefik, dozzle agent, etc.)
<!-- gh-comment-id:2941834390 -->
@adrianipopescu commented on GitHub (Jun 4, 2025):
one agent / host, but I cobble my host stacks into a big one using includes, and I have another one per host with common utilities (think traefik, dozzle agent, etc.)
I believe I have a PR ready for this, but I'm not a legit developer. It seems to be working on a test stack where I removed the recreate secrets.env portion from the post-deploy and blew away secrets.env placeholder.
<!-- gh-comment-id:2945699309 -->
@undaunt commented on GitHub (Jun 5, 2025):
I believe I have a PR ready for this, but I'm not a legit developer. It seems to be working on a test stack where I removed the recreate secrets.env portion from the post-deploy and blew away secrets.env placeholder.
Edit: https://github.com/moghtech/komodo/pull/584
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @cam-yates on GitHub (Feb 20, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/324
I'm currently using Pre Deploy to trigger infisical to generate my .env file.
Splitting that concern out into infisical means i can keep .env out of the git repo and keep the secrets secret.
But because i've mentioned a env_file in the docker compose komodo wants to perform it's pull including that .env which doesn't exist yet.
I can get around that just by committing an empty .env for now. But it feels like there might be a more elegant solution.
Moving those infisical commands to a Pre Pull could work, just not sure how value that would be to others
I'm preferring to use the Reclone option to ensure that stack is exactly in sync with the repo, but disabling that and manually creating an .env would also be an option
@ravensorb commented on GitHub (May 9, 2025):
Would love to see a way to integrate infiscial into the deployment process.
@undaunt commented on GitHub (Jun 4, 2025):
@cam-yates Having the pre-deploy run before the pull would be ideal in case we need a secret as part of the pull, and just for ease of not janking the script to make the .env permanently exist even as a blank as you've experienced.
In the interim, I'm populating secrets with pre-deploy, shredding it and touching a blank .env on post-deploy to set up for the next run.
Pre-deploy
It's currently coded to use the name of the stack as the folder path in Infisical.
Post-deploy
Eg:
Edit: Related https://github.com/moghtech/komodo/issues/467
@adrianipopescu commented on GitHub (Jun 4, 2025):
heh, I do it almost the same way, but it would be great to have an option to configure the actual docker command
i.e.:
@undaunt commented on GitHub (Jun 4, 2025):
Rewrote the scripts to have fewer lines because my .toml was getting out of control. Removed shred and the file exists check from the post script. Added a second call to do root and then stack path to handle global variables.
Are you running an agent per stack @adrianipopescu or just one agent?
This also doesn't work for folder variables (I'm trying to completely get rid of my local .env files that aren't committed) since it will break the docker pull, unless I add placeholder fallbacks to them. :|
@adrianipopescu commented on GitHub (Jun 4, 2025):
one agent / host, but I cobble my host stacks into a big one using includes, and I have another one per host with common utilities (think traefik, dozzle agent, etc.)
@undaunt commented on GitHub (Jun 5, 2025):
I believe I have a PR ready for this, but I'm not a legit developer. It seems to be working on a test stack where I removed the recreate secrets.env portion from the post-deploy and blew away secrets.env placeholder.
Edit: https://github.com/moghtech/komodo/pull/584