Configuring Domains for Services Workflows

CTO.ai 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 CTO.ai platform.

Associate a Domain with Your Service

For your CTO.ai 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.

version: "1"
services:
  - name: sample-app:0.4.9
    description: sample-app
    run: node /ops/index.js
    port: ["8080:8080"]
    domain: preview.example.com

In the above example, setting the value of the domain key to preview.example.com indicates to the CTO.ai 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 CTO.ai platform. This is done by creating a CNAME record for your domain name that points traffic to our ingress domain: in.cto.ai. 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 CTO.ai platform:

$ORIGIN example.com.
$TTL    86400
@       IN      SOA ns.example.com ( 2023080701 7200 3600 1209600 86400 )
@       IN      NS      ns.example.com.

@       IN      CNAME   in.cto.ai.
preview IN      CNAME   in.cto.ai.

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

@       IN      CNAME   in.cto.ai. ; directs the base domain `example.com.` to `in.cto.ai.`
preview IN      CNAME   in.cto.ai. ; directs `preview.example.com.` to `in.cto.ai.`

This sets the canonical name (CNAME) as in.cto.ai for traffic that is directed to example.com or preview.example.com. 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.

Save an SSL certificate and key for your service

USAGE
  $ ops certs CERTIFICATETYPE NAMEORPATH

ARGUMENTS
  CERTIFICATETYPE  (ssl) The type of certificate to store
  NAMEORPATH       Name or path of the service to save SSL for.

OPTIONS
  -h, --help             Show help screen
  --cert-file=cert-file  Path to your certificate file
  --key-file=key-file    Path to your key file

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

ops certs ssl ./ops.yml --cert-file=~/tmp/example_cert/demo.pem

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.