Originally created by @JavertArdo on GitHub (Aug 7, 2025).
The problem appears when deploying Komodo Core in Kubernetes. When not specifying directly KOMODO_PORT value (which should be 9120 by default), Pod crashes with following error:
kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
app-komodo komodo-f964fbff9-97pmk 0/1 Error 1(3s ago) 12s
kubectl logs komodo-f964fbff9-97pmk -n app-komodo
thread 'tokio-runtime-worker' panicked at bin/core/src/config.rs:24:11:
Error {
context: "failed to parse core Env",
source: Custom("invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT",
),
}
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: task 5 panicked with message "Error {\n context: \"failed to parse core Env\",\n source: Custom(\n \"invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT\",\n ),\n}"
The workaround is to explicitly define or somehow override KOMODO_PORT to 9120.
...env:...- name:KOMODO_PORTvalue:"9120"...
kubectl get pods -ANAMESPACE NAME READY STATUS RESTARTS AGEapp-komodo komodo-7c6659c6b-7p588 1/1 Running 0 17m
I didn't notice this issue using Podman Compose when not specifying the KOMODO_PORT. If I understand the error correctly, instead of having only the number in KOMODO_PORT the application appended prefix tcp://10.101.108.109: before parsing value?
Version: komodo-core:1.18.4
Originally created by @JavertArdo on GitHub (Aug 7, 2025).
The problem appears when deploying Komodo Core in Kubernetes. When not specifying directly `KOMODO_PORT` value (which should be 9120 by default), Pod crashes with following error:
```shell
kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
app-komodo komodo-f964fbff9-97pmk 0/1 Error 1 (3s ago) 12s
```
```shell
kubectl logs komodo-f964fbff9-97pmk -n app-komodo
thread 'tokio-runtime-worker' panicked at bin/core/src/config.rs:24:11:
Error {
context: "failed to parse core Env",
source: Custom(
"invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT",
),
}
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: task 5 panicked with message "Error {\n context: \"failed to parse core Env\",\n source: Custom(\n \"invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT\",\n ),\n}"
```
Here is the configuration:
```yaml
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: komodo-core
namespace: app-komodo
stringData:
KOMODO_JWT_SECRET: "yoursecret"
KOMODO_PASSKEY: "yoursecret"
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: komodo-database
namespace: app-komodo
stringData:
KOMODO_DATABASE_ADDRESS: "yourip:27017"
KOMODO_DATABASE_USERNAME: "mongo"
KOMODO_DATABASE_PASSWORD: "password"
```
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: komodo
namespace: app-komodo
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: komodo
template:
metadata:
labels:
app.kubernetes.io/name: komodo
spec:
containers:
- name: core
image: ghcr.io/moghtech/komodo-core:1.18.4
ports:
- name: http
containerPort: 9120
env:
- name: KOMODO_LOCAL_AUTH
value: "true"
- name: KOMODO_DISABLE_USER_REGISTRATION
value: "false"
- name: KOMODO_OIDC_ENABLED
value: "false"
envFrom:
- secretRef:
name: komodo-core
- secretRef:
name: komodo-database
volumeMounts:
- name: komodo-cache
mountPath: /repo-cache
volumes:
- name: komodo-cache
persistentVolumeClaim:
claimName: komodo-cache
```
The workaround is to explicitly define or somehow override `KOMODO_PORT` to 9120.
```yaml
...
env:
...
- name: KOMODO_PORT
value: "9120"
...
```
```yaml
kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
app-komodo komodo-7c6659c6b-7p588 1/1 Running 0 17m
```
I didn't notice this issue using Podman Compose when not specifying the `KOMODO_PORT`. If I understand the error correctly, instead of having only the number in `KOMODO_PORT` the application appended prefix `tcp://10.101.108.109:` before parsing value?
Version: komodo-core:1.18.4
I'm not sure where that Komodo port value is coming from, I don't see where it would be, unless you also give it a config file with this value
@mbecker20 commented on GitHub (Aug 19, 2025):
I'm not sure where that Komodo port value is coming from, I don't see where it would be, unless you also give it a config file with this value
After digging a little bit I might have some suspicion that this value comes from different environment variable.
When we log into pod (the working one after applying workaround, since the previous is crashing while parsing config values) shell and print all mounted environment variables, I see some of them are auto mounted by Kubernetes.
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
app-komodo komodo-7c6659c6b-7p588 1/1 Running 0 13d
As we can see four of them are auto created by Kubernetes for Service defined for this Pod.
So, is it possible that Komodo is trying to get any env starting with KOMODO_PORT. Since in faulty scenario KOMODO_PORT is not explicitly defined we should have only four of them in Pod. So, Komodo get the shortest matching env starting with KOMODO_PORT? Which is KOMODO_PORT_9120_TCP and then parsing failed, since the value was not a digit.
I believe Podman does not automount such env vars in container. Hence, the issue is observed only in Kubernetes in the same configuration.
@JavertArdo commented on GitHub (Aug 20, 2025):
After digging a little bit I might have some suspicion that this value comes from different environment variable.
When we log into pod (the working one after applying workaround, since the previous is crashing while parsing config values) shell and print all mounted environment variables, I see some of them are auto mounted by Kubernetes.
```shell
$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
app-komodo komodo-7c6659c6b-7p588 1/1 Running 0 13d
```
```shell
$ kubectl exec -it -n app-komodo pod/komodo-7c6659c6b-7p588 -- /bin/sh
```
```shell
$ env | grep KOMODO_PORT
KOMODO_PORT_9120_TCP_PORT=9120
KOMODO_PORT_9120_TCP_PROTO=tcp
KOMODO_PORT=9120
KOMODO_PORT_9120_TCP=tcp://10.102.138.69:9120
KOMODO_PORT_9120_TCP_ADDR=10.102.138.69
```
```yaml
apiVersion: v1
kind: Service
metadata:
name: komodo
namespace: app-komodo
spec:
type: ClusterIP
selector:
app.kubernetes.io/name: komodo
ports:
- protocol: TCP
port: 9120
targetPort: 9120
```
And the format seems to be:
```
{SERVICE_NAME}_PORT_{PORT_VALUE}_{PROTOCOL}
```
As we can see four of them are auto created by Kubernetes for Service defined for this Pod.
So, is it possible that Komodo is trying to get any env starting with `KOMODO_PORT`. Since in faulty scenario `KOMODO_PORT` is not explicitly defined we should have only four of them in Pod. So, Komodo get the shortest matching env starting with `KOMODO_PORT`? Which is `KOMODO_PORT_9120_TCP` and then parsing failed, since the value was not a digit.
I believe Podman does not automount such env vars in container. Hence, the issue is observed only in Kubernetes in the same configuration.
I don't believe Komodo will parse KOMODO_PORT from any other variable other than KOMODO_PORT exactly. For example, I cannot reproduce this through passing KOMODO_PORT_9120_TCP on the environment.
I am closing this issue as its kind of out of scope, but if you have any other comments I will see it.
@mbecker20 commented on GitHub (Aug 30, 2025):
I don't believe Komodo will parse `KOMODO_PORT` from any other variable other than `KOMODO_PORT` exactly. For example, I cannot reproduce this through passing `KOMODO_PORT_9120_TCP` on the environment.
I am closing this issue as its kind of out of scope, but if you have any other comments I will see it.
Just to leave a comment for others. I agree with you that it is not Komodo issue, it is a Kubernetes way of env variables injection into Pods. The problem is due to naming collision of Komodo variables and created Kubernetes Service. I deployed some other app to test.
/ # env | grep -i myappMYAPP_PORT_3000_TCP=tcp://10.98.73.132:3000
MYAPP_SERVICE_HOST=10.98.73.132
MYAPP_SERVICE_PORT=3000MYAPP_PORT=tcp://10.98.73.132:3000 <-- Auto created by Kubernetes
MYAPP_PORT_3000_TCP_ADDR=10.98.73.132
MYAPP_PORT_3000_TCP_PORT=3000MYAPP_PORT_3000_TCP_PROTO=tcp
Now I am sure that Kubernetes created KOMODO_PORT with value tcp://10.101.108.109:9120 which caused an error during parsing. When explicitly defined KOMODO_PORT with valid value (which overriden previous one) then there was no issue.
@mbecker20, thank you for taking a look and your time.
@JavertArdo commented on GitHub (Aug 30, 2025):
Just to leave a comment for others. I agree with you that it is not Komodo issue, it is a Kubernetes way of env variables injection into Pods. The problem is due to naming collision of Komodo variables and created Kubernetes Service. I deployed some other app to test.
```shell
/ # env | grep -i myapp
MYAPP_PORT_3000_TCP=tcp://10.98.73.132:3000
MYAPP_SERVICE_HOST=10.98.73.132
MYAPP_SERVICE_PORT=3000
MYAPP_PORT=tcp://10.98.73.132:3000 <-- Auto created by Kubernetes
MYAPP_PORT_3000_TCP_ADDR=10.98.73.132
MYAPP_PORT_3000_TCP_PORT=3000
MYAPP_PORT_3000_TCP_PROTO=tcp
```
```yaml
apiVersion: v1
kind: Service
metadata:
name: myapp
namespace: app-myapp
spec:
type: ClusterIP
selector:
app.kubernetes.io/name: myapp
ports:
- protocol: TCP
port: 3000
targetPort: 3000
```
Now I am sure that Kubernetes created `KOMODO_PORT` with value `tcp://10.101.108.109:9120` which caused an error during parsing. When explicitly defined `KOMODO_PORT` with valid value (which overriden previous one) then there was no issue.
@mbecker20, thank you for taking a look and your time.
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 @JavertArdo on GitHub (Aug 7, 2025).
The problem appears when deploying Komodo Core in Kubernetes. When not specifying directly
KOMODO_PORTvalue (which should be 9120 by default), Pod crashes with following error:Here is the configuration:
The workaround is to explicitly define or somehow override
KOMODO_PORTto 9120.I didn't notice this issue using Podman Compose when not specifying the
KOMODO_PORT. If I understand the error correctly, instead of having only the number inKOMODO_PORTthe application appended prefixtcp://10.101.108.109:before parsing value?Version: komodo-core:1.18.4
@mbecker20 commented on GitHub (Aug 19, 2025):
I'm not sure where that Komodo port value is coming from, I don't see where it would be, unless you also give it a config file with this value
@JavertArdo commented on GitHub (Aug 20, 2025):
After digging a little bit I might have some suspicion that this value comes from different environment variable.
When we log into pod (the working one after applying workaround, since the previous is crashing while parsing config values) shell and print all mounted environment variables, I see some of them are auto mounted by Kubernetes.
And the format seems to be:
As we can see four of them are auto created by Kubernetes for Service defined for this Pod.
So, is it possible that Komodo is trying to get any env starting with
KOMODO_PORT. Since in faulty scenarioKOMODO_PORTis not explicitly defined we should have only four of them in Pod. So, Komodo get the shortest matching env starting withKOMODO_PORT? Which isKOMODO_PORT_9120_TCPand then parsing failed, since the value was not a digit.I believe Podman does not automount such env vars in container. Hence, the issue is observed only in Kubernetes in the same configuration.
@mbecker20 commented on GitHub (Aug 30, 2025):
I don't believe Komodo will parse
KOMODO_PORTfrom any other variable other thanKOMODO_PORTexactly. For example, I cannot reproduce this through passingKOMODO_PORT_9120_TCPon the environment.I am closing this issue as its kind of out of scope, but if you have any other comments I will see it.
@JavertArdo commented on GitHub (Aug 30, 2025):
Just to leave a comment for others. I agree with you that it is not Komodo issue, it is a Kubernetes way of env variables injection into Pods. The problem is due to naming collision of Komodo variables and created Kubernetes Service. I deployed some other app to test.
Now I am sure that Kubernetes created
KOMODO_PORTwith valuetcp://10.101.108.109:9120which caused an error during parsing. When explicitly definedKOMODO_PORTwith valid value (which overriden previous one) then there was no issue.@mbecker20, thank you for taking a look and your time.