I’m replacing P* with Komodo, and everything works correctly except when the periphery server is located on a different VLAN. The Komodo core server and private Git server have unrestricted access to the periphery VLAN (including all related traffic). However, the periphery VLAN is restricted from initiating connections back to the VLAN containing the core and Git servers.
Details
The only explanation I can think of is that the periphery server is attempting to initiate a connection to either the core or Git server. I haven’t found anything in the documentation indicating that this should happen; my understanding is that the core server handles all communications.
This issue only occurs when using a Git repository for the compose file. Deployments work correctly on the periphery servers when the compose file is stored directly in the Komodo UI, but fail when the compose file is sourced from Git.
Question
Do you have any insight into why this might be happening, and how it could be resolved?
Thank you.
Originally created by @itwasdolly on GitHub (Nov 26, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/1005
**Issue Summary**
I’m replacing P* with Komodo, and everything works correctly except when the periphery server is located on a different VLAN. The Komodo core server and private Git server have unrestricted access to the periphery VLAN (including all related traffic). However, the periphery VLAN is restricted from initiating connections back to the VLAN containing the core and Git servers.
**Details**
The only explanation I can think of is that the periphery server is attempting to initiate a connection to either the core or Git server. I haven’t found anything in the documentation indicating that this should happen; my understanding is that the core server handles all communications.
This issue only occurs when using a Git repository for the compose file. Deployments work correctly on the periphery servers when the compose file is stored directly in the Komodo UI, but fail when the compose file is sourced from Git.
**Question**
Do you have any insight into why this might be happening, and how it could be resolved?
Thank you.
<!-- gh-comment-id:3582672778 -->
@itwasdolly commented on GitHub (Nov 26, 2025):
This might be related to issue https://github.com/moghtech/komodo/issues/905
Ultimately, it's the working copy of the repo on the server that is used when docker compose up is run. So it needs to be able to pull down a local copy. Otherwise a compose file that brings in specific env files wouldn't work without specifying every single file from the repo to copy over to the periphery server, for example.
Also can't really use git-hosted compose files to manage the git server hosting them, or a reverse proxy in front of the git server, either. It brings down the service, then tries pull from the repo which is no longer reachable. I found out that one the hard way.
<!-- gh-comment-id:3618842961 -->
@Kaiede commented on GitHub (Dec 5, 2025):
> However, the periphery VLAN is restricted from initiating connections back to the VLAN containing the core and Git servers.
This seems expected. The periphery server has an API where the central service tells it to clone or pull a particular repo: https://github.com/moghtech/komodo/blob/main/client/periphery/rs/src/api/git.rs
Ultimately, it's the working copy of the repo on the server that is used when `docker compose up` is run. So it needs to be able to pull down a local copy. Otherwise a compose file that brings in specific env files wouldn't work without specifying every single file from the repo to copy over to the periphery server, for example.
Also can't really use git-hosted compose files to manage the git server hosting them, or a reverse proxy in front of the git server, either. It brings down the service, then tries pull from the repo which is no longer reachable. I found out that one the hard way.
So the solution is to allow connections from the periphery server back to the git server?
Wouldn't a more secure solution be for the core server to copy the cloned repo over to the periphery server on deployment, much like Ansible does?
<!-- gh-comment-id:3643692507 -->
@itwasdolly commented on GitHub (Dec 11, 2025):
So the solution is to allow connections from the periphery server back to the git server?
Wouldn't a more secure solution be for the core server to copy the cloned repo over to the periphery server on deployment, much like Ansible does?
Wouldn't a more secure solution be for the core server to copy the cloned repo over to the periphery server on deployment?
Depends. If following good practices, then the repo with the compose and env files shouldn't include secrets, and instead manage them using something like Komodo's variables feature. So in this case, the repo itself isn't exactly sensitive data. But if you share a git server with sensitive data (code for a personal project), then I'd probably look at that and suggest that could be improved by splitting it out into two services. One for the management VLAN and one for the services VLAN. Easier than trying to setup fine-grained controls if you are truly paranoid, IMO.
I have a setup where the git server hosting my code-as-infra setup lives in the homelab network. Komodo core lives on a trusted network, and I have a similar firewall setup to yours. Komodo can tell a docker host to pull the repo and deploy the service, while providing an .env file with secrets that doesn't come from the repo. The gotcha is that webhooks don't work in this setup, but I don't currently rely on them for auto-deployment. If I needed them, I'd likely setup a small reverse-proxy that can act like a psudeo-WAF to only allow the specific webhooks back to Komodo that I want, and only from the specific host(s) that should be allowed to trigger them.
But keep in mind I'm also just another user. Mostly just figured I'd point out the behavior as written. I am not in a position to make statements on behalf of the Komodo project itself.
<!-- gh-comment-id:3643918085 -->
@Kaiede commented on GitHub (Dec 11, 2025):
> Wouldn't a more secure solution be for the core server to copy the cloned repo over to the periphery server on deployment?
Depends. If following good practices, then the repo with the compose and env files shouldn't include secrets, and instead manage them using something like Komodo's variables feature. So in this case, the repo itself isn't exactly sensitive data. But if you share a git server with sensitive data (code for a personal project), then I'd probably look at that and suggest that could be improved by splitting it out into two services. One for the management VLAN and one for the services VLAN. Easier than trying to setup fine-grained controls if you are truly paranoid, IMO.
I have a setup where the git server hosting my code-as-infra setup lives in the homelab network. Komodo core lives on a trusted network, and I have a similar firewall setup to yours. Komodo can tell a docker host to pull the repo and deploy the service, while providing an .env file with secrets that doesn't come from the repo. The gotcha is that webhooks don't work in this setup, but I don't currently rely on them for auto-deployment. If I needed them, I'd likely setup a small reverse-proxy that can act like a psudeo-WAF to only allow the specific webhooks back to Komodo that I want, and only from the specific host(s) that should be allowed to trigger them.
But keep in mind I'm also just another user. Mostly just figured I'd point out the behavior as written. I am not in a position to make statements on behalf of the Komodo project itself.
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 @itwasdolly on GitHub (Nov 26, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/1005
Issue Summary
I’m replacing P* with Komodo, and everything works correctly except when the periphery server is located on a different VLAN. The Komodo core server and private Git server have unrestricted access to the periphery VLAN (including all related traffic). However, the periphery VLAN is restricted from initiating connections back to the VLAN containing the core and Git servers.
Details
The only explanation I can think of is that the periphery server is attempting to initiate a connection to either the core or Git server. I haven’t found anything in the documentation indicating that this should happen; my understanding is that the core server handles all communications.
This issue only occurs when using a Git repository for the compose file. Deployments work correctly on the periphery servers when the compose file is stored directly in the Komodo UI, but fail when the compose file is sourced from Git.
Question
Do you have any insight into why this might be happening, and how it could be resolved?
Thank you.
@itwasdolly commented on GitHub (Nov 26, 2025):
This might be related to issue https://github.com/moghtech/komodo/issues/905
@Kaiede commented on GitHub (Dec 5, 2025):
This seems expected. The periphery server has an API where the central service tells it to clone or pull a particular repo: https://github.com/moghtech/komodo/blob/main/client/periphery/rs/src/api/git.rs
Ultimately, it's the working copy of the repo on the server that is used when
docker compose upis run. So it needs to be able to pull down a local copy. Otherwise a compose file that brings in specific env files wouldn't work without specifying every single file from the repo to copy over to the periphery server, for example.Also can't really use git-hosted compose files to manage the git server hosting them, or a reverse proxy in front of the git server, either. It brings down the service, then tries pull from the repo which is no longer reachable. I found out that one the hard way.
@itwasdolly commented on GitHub (Dec 11, 2025):
So the solution is to allow connections from the periphery server back to the git server?
Wouldn't a more secure solution be for the core server to copy the cloned repo over to the periphery server on deployment, much like Ansible does?
@Kaiede commented on GitHub (Dec 11, 2025):
Depends. If following good practices, then the repo with the compose and env files shouldn't include secrets, and instead manage them using something like Komodo's variables feature. So in this case, the repo itself isn't exactly sensitive data. But if you share a git server with sensitive data (code for a personal project), then I'd probably look at that and suggest that could be improved by splitting it out into two services. One for the management VLAN and one for the services VLAN. Easier than trying to setup fine-grained controls if you are truly paranoid, IMO.
I have a setup where the git server hosting my code-as-infra setup lives in the homelab network. Komodo core lives on a trusted network, and I have a similar firewall setup to yours. Komodo can tell a docker host to pull the repo and deploy the service, while providing an .env file with secrets that doesn't come from the repo. The gotcha is that webhooks don't work in this setup, but I don't currently rely on them for auto-deployment. If I needed them, I'd likely setup a small reverse-proxy that can act like a psudeo-WAF to only allow the specific webhooks back to Komodo that I want, and only from the specific host(s) that should be allowed to trigger them.
But keep in mind I'm also just another user. Mostly just figured I'd point out the behavior as written. I am not in a position to make statements on behalf of the Komodo project itself.