Skip to main content

Setting Up Custom Domains

This guide explains how to expose your application to the public internet using a clean, custom domain name (e.g., api.yourcompany.com).

Automatic vs. Custom Domain Management​

By default, every route you create is automatically assigned a long, fully-qualified domain name (FQDN). This FQDN is dynamically generated based on the resource metadata, providing a unique and predictable endpoint for every service. The format is:

[route-name].[ingress-name].[project-name].[env-name].[ou-name].[org-public-domain]

For example: payment-api-route.api-gateway.payment-gateway.production.retail-banking.fincorp.com

This automatic domain is excellent for development, testing, and internal service-to-service communication. However, for public-facing, production applications, you need a cleaner, more memorable URL.

The PublicIngress manifest is the mechanism you use to achieve this. By setting the spec.domain field in a PublicIngress manifest, you can override the automatic domain generation and expose your services on a clean, custom domain.

The process involves creating two separate manifests:

  1. A PublicIngress to create the load balancer and associate it with your domain.
  2. A HttpRoute (or GrpcRoute, TlsRoute, etc.) to create a rule that directs traffic from a specific path on your domain to your specific application.

Prerequisites​

  • You must have an existing application (e.g., an Application manifest) already defined and running.
  • Your organization must own the custom domain name you wish to use.
  • You need to know the identity of your project: organization, organizational-unit, environment, and project.

Step 1: Create a Manifest for Your Public Ingress​

First, create a new YAML file to define your public ingress. This resource acts as the secure front door for all public traffic to your project.

Step 2: Define Your PublicIngress manifest​

Open your new file and add the following content. This manifest defines the load balancer and links it to your desired domain.

apiVersion: lowops.manifests.v1
kind: PublicIngress
metadata:
  name: api-gateway
  # Project identity is defined here:
  project: payment-gateway
  environment: production
  organizational-unit: retail-banking
  organization: fincorp
spec:
  # 'domain' is an object. 'name' is the base domain; the platform provisions a
  # managed DNS zone + certificates. Delegate the domain to that zone's nameservers.
  domain:
    name: api.fincorp.com

  # (Optional) Secure your ingress with Identity-Aware Proxy (IAP).
  # This block defines who is allowed to access the applications behind this ingress.
  # If omitted, the ingress will be open to the public internet.
  iapPermissions:
    groups:
      - "fincorp-employees@fincorp.com"

Step 3: Create a Manifest for Your HTTP Route​

Now that you've defined the front door, you need to create a route that tells traffic where to go. Create a new YAML file for your route.

Step 4: Define Your HttpRoute manifest​

Open the new route file and add the following content. This manifest links a path on your ingress to your backend application.

apiVersion: lowops.manifests.v1
kind: HttpRoute
metadata:
  name: payment-api-route
  # This links the route to the ingress by name:
  public-ingress: api-gateway 
  project: payment-gateway
  environment: production
  organizational-unit: retail-banking
  organization: fincorp
spec:
  rules:
    - matches:
        # This rule matches requests to "api.fincorp.com/v1/payments/*"
        - prefixMatch: /v1/payments
      action:
        destinations:
          # The application to send the traffic to.
          # This must match the name of an existing Application manifest.
          - deploymentConfig: payment-processing-api
            port: 8080

Step 5: Commit, Review, and Merge​

Commit the changes for both new manifest files in a single pull request. After your PR is reviewed and approved, merge it. The platform will automatically provision the new public load balancer and configure the routing rule.

Step 6: Delegate Your Domain (Manual Step)​

This is the final, manual step to make your domain live. When you set spec.domain.name, Infrastream provisions a dedicated Cloud DNS managed zone for that domain — it does not reuse your existing DNS provider's zone. Traffic routing and certificate issuance both depend on that new zone being authoritative for the domain, which means an A record at your old provider is not sufficient: you must delegate the domain to Infrastream's zone.

  1. Find the Name Servers: After your PR is merged, the Infrastream Engine provisions the managed zone and outputs its assigned name servers. You can find these in the computed block of the PublicIngress manifest in the Git repository after the run completes.

  2. Update Your Registrar's NS Records: Go to your domain registrar (e.g., GoDaddy, Namecheap, Cloudflare Registrar) and point the domain's NS records at the name servers from Step 1, replacing whatever name servers it currently delegates to.

    • Type: NS
    • Value: The name servers listed in the PublicIngress manifest's computed output (typically four ns-cloud-*.googledomains.com records).

Until delegation completes, the platform cannot validate ownership of the domain, so the managed TLS certificate will remain stuck pending issuance. After the NS change propagates (which can take a few minutes to 48 hours depending on your registrar), your application will be accessible at your custom domain over HTTPS.