Multi-App Run template file

When you execute dapr run -f ., it starts the multi-app template file (named dapr.yaml) present in the current directory to run all the applications.

You can name template file with preferred name other than the default. For example dapr run -f ./<your-preferred-file-name>.yaml.

The following example includes some of the template properties you can customize for your applications. In the example, you can simultaneously launch 2 applications with app IDs of processor and emit-metrics.

version: 1
apps:
  - appID: processor
    appDirPath: ../apps/processor/
    appPort: 9081
    daprHTTPPort: 3510
    command: ["go","run", "app.go"]
  - appID: emit-metrics
    appDirPath: ../apps/emit-metrics/
    daprHTTPPort: 3511
    env:
      DAPR_HOST_ADD: localhost
    command: ["go","run", "app.go"]

For a more in-depth example and explanation of the template properties, see Multi-app template.

Locations for resources and configuration files

You have options on where to place your applications’ resources and configuration files when using Multi-App Run.

Point to one file location (with convention)

You can set all of your applications resources and configurations at the ~/.dapr root. This is helpful when all applications share the same resources path, like when testing on a local machine.

Separate file locations for each application (with convention)

When using Multi-App Run, each application directory can have a .dapr folder, which contains a config.yaml file and a resources directory. Otherwise, if the .dapr directory is not present within the app directory, the default ~/.dapr/resources/ and ~/.dapr/config.yaml locations are used.

If you decide to add a .dapr directory in each application directory, with a /resources directory and config.yaml file, you can specify different resources paths for each application. This approach remains within convention by using the default ~/.dapr.

Point to separate locations (custom)

You can also name each app directory’s .dapr directory something other than .dapr, such as, webapp, or backend. This helps if you’d like to be explicit about resource or application directory paths.

Logs

The run template provides two log destination fields for each application and its associated daprd process:

1. appLogDestination : This field configures the log destination for the application. The possible values are console, file and fileAndConsole. The default value is fileAndConsole where application logs are written to both console and to a file by default.

2. daprdLogDestination : This field configures the log destination for the daprd process. The possible values are console, file and fileAndConsole. The default value is file where the daprd logs are written to a file by default.

Log file format

Logs for application and daprd are captured in separate files. These log files are created automatically under .dapr/logs directory under each application directory (appDirPath in the template). These log file names follow the pattern seen below:

• <appID>_app_<timestamp>.log (file name format for app log)
• <appID>_daprd_<timestamp>.log (file name format for daprd log)

Even if you’ve decided to rename your resources folder to something other than .dapr, the log files are written only to the .dapr/logs folder (created in the application directory).

Watch the demo

Watch this video for an overview on Multi-App Run:

# the template file needs to be called `dapr.yaml` by default if a directory path is given

dapr stop -f <dir_path>

or:

dapr stop -f ./path/to/<your-preferred-file-name>.yaml

version: 1
common: # optional section for variables shared across apps
  resourcesPath: ./app/components # any dapr resources to be shared across apps
  env:  # any environment variable shared across apps
    DEBUG: true
apps:
  - appID: webapp # optional
    appDirPath: .dapr/webapp/ # REQUIRED
    resourcesPath: .dapr/resources # deprecated
    resourcesPaths: .dapr/resources # comma separated resources paths. (optional) can be left to default value by convention.
    appChannelAddress: 127.0.0.1 # network address where the app listens on. (optional) can be left to default value by convention.
    configFilePath: .dapr/config.yaml # (optional) can be default by convention too, ignore if file is not found.
    appProtocol: http
    appPort: 8080
    appHealthCheckPath: "/healthz"
    command: ["python3", "app.py"]
    appLogDestination: file # (optional), can be file, console or fileAndConsole. default is fileAndConsole.
    daprdLogDestination: file # (optional), can be file, console or fileAndConsole. default is file.
  - appID: backend # optional
    appDirPath: .dapr/backend/ # REQUIRED
    appProtocol: grpc
    appPort: 3000
    unixDomainSocket: "/tmp/test-socket"
    env:
      DEBUG: false
    command: ["./backend"]

The following rules apply for all the paths present in the template file:

• If the path is absolute, it is used as is.
• All relative paths under common section should be provided relative to the template file path.
• appDirPath under apps section should be provided relative to the template file path.
• All other relative paths under apps section should be provided relative to the appDirPath.

The properties for the Multi-App Run template align with the dapr run CLI flags, listed in the CLI reference documentation.

Next steps

Watch this video for an overview on Multi-App Run: