Configuring Domains for Services Workflows Services workflows run on our platform can be assigned custom domain names through a configuration setting in your ops.yml file and a CNAME record on your domain’s nameserver. This feature allows you to configure persistent domains for previewing builds from your Pipelines workflows or accessing internal applications you deploy directly to the platform.

Associate a Domain with Your Service

For your Services workflow to accept traffic targeted at a given domain, that domain name must be specified in the ops.yml configuration file for the workflow. Under the configuration for a service in your ops.yml file, add a domain key where the value is the domain you wish to use to access your service.

In the above example, setting the value of the domain key to indicates to the platform that any requests received for that domain should be directed to the Service you have associated with it.

Direct Traffic to Our Platform

After a Services workflow has been configured to accept traffic for a specific domain, you must then direct the domain’s traffic at the platform. This is done by creating a CNAME record for your domain name that points traffic to our ingress domain: Instructions for configuring a CNAME record (or, alternatively, an ALIAS record) for your domain should be available from your DNS provider.

Below is a BIND-format Zone File showing you how might configure your domains to point at the platform:

In the example Zone File shown above, you can see that both the base domain name (represented by the @ symbol) and the subdomain have been pointed to This is accomplished by the two CNAME lines in the file:

This sets the canonical name (CNAME) as for traffic that is directed to or Then, if you make an HTTP request to either of those domains while your Service is running, the following occurs:

  1. Your web browser (or other client) resolves the canonical name of your URL, then retrieves the IP address of our ingress host from the A record (this is the purpose of CNAME records in general).
  2. Traffic from the local host is directed to our ingress host over the internet.
  3. Our ingress host routes the traffic addressed to your custom domain to the Service you have associated with that domain via the Service’s ops.yml configuration.

Secure Your Traffic in Transit

Traffic between your existing Service and its users can be secured by configuring an SSL/TLS certificate for your domain, which will enable communicating with your Service via HTTPS. You can add an SSL/TLS certificate to your Service using the ops certs command of our CLI.

Running the following example command will associate the certificate file demo.pem with the Services workflow configured in the local ops.yml file:

The CLI will prompt you for any required values that are missing from the command, then associate the specified SSL/TLS certificate with your Services workflow.

Finally, publish and restart your Service to begin securing its traffic with HTTPS.

Certificate Changes Requires Restart
After adding a certificate to an existing Service that lacks an SSL/TLS certificate or after updating an existing certificate, you will need to publish and restart your Service to begin using the new certificate.