Skip to main content
This page covers the network configuration required to run Cymph alongside the systems it connects to — SIEMs, SOAR platforms, ticketing systems and repositories. It applies to both deployment models; the parts that differ are split out below.
Setting up an individual integration is covered in Integrations. This page is for the network and firewall work that has to happen around it.

​
Inbound access

Self-hosted. The web application listens on the IP address and port you choose during installation, over HTTPS. Users and API clients need to reach that address, so allow it through any host firewall, and if you front Cymph with a reverse proxy or load balancer, terminate or pass through TLS there. See TLS certificates.
That one port is the only one to open. The web application, API, embedding service and database are all bound to the internal Docker network and are not published on the host, so there is no second entry point to firewall off.
Managed cloud tenant. Your tenant is reachable at its own hostname over HTTPS on port 443. DNS and certificates are handled by Cymph, so there is no inbound work on your side beyond permitting outbound HTTPS from your users to that hostname.

​
Egress control

Several integrations require Cymph to make outbound connections to an endpoint you operate — SIEM APIs (Wazuh, Microsoft Sentinel), SOAR platforms, ticketing systems, and similar. When that endpoint sits behind a firewall or a source-IP allowlist (standard practice in financial and government environments), the connection is refused unless Cymph’s egress address is permitted. Symptoms of a missing allowlist entry:
  • Test Connection fails with 403 or a connection timeout.
  • A previously working integration goes dead while its status still shows Enabled — the only clue is the 403s in your own endpoint’s access logs.
How you allowlist depends on which deployment model you run.

​
Self-hosted

Cymph runs inside your own environment, so its outbound traffic leaves from infrastructure you control — the API host, or the NAT gateway / egress proxy in front of it.
  • Allowlist by FQDN wherever your firewall supports it. Put the FQDN of your Cymph deployment (or its egress NAT) in the allowlist rather than a raw IP, so the rule survives host or IP changes.
  • If your allowlist is strictly IP-based, use the static egress IP / CIDR of the NAT gateway or proxy that fronts Cymph. Because you own this hop, the address is stable and already known to your network team.
  • No coordination with Cymph is required — the egress point is entirely within your network.

​
Managed cloud tenant

Managed tenants run on AWS in eu-west-1 (Europe / Ireland). Outbound connections originate from AWS-owned IP addresses in that region:
  • 34.252.152.14
  • 52.19.159.74
  • 54.220.85.57
All three are in use, and they are shared across managed tenants. An allowlist must contain every address, not just the ones observed in your own logs — traffic for a given sync can leave from any of them.

​
Change policy for egress addresses

The addresses above are stable, but infrastructure changes do occasionally require them to move.
Cymph gives at least 15 days’ notice before any change to these egress addresses, so your network team has time to update firewall rules ahead of the change. Notice is sent on the channel agreed with your organisation.
New addresses are added to this page as soon as the notice goes out, so an allowlist that covers both the current and the announced addresses stays working across the transition.
If your organisation routes change requests through a ticketing process with a lead time longer than 15 days, let us know at support@cymph.io and we can flag your organisation for earlier notice.

​
Outbound connections Cymph makes

Regardless of model, the deployment connects outbound only to:
  • The integration endpoints you configure.
  • Your AI provider, if you have configured one — see AI configuration.
  • Your SMTP server, if you have configured one — see SMTP.
  • Your identity provider, if you have enabled single sign-on — see Single sign-on.
Semantic search embeddings are generated by a service inside the deployment, so no outbound connection is needed for search.