Ingress
Ingress configuration determines whether a deployed service is reachable from the internet. In Service Hub, ingress is a two-field toggle on the Service spec that connects a deployment to a configured DNS domain.
Ingress Settings
A Service's ingress configuration has two settings:
| Setting | Purpose |
|---|---|
| Ingress enabled | Whether the service is publicly accessible. Disabled by default. |
| DNS domain | The DNS domain to use for ingress routing. Required when ingress is enabled. |
When ingress is enabled, Planton creates the appropriate ingress resources for the deployment target — Kubernetes Ingress objects, load balancer listener rules, or platform-specific routing — and configures the service to be accessible at a subdomain under the selected DNS domain.
When ingress is disabled (the default), the service is deployed but not publicly accessible. This is appropriate for:
- Internal services that communicate only with other services in the cluster
- Background workers and cron jobs
- Services in early development where public access is not yet needed
DNS Domains
DNS domains are managed as a separate resource in Service Hub. Each domain has:
| Property | Purpose |
|---|---|
| Domain name | The DNS domain (e.g., example.com, *.staging.example.com) |
| Description | Human-readable description of the domain's purpose |
Domains are configured at the organization level and can be referenced by any service in the organization. A single domain can serve multiple services — each service receives its own subdomain.
Managing DNS Domains
Web Console
The Domains tab on the Service Hub landing page provides:
- List of all configured domains in the organization
- Search and filter
- Add new domains
- Delete existing domains
Configuring Ingress on a Service
In the web console, ingress is configured in the service details page under the Overview or Settings tab. The configuration provides:
- An enable/disable toggle
- A dropdown to select from configured DNS domains
How Ingress Relates to Deployment Targets
The behavior of ingress depends on the deployment target. When ingress is enabled:
- Kubernetes deployments: An Ingress resource or ingress controller configuration is created, routing traffic from the domain to the service's pods.
- AWS ECS: Load balancer listener rules and target groups are configured.
- GCP Cloud Run: The service is mapped to the domain through Cloud Run's domain mapping.
- Cloudflare Workers: Workers are bound to routes under the configured domain.
The specific infrastructure provisioned is handled by the deployment component for each target kind. The Service's ingress configuration is the same regardless of the deployment target — the abstraction is intentional.
Two things to know when the hostname is yours rather than composed. A route or ingress you author with its own hostname is an address the platform discovers after it applies (see How the URL Is Found) — so it appears on the service page and in planton service urls and is probed like any other. And deploy.hostname is one label for every environment on purpose: environments differ by the serving DOMAIN they declare, so api under dev.example.com and api under example.com are the dev and production addresses of one service, while two environments sharing a domain would collide and are refused at save.
Related Documentation
- What is a Service? — Service configuration overview
- Deployment Targets — Where services run
- Pipelines — The pipeline execution model
Next article