Multi-App Run overview
NoteMulti-App Run is currently a preview feature only supported in Linux/MacOS.
Let’s say you want to run several applications locally to test them together, similar to a production scenario. With a local Kubernetes cluster, you’d be able to do this with helm/deployment YAML files. You’d also have to build them as containers and set up Kubernetes, which can add some complexity.
Instead, you simply want to run them as local executables in self-hosted mode. However, self-hosted mode requires you to:
- Run multiple
- Keep track of all ports opened (you cannot have duplicate ports for different applications).
- Remember the resources folders and configuration files that each application refers to.
- Recall all of the additional flags you used to tweak the
dapr runcommand behavior (
With Multi-App Run, you can start multiple applications in self-hosted mode using a single
dapr run -f command using a template file. The template file describes how to start multiple applications as if you had run many separate CLI
runcommands. By default, this template file is called
Multi-App Run template file
When you execute
dapr run -f ., it uses 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
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/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
Point to separate locations (custom)
You can also name each app directory’s
.dapr directory something other than
.dapr, such as,
backend. This helps if you’d like to be explicit about resource or application directory paths.
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
<appID>_daprd_<timestamp>.log(file name format for
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:
- Learn the Multi-App Run template file structure and its properties
- Try out the Multi-App Run template with the Service Invocation quickstart
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.