Beta feature

Install Postman Insights Agent as a DaemonSet

Install the Postman Insights Agent as a DaemonSet if you want to install it in multiple services at once, for example, across your entire organization by your DevOps or platform team.

Estimated time: 10-minute setup, 5-minute wait

This installation is a three-part process consisting of:

Installing the Insights Agent as a DaemonSet in a Kubernetes cluster.
Onboarding your service as environment variables.
Activating Repro Mode, to enable you to reproduce errors on real user data.

Requirements

Edit permissions for the Kubernetes deployment.
Postman Workspace Admin or Editor role.
Linux environment. The agent and the user’s service should be running in a Linux environment.
Insights project. See Get started with Postman Insights to learn more.

Install the agent in the Kubernetes cluster

To install the Insights agent as a DaemonSet in your Kubernetes cluster, do the following:

Download the postman-insights-agent-daemonset.yaml manifest file.

Apply the manifest file to your cluster by running the following command:

kubectl apply -f postman-insights-agent-daemonset.yaml

This sets up the following resources in your cluster:

Resource type	Resource
Namespace	`postman-insights-namespace`
Service Account	`postman-insights-service-account`
Cluster Role	`postman-insights-read-only-role`
Cluster Role Binding	`postman-insights-view-all-resources-binding`
DaemonSet	`postman-insights-agent`

Wait for all the pods assigned to the DaemonSet to start up. You can check the status of the DaemonSet by running the following command:
```
kubectl get daemonsets -n postman-insights-namespace postman-insights-agent
```
The number of desired and ready pods should be equal.

Onboard your service to Insights

To continue onboarding your service, you'll collect your project ID and API key and move on to adding the required environment variables to your Kubernetes deployment.

Get your project ID

Go to the Diagnostics tab to locate your project ID string, formatted as svc_xxxxxxxxxx. Keep it for the next steps.

Get your Postman API key

Get or create a new API key. For more information, see Generate and use Postman API keys. Keep the API key for the next steps.

Manage and store the API Key

You need to provide the API key as an environment variable to the containers. You can either add it directly in the deployment YAML file or use one of the following methods:

Kubernetes ConfigMap
Kubernetes Secrets
AWS Secrets Manager
HashiCorp Vault
Other secret management tools

When using these options, make sure the container has the necessary permissions to access the secret from your secrets manager and that the secret is accessible from within the container. The following examples show how to use Kubernetes ConfigMap and Secrets to store the API key.

Learn more about DaemonSet security considerations.

Add environment variables to your deployment

You can add environment variables by defining them directly or by using a ConfigMap. You will need to set the following two environment variables per service:

Environment variable	Description
`POSTMAN_INSIGHTS_PROJECT_ID`	Your Insights project ID from the Postman app.
`POSTMAN_INSIGHTS_API_KEY`	Your AWS Secret ARN of Postman API Key, which will be used to send traffic data from your service.

You can use these optional environment variables:

Environment variable	Description
`POSTMAN_INSIGHTS_DISABLE_REPRO_MODE`	Turn off Repro Mode for a specific service.
`POSTMAN_INSIGHTS_AGENT_RATE_LIMIT`	Service-specific rate limit. The Insights Agent drops traffic after reaching this limit.

Based on the following options, decide how to use Kubernetes ConfigMap and Secrets to store the API key.

Option 1: Define environment variables directly

To add an environment variable to a Kubernetes deployment from a config file, you typically define it in a YAML manifest under the env section of the container spec.

...
spec:
  ...
  template:
    ...
    spec:
      containers:
        - name: my-container
          image: my-image
          env:
            - name: POSTMAN_INSIGHTS_PROJECT_ID
              value: "svc_xxxxxxxxxx"
            - name: POSTMAN_INSIGHTS_API_KEY
              value: "PMAK_xxxxxxxxxx"
  ...
...

Option 2: Define environment variables using a ConfigMap

If you want to manage environment variables through a ConfigMap, do the following:

Define the ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: deployment-service-config
data:
  POSTMAN_INSIGHTS_PROJECT_ID: "svc_xxxxxxxxxx"
  POSTMAN_INSIGHTS_API_KEY: "PMAK_xxxxxxxx"

Reference the ConfigMap in the deployment:

...
spec:
  ...
  template:
    ...
    spec:
      containers:
        - name: deployment-service
          image: deployment-service-image
          envFrom:
            - configMapRef:
                name: deployment-service-config
  ...
...

This imports all key-value pairs from the deployment-service-config as environment variables into the container.

Option 3: Define environment variables using both ConfigMap and Secrets

If you want to store the API Key in secrets (for security concerns) and the Service ID in Config Map, do the following:

Define the ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: deployment-service-config
data:
  POSTMAN_INSIGHTS_PROJECT_ID: "svc_xxxxxxxxxx"

Define the secret:

Encode your API key.

echo -n "<your_api_key>" | base64
# Output: UE1BSy1hc2RmZ2hqa2wtcXdlcnR5dTU0MzIx

Create secret.yaml.

apiVersion: v1
kind: Secret
metadata:
  name: deployment-service-secret
type: Opaque
data:
  POSTMAN_INSIGHTS_API_KEY: "encoded API key"

Reference both ConfigMap and Secret in the deployment:

...
spec:
  ...
  template:
    ...
    spec:
      containers:
        - name: deployment-service
          image: deployment-service-image
          envFrom:
            - configMapRef:
                name: deployment-service-config
            - secretRef:
                name: deployment-service-secret
  ...
...

After you add the environment variables, the deployment restarts, and new pods are created. The Insights Agent, running as a DaemonSet, begins monitoring traffic from your services.

Tip: If you're not seeing your endpoints right away, traffic may be taking some time to collect. See the next section for more information.

Wait for the Insights Agent to collect traffic

After Insights detects traffic from the Insights Agent, you'll get automatically redirected to the Overview page. The Insights Agent needs 5-8 minutes to use AI to generate endpoints.

If you're only seeing health checks, your traffic may be affected. If you're not seeing what you expect after 10 minutes, see Diagnose and troubleshoot Insights Agent errors.

Activate Repro Mode

In a DaemonSet setup, agent-level Repro Mode can be controlled both at the DaemonSet level and at the individual service level. For Repro Mode to work for a service, you need to enable it at both the agent and service levels.

To make it possible to make API calls using real user data, you need to activate Repro Mode. Go to your Insights project and select Settings. Then, toggle on Activate Repro Mode.

Only a Workspace Admin can enable the Repro Mode.

Default data redactions. Postman Insights automatically redacts a set of sensitive values including authentication tokens. See the full list. You can also add fields to redact ahead of turning on the feature.

Uninstall the Insights Agent

To remove the Insights Agent:

Either delete all the created resources manually, or run the following command to delete the manifest file you downloaded:
```
kubectl delete -f postman-insights-agent-daemonset.yaml
```
Remove the environment variables added in the service configs.

Last modified: 2025/05/30