IP Ranges & Allow-Listing
Purpose: what to put in your firewall or SaaS allow-list for CMDash's outbound connector traffic, and why the honest answer is "it depends on your deployment model" rather than a fixed list.
This page is linked from the FAQ and Troubleshooting guides, both of which tell a customer whose integration can't reach an on-premises system (Nessus, internal Jira, etc.) to check firewall/IP allow-listing here. Read this page before you open a firewall change request — the answer below is the answer those tickets need, and it depends on which of CMDash's deployment models your workspace runs as.
The short answer
CMDash's hosted SaaS does not publish a fixed set of egress IP addresses today. If your source system (an on-prem scanner, an internal ticketing instance, an internal Jira/GRC tool) restricts inbound connections by IP, there is no static CMDash SaaS IP or CIDR range you can allow-list against.
This is a real limitation, not an oversight we're hiding — see What this means for you for the two ways around it.
Why there's no fixed range
| Deployment model | Where connector traffic actually originates |
|---|---|
| Hosted (SaaS) | Every integration call (pulling from Nessus, Jira, a cloud CSPM, etc.) is made by the API service on CMDash's shared hosted infrastructure. That infrastructure does not sit behind a static NAT/Elastic IP, so the source address can and does change over time. |
| Self-hosted (your own AWS / Lightsail) | The connector calls originate from your own infrastructure — the instance(s) you deployed and control. Your outbound traffic uses whatever address(es) your own VPC/NAT/Lightsail networking assigns, which you can fix and document yourself. |
| On-prem | Same as self-hosted: connector traffic egresses from your own network's addresses, under your own control, because you (or your ops team) run and update the stack directly on your host. See Deployment Models. |
In other words: allow-listing "CMDash's IP" is only a meaningful, stable request on the two deployment models where the infrastructure is yours.
What this means for you
If a source system needs to allow-list inbound connections by IP and you're on hosted SaaS, you have two options — neither requires waiting on us to publish a range that doesn't exist:
- Move that connection to a self-hosted or on-prem deployment. Once CMDash runs on infrastructure you control, its outbound address is one you can fix (a static Elastic IP, a NAT gateway, or your existing egress proxy) and allow-list normally. See Deployment Models for what that migration involves.
- Use a local collector instead of a direct inbound allow-list. For systems that cannot be reached from the public internet under any circumstances (common with an internal Jira instance or an on-prem vulnerability scanner), point the integration at a collector process running inside your own network that calls out to CMDash, rather than CMDash calling in. This avoids the allow-listing question entirely because no connection needs to reach your network from outside it. Check the specific integration's setup guide under Integrations for whether a collector mode is available for that connector.
What we do publish
- TLS/HTTPS only. Every connector call outbound from CMDash uses HTTPS; there is no unencrypted transport to allow-list around.
- Deployment model, which determines whether "CMDash's IP" is even a well-formed question — see the table above.
If your procurement or security review needs something more specific than this page (e.g. a signed statement for a self-hosted deployment's fixed address), raise it with your CMDash contact rather than assuming a SaaS-wide range exists — it doesn't, and a documented static range is only ever true of infrastructure you or we have specifically pinned down for your instance.