Monaco resources

• Latest Dynatrace
• Reference
• 7-min read
• Updated on Jun 16, 2026

To run Monaco, you need to define the deployment manifest, project directories, and resource configuration so that you can manage the resources.

Deployment manifest

The deployment manifest file has three top-level keys: manifestVersion, projects, and environmentGroups.

Sample manifest.yaml

An example of a manifest.yaml:

manifestVersion: 1.0

projects:
- name: infra
  path: shared/infrastructure
- name: general
  path: general
  type: grouping

environmentGroups:
- name: dev
  environments:
  - name: test-env-1
    url:
      value: https://<YOUR-DT-DEV-ENV-ID>.apps.dynatrace.com
    auth:
      token:
         name: DEV_TOKEN
      oAuth:
        clientId:
          name: DEV_CLIENT_ID
        clientSecret:
          name: DEV_CLIENT_SECRET
  - name: test-env-2
    url:
      value: https://<YOUR-DT-SPRINT-ENV-ID>.apps.dynatrace.com
    auth:
      token:
         name: SPRINT_TOKEN
      oAuth:
        clientId:
          name: SPRINT_CLIENT_ID
        clientSecret:
          name: SPRINT_CLIENT_SECRET
- name: prod
  environments:
  - name: prod-env-1
    url:
      type: environment
      value: https://<YOUR-DT-PROD-ENV-ID>.apps.dynatrace.com
    auth:
      token:
         name: PROD_TOKEN
      oAuth:
        clientId:
          name: PROD_CLIENT_ID
        clientSecret:
          name: PROD_CLIENT_SECRET

manifestVersion

A manifest must contain a manifestVersion as a top-level key. This is a simple string that is used to validate if the currently used version of Monaco can correctly parse the manifest.

Currently, the supported manifest version is 1.0. The release notes will contain details if the manifest is extended, of if newer versions are released.

Projects

All entries under projects specify the projects to deploy by Monaco.

To specify a project's:

Give these keys a value.

There are two project types: simple and grouping.

For more details, see Manage a Monaco project.

simple projects (default type)

A simple project represents the default type and is defined by two properties:

grouping projects

A grouping project loads all subfolders of a given path as simple projects. A grouping project offers a simplified way of grouping multiple projects together.

environmentGroups

An environment is a Dynatrace environment. You can group these environments together in single environment group using the environmentGroups type. You can apply a configuration to an environmentGroup, which implicitly applies it to all environments within the group. Grouping pre-production and production environments can be helpful, as shown in the initial manifest.yaml example above.

Environment definition

An environment type consists of name, url, and auth sections.

The auth section supports the following authentication methods:

You can define a token together with either a platformToken or an oAuth client for the same environment, but you can't define both platformToken and oAuth.

The following examples show how to reference each authentication method. In each case, the name value is the name of the environment variable that holds the secret, not the secret itself.

auth:
  token:
    name: ACCESS_TOKEN

auth:
  oAuth:
    clientId:
      name: OAUTH_CLIENT_ID
    clientSecret:
      name: OAUTH_CLIENT_SECRET

auth:
  platformToken:
    name: PLATFORM_TOKEN

Access token authentication

Access tokens for the Dynatrace Monaco CLI always require at least the Access problem and event feed, metrics, and topology (DataExport)—API v1 permission to query general information about your environment.

In most cases, you need an access token with at least these permissions:

Each available configuration type requires specific permissions. For details, see Monaco API support and access permission handling.

For general information on access token authentication, see Dynatrace API - Tokens and authentication.

Platform authentication

To access a Dynatrace Platform environment, a platform token or an OAuth client is required.

Each available type of platform configuration requires specific scopes. For details, see Monaco API support and access permission handling.

Generally, platform tokens and OAuth clients for the Dynatrace Monaco CLI should have at least these scopes:

To create a platform token or an OAuth client for the Dynatrace Monaco CLI, see Create a platform token for the Dynatrace Monaco CLI and Create an OAuth client for the Dynatrace Monaco CLI.

Configuration files

The configuration files consist of:

The configuration YAML file contains basic information about the configuration to deploy. This includes the configuration name, the location of the template file, and the parameters available in the template file. Parameters can be overwritten based on the currently deployed group or environment.

The JSON template file contains the payload that will be uploaded to the Dynatrace API endpoints. It allows you to reference all defined configuration parameters via {{ .PARAMETER_NAME }} syntax.

configs:

- id: newCpuUsageSLO
  config:
    parameters:
      target: 95
      title: myNewSLO
      entityScope: HOST-#######
    template: slo-cpu-usage.json
    skip: false
  type: slo-v2

{
  "name": "{{ .title }}",
  "description": "test SLO for template test",
  "tags": [],
  "customSli": {
    "filterSegments": [],
    "indicator": "timeseries sli=avg(dt.host.cpu.usage)\n, by: { \"{{ .entityScope }}\" } \n  , filter: in(dt.entity.host, { $hosts })\n  | fieldsAdd entityName(dt.entity.host)"
  },
  "criteria": [
    {
      "target": {{ .target }},
      "timeframeFrom": "now-7d",
      "timeframeTo": "now",
      "warning": 99
    }
  ]
}

Important additional information for creating new templates

The JSON files that can be uploaded with Monaco are the JSON objects that the respective Dynatrace APIs accept/return. Adding a new configuration is generally done via the Dynatrace UI unless you know the configuration JSON structures well enough to prefer writing them. You can download the configurations via the respective GET endpoint defined in the Dynatrace Configuration API, and they should be cleaned up for auto-deployment.

Deletefile

A deletefile is a YAML document that lists the configurations that are to be deleted by the delete command. By default, this file is named delete.yaml.

You can manually create a delete file, or generate it with monaco generate deletefile.

Within the file, each entry can reference a configuration directly via its Dynatrace object ID, or indirectly via coordinates.

File structure for direct reference

To reference directly, define the following parameters:

An example structure is shown in the code block below.

delete:
- type: slo-v2
  objectId: origin-object-ID # ID of the configuration from Dynatrace
- [other entries...]

File structure for indirect reference

The structure of the delete.yml file depends on the configuration type, whether

# delete.yml file for Classic Dynatrace API
delete:
- name: my-mz # name of the configuration
  type: management-zone
- [other entries ...]

# delete.yml file for Settings 2.0 and Platform APIs
delete:
- project: my-project
  type:    workflow
  id:      my-workflow
- [other entries ...]

Schema files

Monaco can generate JSON-format schema files for many of Monaco's YAML files, including manifest, configuration, and delete files. For more information about generation, see Generate.

These schema files can be integrated with most common IDEs and advanced editors directly or by using free plugins.

In Visual Studio Code, for example, you can use the YAML extension (YAML Language Support by Red Hat) to associate a specific schema file with the Monaco files.

We recommend modifying your settings.json file with the following contents (replace the <path> placeholder with the appropriate path):

"yaml.schemas": {
"file:///<path-to-your-schema-folder>/monaco-config.schema.json": "**/*config*.yaml",
"file:///<path-to-your-schema-folder>/monaco-manifest.schema.json": "**/*manifest*.yaml",
"file:///<path-to-your-schema-folder>/monaco-delete-file.schema.json": "**/*delete*.yaml"
}