• Beta
How to Configure ops.yml & Dockerfile
  • 17 Feb 2021
  • 6 Minutes To Read
  • Share
  • Dark

How to Configure ops.yml & Dockerfile

  • Share
  • Dark

Configuring Workflows

There are two main files that you can configure in workflows: the ops.yml and the Dockerfile. If you deploy your app to CTO.ai, you will be provided a pre-configured ops.yml and Dockerfile. However, you can also manually configure them for Commands, Pipelines and Services.


The ops.yml file structures how your work will run and provides information for how other users will be able to interact with it.

The run line of the YAML is the entry point command that is run as the final step of the Dockerfile to trigger your workflow. In general, this is the only difference in the YAML file between workflows made for different languages.

The example template shown below is an ops.yml created by ops init for a Service. There are a number of different flags you can specify in this file, as described in the ops.yml settings section below. A similar ops.yml file will be generated for Commands and Pipelines. For details on Pipeline-specific configuration, please review our Pipeline doc.

version: "1"
  - name: Apptest2:0.1.0
    description: my app description
    run: "node /ops/index.js"
    port: [ '8080:8080' ] ## Port only required for Services
    domain: ""
        - DB_PORT=5050
        - config_name
        - secret_name 
    events: "github:cto-ai-github/node-service-test:push:ref==master"
     - build
     - publish
     - start

If any of the ops.yml flags are left blank, the flag will use the default value. To see a complete set of flags in the ops.yml, you can see the example below.

Environment variables

As shown above, the ops.yml file also includes an env property that allows you to provide required environment variables for workflows from our Config and Secrets features. You can set both secrets and configs from either the CLI or our WebUI.


You must specify your secret or config in your ops.yml to be able to use it.

In the environment variable property, you can specify secrets and configs.
These environment variables are automatically pulled from the respective storage by name.
For example, if you were to store the password for your database in a Secrets value called DB-PASS. Then, when you use that variable under secrets in env it will automatically pull in your database password to be used where needed (see yml above for this usage).


If you specify a secret or config that does not already exist in your secret/config store, it will produce a blank value.

Once you have set secrets & configs on CTO.ai and in your ops.yml, you can treat them as any other variable in your code. You can follow a more detailed guide in the Secrets & Configs as Environment Variables docs.


Environmental variable names cannot start with a number.

Static Variables

It is also possible to set static variables in the ops.yml. These environment variables do not need to be hosted in your secret or config store. In the example above you will see we've set both variables KEY and DB_PORT to specific values.

Fetching Environment Variables in code

You can also fetch environment variables in code. You can use the sdk.getSecret() function. You can find a node example of secrets and configs in the Node SDK documentation.


Different types of workflows have their own unique ops.yml characteristics. You can find out more in the specific documentation for Pipelines and Services.


The Dockerfile provides the build instructions to include all of the files and software packages necessary to run the workflow. This sample Dockerfile was created with ops init for a JavaScript Service.

# Final container
FROM registry.cto.ai/official_images/node:2-12.13.1-stretch-slim


ADD package.json .
RUN npm install

ADD . .

Container File Permission Consideration

Following security best practices and to ensure no malicious processes are executed within the Pipeline, Service, or Command, the Workflow containers are run in non-privileged mode (with non-root user). To be more specific, the containers run with user and group set to 9999.

This means that running specific commands or attempting to execute actions that require root privileges post-build (as part of the container running) will not work as expected unless the right configuration is done as part of the Dockerfile. For writing files, we recommend using the /home/ops or /tmp directories, as those are set up by default as writeable. Additionally, if your workflow requires write access to a specific directory beyond the default ones, set the ownership of that location to user 9999 by adding additional arguments --chown=9999 to the ADD or COPY commands in the Dockerfile. Alternatively, you can RUN a chmod o+w command on the files/directories that you want writeable.

Docker Technical Info

  • registry.cto.ai/official_images/base:2-stretch-slim, adds the needed SDK binaries in /bin to the base Debian image.
  • registry.cto.ai/official_images/node:2-12.13.1-stretch-slim, has Node.js included on top of what is provided by the base image. Currently, this includes version 12 of Node.js.
  • registry.cto.ai/official_images/python:2-3.7-buster-slim, has Python 3 included on top of what is provided by the base image.
  • registry.cto.ai/official_images/bash:2-buster-slim, has Bash included on top of what is provided by the base image.


Ops.yml Settings

CTO.ai has many standard and optional .yml settings that you can use to better leverage our platform. If a value is unspecified, it will be set to its default value.

Below is a list of different settings you can use in your ops.yml.

name (required)

The unique identifier for your workflow, followed by the version number.
name: workflowname:x.xx

run (required)

The command that executes when a workflow is started.
run: node /ops/index.js


Allows you to configure a domain for your Service. See Domains and CNAME on how to use this setting. This is only used in a Service ops.yml.
domain : "mydomain.com"


This is the port defined for your Service. This is only used in a Service ops.yml.
port : 8080


This sets environment variables that can be used in your App. You can set secrets, configs, or static env variables. See Environment Variables section above for more information.

        - config1
        - secret1
        - staticEnv1 = 8080


The events flag lets CTO.ai know the source of events and what specific event to list to trigger an operation.

ex. โ€œgithub:org_name/repo_name:push:ref==mainโ€


Event triggers let CTO.ai know what operation to take when an event occurs. This can be build, publish, or start.


Read the How to Use Events and Triggers for more information on how to leverage these in your workflow.


This is a text field that provides a brief description of the workflow visible to other users.


The platform version for the ops.yml syntax
The version of the Workflow is captured in the name: field.

Legacy Settings


It is a legacy setting that specifies whether a version of a workflow is visible in our Public Registry.

Vaules: false or true.
Default: public: false


It is a legacy setting that specifies if a workflow will be allowed to run remotely(true) or if the workflow can only be run locally(false).
default value: true
remote: true


It is a legacy setting that specifies the CTO.ai SDK version to use.
default value: 2.


It is a legacy setting for the Registry. It allows adding a link to a public Github repo or a markdown file. The README.md will be displayed on your workflow page in our Registry.

mountCwd(run local only)

A setting for testing a locally run Workflow only. If set to true, this will bind the host's current working directory to /cwd.
Default= false and will use working directory /ops.

mountHome(run local only)

A setting for testing a locally run Workflow only. If set to true this will bind the host's home directory to /root. The default value is false.

๐Ÿš€ What's next?

๐Ÿ“ž Need help? No problem!

Was This Article Helpful?