Currently, when adding a new server (komodo-periphery) to Komodo, all the communication between Komodo and the registered servers is made with a non configurable set of headers only.
In some environments (like Cloudflares Service Tokens for Zero-Trust), additional headers are required to authenticate / authorize the requests for machine-to-machine communication.
Proposed Feature
Add support for defining custom HTTP headers when registering a new server in Komodo.
Users should be able to specify one or more headers (key + value) for each server.
These headers should then be included in every request Komodo makes to that specific server.
Ideally, headers should be stored securely (e.g., encrypted at rest, not shown in plain text after saving).
Use Case / Example
In my case, I’m using Cloudflare Zero Trust Network Access (ZTNA).
Each request to the protected service must include a service token in two specific HTTP headers (CF-Access-Client-Id + CF-Access-Client-Secret). Without the ability to attach this header, komodo cannot communicate with the periphery server behind Cloudflare ZTNA and I have to fallback to an IP based whitelisting within in my ZTNA configuration.
Benefits
enables Komodo to be easily used in Cloudflare ZTNA environments
provides flexibility for other custom auth/security mechanisms.
Originally created by @codejanovic on GitHub (Aug 28, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/782
## Description
Currently, when adding a new server (komodo-periphery) to Komodo, all the communication between Komodo and the registered servers is made with a non configurable set of headers only.
In some environments (like [Cloudflares Service Tokens](https://developers.cloudflare.com/cloudflare-one/identity/service-tokens/) for Zero-Trust), additional headers are required to authenticate / authorize the requests for machine-to-machine communication.
## Proposed Feature
Add support for defining custom HTTP headers when registering a new server in Komodo.
- Users should be able to specify one or more headers (key + value) for each server.
- These headers should then be included in every request Komodo makes to that specific server.
- Ideally, headers should be stored securely (e.g., encrypted at rest, not shown in plain text after saving).
## Use Case / Example
In my case, I’m using **Cloudflare Zero Trust Network Access (ZTNA)**.
Each request to the protected service must include a [service token](https://developers.cloudflare.com/cloudflare-one/identity/service-tokens/) in two specific HTTP headers (CF-Access-Client-Id + CF-Access-Client-Secret). Without the ability to attach this header, komodo cannot communicate with the periphery server behind Cloudflare ZTNA and I have to fallback to an IP based whitelisting within in my ZTNA configuration.
## Benefits
- enables Komodo to be easily used in Cloudflare ZTNA environments
- provides flexibility for other custom auth/security mechanisms.
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 @codejanovic on GitHub (Aug 28, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/782
Description
Currently, when adding a new server (komodo-periphery) to Komodo, all the communication between Komodo and the registered servers is made with a non configurable set of headers only.
In some environments (like Cloudflares Service Tokens for Zero-Trust), additional headers are required to authenticate / authorize the requests for machine-to-machine communication.
Proposed Feature
Add support for defining custom HTTP headers when registering a new server in Komodo.
Use Case / Example
In my case, I’m using Cloudflare Zero Trust Network Access (ZTNA).
Each request to the protected service must include a service token in two specific HTTP headers (CF-Access-Client-Id + CF-Access-Client-Secret). Without the ability to attach this header, komodo cannot communicate with the periphery server behind Cloudflare ZTNA and I have to fallback to an IP based whitelisting within in my ZTNA configuration.
Benefits