How to Set Up Internal Service Communication in Kubernetes
Last updated: December 1, 2025
Overview
When services need to communicate within a Kubernetes cluster on Qovery, the approach depends on whether they are in the same namespace (same Qovery environment) or in different namespaces (different Qovery environments).
Same Namespace (Same Qovery Environment)
When services are deployed in the same Qovery environment, they share the same Kubernetes namespace. Communication is straightforward.
How to configure:
Use the built-in variable
QOVERY_<SERVICE_NAME>_HOST_INTERNALwhich is automatically available for each serviceReference this variable directly in your calling service's environment variables
Example:
If service-a needs to call service-b (both in the same environment):
Create an alias variable in
service-a:SERVICE_B_HOST={{QOVERY_SERVICE_B_HOST_INTERNAL}}Your application can then connect to
SERVICE_B_HOSTon the appropriate port
DNS format (for reference):<service-name> or <service-name>.<namespace>.svc.cluster.local
Cross Namespace (Different Qovery Environments)
When services are in different Qovery environments, they are deployed in different Kubernetes namespaces. You need to use the fully qualified domain name (FQDN).
DNS format:<service-name>.<namespace>.svc.cluster.local
How to configure:
Retrieve the service name: Get the value from
QOVERY_<SERVICE_NAME>_HOST_INTERNALon the target serviceRetrieve the namespace: Get the value from
QOVERY_KUBERNETES_NAMESPACE_NAMEon the target service's environmentCreate the connection string: In the calling service, create an environment variable combining both values
Example:
If service-a (in env-frontend) needs to call service-b (in env-backend):
On
service-b, note the values ofQOVERY_SERVICE_B_HOST_INTERNAL(e.g.,app-z1234567) andQOVERY_KUBERNETES_NAMESPACE_NAME(e.g.,z5678-env-backend)In
service-a, create a variable:SERVICE_B_HOST=app-z1234567.z5678-env-backend.svc.cluster.local
Important Notes
Port configuration: Ensure you're using the internal port configured on your target service (not the external/public port).
Testing connectivity: You can verify TCP connectivity using netcat:
nc -zv <service-host> <port>Same cluster only: This method only works for services deployed on the same Kubernetes cluster.
Important: If your services enforce HTTPS, you'll need to modify your application logic to handle internal traffic differently, as there is no SSL termination for internal Kubernetes communication.