Deployment: Invicti Platform on-premises
Nginx service configuration
The Helm chart exposes configuration options under nginx.service to control how the nginx ingress service is exposed in your Kubernetes cluster. The right choice depends on your infrastructure and how external traffic reaches the cluster.
Service types
LoadBalancer (default)
No configuration is needed to use this mode — it is the default. The cloud provider provisions an external load balancer that routes traffic to the nginx service automatically.
This is the recommended option for managed Kubernetes environments (EKS, AKS, GKE, etc.) where the cloud platform handles load balancer provisioning natively.
# No nginx.service configuration required — LoadBalancer is used by default.
NodePort
Use NodePort when you want to manage your own external load balancer rather than relying on Kubernetes to provision one. This is the typical choice for on-premises deployments where a hardware or software load balancer (e.g. F5, HAProxy, NGINX Plus) already exists in front of the cluster. The service is exposed on a static port on every node, and you configure your external load balancer to distribute traffic to that port across your cluster nodes.
nginx:
service:
type: "NodePort"
nodePort: 30443 # Optional. Defaults to 30443 if omitted.
The service will be reachable at <any-node-ip>:<nodePort>. You can change the port to any value in the Kubernetes NodePort range (default 30000–32767).
ClusterIP
Use ClusterIP when the service should only be reachable from within the cluster. This is useful when an existing ingress controller or reverse proxy already running in the cluster handles inbound traffic and forwards it to the service internally.
nginx:
service:
type: "ClusterIP"
No external port is allocated. The service is accessible only via its cluster-internal DNS name.
Custom service annotations
Annotations can be passed under nginx.service.annotations to influence how the underlying service is provisioned. This is most commonly used with the LoadBalancer type to control provider-specific load balancer behavior, but annotations can be applied regardless of the service type.
nginx:
service:
annotations:
my-organization.com/team: "secops"
my-organization.com/cost-center: "infrastructure"
Typical use cases
Annotations are especially useful for:
- Restricting a load balancer to internal traffic — most cloud providers offer an annotation that prevents the load balancer from receiving a public IP, keeping it accessible only from within your VPC or virtual network.
- Controlling subnet or network placement — on providers like AWS, you can specify which subnets the load balancer should be provisioned in, which is important for multi-AZ deployments or when separating public and private traffic.
- Setting health check parameters — some providers allow you to configure health check paths, intervals, and thresholds through annotations.
- Choosing a load balancer class or SKU — for example, selecting between a standard and a premium tier, or between an NLB and an ALB on AWS.
Refer to your cloud provider's Kubernetes documentation for the full list of supported service annotations. Multiple annotations can be combined freely under the same annotations block.
Need help?
Invicti Support team is ready to provide you with technical help. Go to Help Center