Private Actions Overview

このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、お気軽にご連絡ください
このページは日本語には対応しておりません。随時翻訳に取り組んでいます。
翻訳に関してご質問やご意見ございましたら、お気軽にご連絡ください
Join the Preview!

Private Actions are in Preview. Use this form to request access today.

Request Access

Private actions allow your Datadog workflows and apps to interact with services hosted on your private network without exposing them to the public internet. To use private actions, you must install a private action runner on a host in your network using Docker or Kubernetes and pair the runner with a connection.

When you first start the runner, it generates a private key for authentication with Datadog’s servers. This private key is never accessible by Datadog and ensures you exclusive access. Datadog uses a public key derived from the private key as the means to authenticate specific runners.

Modes

A private action runner can be used with App Builder, Workflow Automation, or both.

The following is a general overview diagram for private actions:

Overview diagram illustrating how Private actions interact with Datadog and the user's browser

Mode differences

The following table explains some distinctions between App Builder and Workflows modes, including their triggering mechanisms and operational models.

DistinctionApp Builder modeWorkflows mode
Trigger
mechanism
Human-driven - each action is initiated by user interaction with an AppCan run automatically without direct human intervention
Trigger
model
Push model - actions are triggered by directly accessing a URL on the runnerPull model - periodically checks for tasks to execute
Data
handling
Keeps data in your private environment and does not send it to DatadogReports the result of private action executions to Datadog

The difference in models can result in varying latencies. App Builder mode’s push model might lead to more immediate responses, whereas the pull model in Workflows mode might introduce delays based on polling frequency.

App Builder mode

When your private action runner is in App Builder mode, queries that call your private services are sent directly from the user’s browser to the private action runner, which proxies requests to your services. At no point does your data enter Datadog when the runner is in App Builder mode; it communicates with Datadog only for enrollment and authentication purposes.

In the following diagram, App Management refers to backend App Builder actions that are unrelated to the Private Action runner, such as deleting an app.

Overview diagram illustrating how Private actions work in App Builder mode, including authentication

Authentication

To ensure secure communication, the Datadog frontend sends a single-use scoped token with each request, which the runner validates using a private key. This mechanism ensures that your data remains within your network and does not enter Datadog while maintaining the integrity and security of your private actions.

Runner hostname

In App Builder mode, the user’s browser talks directly to your private action runner. As a result, you must specify a custom domain name that points to your runner. To set up your domain, point an A or CNAME record to your network’s ingress. Your ingress must be capable of terminating HTTPS requests and forwarding them to the runner container on port 9016. The domain and ingress do not have to be accessible to the public internet; the A or CNAME record can point, for example, to a load balancer that is only accessible through your company’s VPN.

Workflow Automation mode

If your private action runner runs in Workflows-only mode, you do not need to perform any setup beyond the initial enrollment. The private action runner continuously polls for tasks from your Datadog account, executes them by interacting with your internal service, and reports the result back to Datadog.

Overview diagram illustrating how Private actions work in Workflow Automation mode

Both

When you select the option to use both modes, the runner dynamically adjusts the mode it uses based on the type of request it receives. This ensures smooth operation whether the runner is handling app requests, Workflow Automation executions, or a combination of both.

Further reading