When a secret (or I assume a variable) has $ character within its value, it can get treated as if it is itself a placeholder to be replaced by the variable/secret replacement logic.
Details & Repro:
I try to maintain complex and unique passwords and secrets for each of my services and utilize a password generator to create unique secrets.
I had a secret with the $ in the value of the secret as a complex password with characters & symbols
During the deployment Komodo saw that value and tried to perform a replacement, but there was understandably not a variable or secret with that name (note in fact that the string had somewhere in the middle and Komodo treats everything after the (up until a space I believe) as a variable to replace.
It would appear that perhaps Komodo is making multiple passes at the variable replacement and also seems to perhaps use $ alone as part of the regex / pattern to match to identify a variable or secret to be replaced.
Originally created by @rsocko on GitHub (Nov 4, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/960
When a secret (or I assume a variable) has $ character within its value, it can get treated as if it is itself a placeholder to be replaced by the variable/secret replacement logic.
Details & Repro:
- I try to maintain complex and unique passwords and secrets for each of my services and utilize a password generator to create unique secrets.
- I had a secret with the $ in the value of the secret as a complex password with characters & symbols
- During the deployment Komodo saw that value and tried to perform a replacement, but there was understandably not a variable or secret with that name (note in fact that the string had $ somewhere in the middle and Komodo treats everything after the $ (up until a space I believe) as a variable to replace.
It would appear that perhaps Komodo is making multiple passes at the variable replacement and also seems to perhaps use $ alone as part of the regex / pattern to match to identify a variable or secret to be replaced.
This feels similar in nature to: https://github.com/moghtech/komodo/issues/644#issuecomment-3483271570 whereby a secret value that matches the service name is being treated oddly.
Komodo only does ${VAR} stype interpolation for its own config files core.config.toml and periphery.config.toml, otherwise it only does [[VAR]] style. Can you clarify the situation?
<!-- gh-comment-id:3484383499 -->
@mbecker20 commented on GitHub (Nov 4, 2025):
Komodo only does `${VAR}` stype interpolation for its own config files `core.config.toml` and `periphery.config.toml`, otherwise it only does `[[VAR]]` style. Can you clarify the situation?
I will try a more detailed repro so that I can confirm what I'm seeing.
On quick review - the secret value was just a string with $ in the middle of it - no { } pr characters included.
I am going to recreate the stack with the secret included to pull the logs and be more specific of what I am seeing.
<!-- gh-comment-id:3487229601 -->
@rsocko commented on GitHub (Nov 4, 2025):
I will try a more detailed repro so that I can confirm what I'm seeing.
On quick review - the secret value was just a string with $ in the middle of it - no { } pr [[ ]] characters included.
I am going to recreate the stack with the secret included to pull the logs and be more specific of what I am seeing.
If KOMODO_VAR contains signs, things can get tricky. I see in the `.env` generated by Komodo that the value is rendered correctly there. The issue appears when docker compose does its interpolation. One solution is to escape signs by replacing them by $$ in KOMODO_VAR.
Having Komodo automatically escape these characters could be a nice feature!
<!-- gh-comment-id:4106407564 -->
@bastienlc commented on GitHub (Mar 22, 2026):
I had a similar issue but the root cause is [docker compose interpolation](https://docs.docker.com/reference/compose-file/interpolation/).
I'm using Komodo to inject variables in my docker compose services, typically in the stack configuration I have:
```
MY_ENV_VAR=[[KOMODO_VAR]]
```
And in the docker-compose.yml file:
```
services:
my_service:
...
environment:
MY_ENV_VAR: ${MY_ENV_VAR}
```
If `KOMODO_VAR` contains $ signs, things can get tricky. I see in the `.env` generated by Komodo that the value is rendered correctly there. The issue appears when docker compose does its interpolation. One solution is to escape $ signs by replacing them by $$ in `KOMODO_VAR`.
Having Komodo automatically escape these characters could be a nice feature!
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 @rsocko on GitHub (Nov 4, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/960
When a secret (or I assume a variable) has $ character within its value, it can get treated as if it is itself a placeholder to be replaced by the variable/secret replacement logic.
Details & Repro:
somewhere in the middle and Komodo treats everything after the(up until a space I believe) as a variable to replace.It would appear that perhaps Komodo is making multiple passes at the variable replacement and also seems to perhaps use $ alone as part of the regex / pattern to match to identify a variable or secret to be replaced.
This feels similar in nature to: https://github.com/moghtech/komodo/issues/644#issuecomment-3483271570 whereby a secret value that matches the service name is being treated oddly.
@mbecker20 commented on GitHub (Nov 4, 2025):
Komodo only does
${VAR}stype interpolation for its own config filescore.config.tomlandperiphery.config.toml, otherwise it only does[[VAR]]style. Can you clarify the situation?@rsocko commented on GitHub (Nov 4, 2025):
I will try a more detailed repro so that I can confirm what I'm seeing.
On quick review - the secret value was just a string with $ in the middle of it - no { } pr characters included.
I am going to recreate the stack with the secret included to pull the logs and be more specific of what I am seeing.
@bastienlc commented on GitHub (Mar 22, 2026):
I had a similar issue but the root cause is docker compose interpolation.
I'm using Komodo to inject variables in my docker compose services, typically in the stack configuration I have:
And in the docker-compose.yml file:
If
KOMODO_VARcontainssigns, things can get tricky. I see in the `.env` generated by Komodo that the value is rendered correctly there. The issue appears when docker compose does its interpolation. One solution is to escapesigns by replacing them by $$ inKOMODO_VAR.Having Komodo automatically escape these characters could be a nice feature!