Back

Everything you need to know about the new Coralogix Endpoints

Coralogix Team Jul 03, 2025

9 mins read

Coralogix is adopting a static Elastic IP strategy for all Load Balancers, combined with the rollout of a new regional DNS endpoint convention. This milestone eliminates the need for repeated customer updates during infrastructure upgrades and streamlines global endpoint management.

The changes we are making to our endpoints

Coralogix has made two key changes to the regional domains.

The first is the DNS records themselves, changing the actual URL.
The second is the IPs behind those DNS records.

Who will be affected by the IP range changes

Only customers who use the ingress.<domain_value> or syslog.<domain_value> endpoints need to whitelist our new Load Balancer IP ranges.

Customers in EU2 and AP3 environments

Add the new Load Balancer IP ranges to your IP allowlists without removing the existing ones. Deprecation for the previous IPs will be announced in advance.

How to update to the new endpoints

This guide will lay out how to discover the Coralogix APIs in commonly utilised infrastructure, as well as provide all the information you need to make the change. By following this guide, you will get a clear picture of where the majority of your Coralogix integrations are within your environment, as well as all the information you need to translate your existing configuration to the new endpoints.

Prerequisites

You should have access to the environment you wish to update, for example kubectl should be configured and ready to query.
Necessary permissions to run scans over your entire platform. If you only have limited permissions, this may be okay, provided you’re able to access the resources you need.
Knowledge of which Coralogix environment you are using (See FAQ: How do I know my environment?)

IP Whitelisting the new CIDR Ranges for Egress

Below are environments with their associated IP addresses.

Environment	Existing whitelist IP’s (Public Ingress)	New whitelist CIDR range	Public domain
US1 – Ohio	18.119.84.1983.22.174.33.139.112.94	18.97.138.64/26	us1.coralogix.com
US2 – Oregon	44.228.187.149	18.98.18.192/26	us2.coralogix.com
EU1 – Ireland	34.253.20.018.203.53.23152.212.0.182	18.97.198.64/26	eu1.coralogix.com
EU2 – Stockholm	13.53.114.4116.170.111.13113.50.102.213	18.99.99.64/26	eu2.coralogix.com
AP1 – India	3.109.88.813.127.95.18443.204.151.45	18.96.228.0/26	ap1.coralogix.com
AP2 – Singapore	52.77.57.11552.221.106.20718.142.194.181	18.99.41.64/26	ap2.coralogix.com
AP3 – Jakarta	108.137.195.232	18.98.97.0/26	ap3.coralogix.com

These IP ranges should be updated in any IP whitelisting you have. Examples of resources that may need to change are:

Kubernetes NetworkPolicy resource instances
AWS Security Groups
Azure Network Security groups

Customers are encouraged to whitelist the entire CIDR block per region to ensure uninterrupted service through future upgrades, scaling and rebalancing.

Updating to the new region format

Here is a mapping of the old domain to new endpoints. Any instance of the old domain should be replaced with the new domain. For any new domain that is suffixed with “NO CHANGE”, the domains have not changed and there is no work to do.

Environment	Old Domain	New Domain
US1 – Ohio	coralogix.us	us1.coralogix.com
US2 – Oregon	cx498.coralogix.com	us2.coralogix.com
EU1 – Ireland	coralogix.com	eu1.coralogix.com
EU2 – Stockholm	eu2.coralogix.com	eu2.coralogix.com (NO CHANGE)
AP1 – India	coralogix.in	ap1.coralogix.com
AP2 – Singapore	coralogixsg.com	ap2.coralogix.com
AP3 – Jakarta	ap3.coralogix.com	ap3.coralogix.com (NO CHANGE)

Endpoint change example

When migrating to a new endpoint, update your current configuration as follows:

For the us1 region:
ingress.coralogix.us → ingress.us1.coralogix.com
For the us2 region:
ingress.cx498.coralogix.com → ingress.us2.coralogix.com

If you’re using our Helm charts to deploy Kubernetes Complete Observability then these will be set by the global.domain key in the values.yaml. For the Kubernetes Operator, you only need to make a change if you have set coralogixOperator.domain explicitly rather than using coralogixOperator.region.

Discovering the config that needs to change

Coralogix customers often integrate in multiple different ways, especially when they’re running on multiple cloud platforms or when using different infrastructure, like AWS Lambda or Kubernetes. We have produced some simple commands that should help you discover configuration that needs to change in common platforms.

Kubernetes

The following Kubernetes commands will search for Coralogix API references in all Pod resources, ConfigMap resources and will look for images containing the phrase coralogix. These commands assume that both kubectl and jq are installed. This script will go namespace by namespace, looking for relevant resources, and it will prompt you each time.

#!/bin/bash

# Get all namespaces
namespaces=$(kubectl get ns -o jsonpath='{.items[*].metadata.name}')

# Loop through each namespace
for ns in $namespaces; do
  echo "🔍 Scanning namespace: $ns"

  # Prompt user before continuing
  read -p "Press Enter to scan this namespace (or Ctrl+C to stop)..."

  echo "➡️ Checking environment variables in pods..."

  kubectl get pods -n "$ns" -o yaml 2>/dev/null | \

    yq '[ .items[] | select(.metadata.name) as $pod | .spec.containers[].env | to_entries.[] | map({"domain": select(.value | test("coralogix(?:sg)?\\.(?:com|us|in)")).value, "owner": ($pod.metadata.ownerReferences[].name + "/" + $pod.metadata.ownerReferences[].kind)}) | map(select(.domain != null)) | select(length > 0)] | unique.[]' | \

    awk 'NF{matches=0} {matches++; print "\033[35m"$0"\033[0m"} END{if (!matches) print "\033[32mNo matches found\033[0m"}'

  echo "➡️ Checking ConfigMaps..."
  kubectl get configmaps -n "$ns" -o yaml 2>/dev/null | \

    yq '.items[] | select (.metadata.name) as $conf | .data | to_entries | map({"configMapKey": select(.value |test("coralogix(?:sg)?\\.(?:com|us|in)")).key, "domain": (.value | capture("(?P<domain>(?:[a-z0-9\\.])*coralogix(?:sg)?\\.(?:com|us|in))")).domain, "owner": ($conf.metadata.name + "/" + $conf.kind)}) | map(select(.domain != null)) | select(length > 0)' | \

    awk 'NF{matches=0} {matches++; print "\033[35m"$0"\033[0m"} END{if (!matches) print "\033[32mNo matches found\033[0m"}'

  echo "➡️ Checking container images..."
  kubectl get pods -n "$ns" -o yaml 2>/dev/null | \

    yq '[ .items[] | select(.spec.containers[].image | test("(?i)coralogix|CX")) as $pod | map({"image": $pod.spec.containers[].image, "owner": ($pod.metadata.ownerReferences[].name + "/" + $pod.metadata.ownerReferences[].kind)}) | map(select(.image != null)) | unique ] | map(select(length > 0)) | unique.[]' | \

    awk 'NF{matches=0} {matches++; print "\033[35m"$0"\033[0m"} END{if (!matches) print "\033[32mNo matches found\033[0m"}'

  echo -e "\n✅ Finished scanning namespace: $ns"
  echo "----------------------------------------"

done

AWS Lambda

The following AWS CLI commands list serverless Lambda functions, and search for those Lambda functions that have the Coralogix API Key (CX_API_KEY), indicating they are integrated with Coralogix. As an aside, it will also look to see if a function name mentions Coralogix, in case there are any custom integrations.

# List functions with Coralogix token or endpoint in their environment
aws lambda list-functions --query 'Functions[*].FunctionName' --output text | \

xargs -n1 -I{} sh -c '
  aws lambda get-function-configuration --function-name "$1" \
    --query "{FunctionName:FunctionName, Env:Environment.Variables}" \
    --output json | \
  grep -iE "CX_API_KEY|coralogix" && echo "Relevant Lambda Function: $1"
' _ {}

Amazon ECS

For Amazon ECS, the following bash script will use the AWS CLI to pull services that are running in your ECS instances, cluster by cluster, and identify any task definitions that mention the Coralogix domains, both case insensitive.

#!/bin/bash

# List ECS clusters
clusters=$(aws ecs list-clusters --query 'clusterArns[*]' --output text)

for cluster in $clusters; do
  cluster=$(echo $cluster | sed -e 's/^.*\///g')

  echo "🔍 Scanning cluster: $cluster"
  # Get list of service ARNs in the cluster

  services=$(aws ecs list-services --cluster "$cluster" --query 'serviceArns[*]' --output text)

  for service in $services; do
    echo "  ➤ Service: $service"

    # Get task definition from the service
    task_def_arn=$(aws ecs describe-services --cluster "$cluster" --services "$service" \
                      --query 'services[0].taskDefinition' --output text)

    echo "    🔍 Task Definition: $task_def_arn"

    # Describe task definition and search for coralogix domains
    aws ecs describe-task-definition --task-definition "$task_def_arn" \
      --query 'taskDefinition.containerDefinitions[*].[name,image,environment,command]' \
      --output yaml | \

      yq 'map({"TaskDefinition": .[0], "Image":.[1], "domain": (.[2].[] | .value | capture("(?P<domain>coralogix(?:sg)?\\.(?:com|us|in))")).domain })' | \

      awk 'NF{matches=0} {matches++; print "\033[35m"$0"\033[0m"} END{if (!matches) print "\033[32mNo matches found\033[0m"}'

    echo "--------------------------------------------"
  done
done

Why are we making these changes?

These changes bring with them a number of operational efficiencies for our customers.

No more repeated customer coordination during LB changes
Faster infrastructure automation and scalability
Standardized endpoint structure for better clarity and consistency
Reduced operational overhead for both Coralogix and our customers

FAQ

Below are some commonly asked questions that may help you make these changes quickly and easily.

How do I know my environment?

Discerning your environment is a simple case of mapping your team URL to the appropriate domain. For example, a user with the team name my-team.coralogixsg.com is within the AP2 environment.

How do I know if my API is in scope?

Every API is in scope for this change, because every API is scoped to a region using the DNS record. This covers, for example:

OpenTelemetry collectors that are pushing all telemetry types to the Coralogix platform
Integrations that are querying specific endpoints to collect data, alert information and more.
Generic webhooks that are sending data into Coralogix via the APIs.
Use of the management API to update Coralogix resources programmatically.

However, different APIs have different caveats, so it’s important to read the section on updating IP whitelists and make sure you open access to all relevant IP ranges.

View the full list of our APIs and endpoints in the Coralogix documentation.

What if I am using the Coralogix distributions?

If you have integrated with Coralogix through Coralogix managed distributions, like the Kubernetes helm chart or the Coralogix Lambda Telemetry Exporter, then upgrading to the latest versions of these distributions will automatically move you to the most up to date DNS records BUT it will not automatically whitelist the necessary IP ranges. So before upgrading to the latest Coralogix distributions, it is important to ensure the correct IP ranges are permitted.

On this page