Resolve Satellite - ResolveAI

The Resolve Satellite is a lightweight agent that runs within your infrastructure, securely proxying queries to your observability systems and streaming results back to ResolveAI through encrypted channels while keeping credentials behind your firewall.

This guide covers Kubernetes-based Satellite deployments. For deploying on AWS ECS Fargate, see Satellite on ECS.

1. Core Capabilities

Understanding Your Infrastructure

The Satellite continuously monitors your Kubernetes cluster through the API server, building a comprehensive model of your infrastructure. It tracks pods, services, deployments, jobs, and more across your configured namespaces. The Satellite operates in a truly read-only mode with zero impact on your API servers.

Discovering Service Dependencies in Real Time

Traditional service dependency mapping requires instrumentation, APM agents, or manual configuration. The Resolve Satellite takes a different approach with visibility into how your services interact, enabling ResolveAI to understand dependencies without requiring changes to your application code.

Connecting On-Premises Observability Tools

The Resolve Satellite acts as a secure local proxy that enables ResolveAI to query your local observability systems and stream results back through encrypted channels. Your credentials remain entirely within your infrastructure, and sensitive data can be redacted before transmission. The Satellite supports a comprehensive range of integration types.

Scaling to Meet Your Needs

The Satellite’s architecture supports both vertical and horizontal scaling to handle environments of any size. For most deployments, a single Satellite is sufficient. Replicas don’t need to coordinate, and when you need additional capacity for very large clusters or high integration query volumes, scaling horizontally is straightforward. Load balancing across replicas is managed automatically by Resolve’s backend. Multiple replicas also provide high availability, allowing you to perform rolling upgrades without disrupting Resolve’s ability to investigate incidents.

2. Deployment & Upgrades

Getting the Resolve Satellite running in your environment takes just a few steps. You’ll generate an ingest token, configure your values file, install the Helm chart, and verify connectivity.

Prerequisites

Before installing the Satellite, ensure you have Kubernetes cluster access with kubectl, Helm 3.x installed, and admin access to ResolveAI to generate ingest tokens.

Install the Resolve Satellite

The installation process configures the Satellite to connect securely to Resolve’s backend and begin a connection from your Kubernetes cluster.

1. Create Ingest Token

The Satellite communicates with the Resolve backend over an authenticated, encrypted channel. Authentication is handled via an ingest token you generate in the Resolve UI. As an admin in ResolveAI, open the Ingest Tokens page. Click Create Ingest Token, name it descriptively (e.g., “production-main-cluster”), click Create ingest token, and copy the token immediately. You will need it in the next step.

2. Configure Your Ingest Token

You’ll need to create a resolve-values.yaml file with your configuration. Before proceeding, choose how you want to handle the ingest token based on your environment. Production/Secure Setup (Recommended) For production environments, configure secure token storage using Kubernetes secrets or external secrets managers. Continue to Secret Management to set up secure token storage, then return here for Step 3. The Secret Management guide will walk you through storing tokens in Kubernetes secrets with an encrypted etcd and integrating with external secrets managers like AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault. Quick Test Setup (Development Only) For quick local testing, you can store the token directly in your values file. This method provides no additional security and should only be used temporarily. Required Values:

ingest.token: The token created in Step 1
clusterName: Global identifier for the satellite (e.g., prod-main)
environment: e.g., production, staging, qa. Match this environment name exactly with each integration you set up (e.g., Datadog).

resolve-values.yaml

ingest:
  token: <your resolve satellite token>

clusterName: <your cluster name>
environment: <your environment>

3. Install Helm Chart

Use this command to install the Helm Chart from Docker Hub:

helm install resolve-satellite \
  oci://registry-1.docker.io/resolveaihq/satellite-chart \
  --values resolve-values.yaml

If installation is rejected due to missing labelsSome Kubernetes clusters use admission controllers or policies that require specific labels on pods before they can be deployed. If your installation fails with a message about missing labels, add the labels required by your cluster policies to your resolve-values.yaml:

podLabels:
  team: your-team-name
  # Add any other labels required by your cluster policies

Alternative: Install via CDK8s

If you’re using CDK8s (Cloud Development Kit for Kubernetes) to manage your Kubernetes deployments, you can deploy the Satellite using a CDK8s Helm chart construct instead of running Helm commands directly.

The example below uses TypeScript and is for the latest version of CDK8s. Syntax may vary depending on your programming language (Python, Java, Go, etc.) and CDK8s version. Refer to the CDK8s documentation for language-specific examples.

Example CDK8s TypeScript code:

import { App, Chart } from 'cdk8s';
import { Helm } from 'cdk8s';

const app = new App();
const chart = new Chart(app, 'satellite');

new Helm(chart, 'resolve-satellite', {
  chart: 'oci://registry-1.docker.io/resolveaihq/satellite-chart',
  namespace: 'resolve',              // Specify namespace here
  createNamespace: true,             // Create if doesn't exist
  releaseName: 'resolve-satellite',
  values: {
    ingest: {
      tokenSecretName: 'satellite-token',
    },
    clusterName: 'prod-cluster',
    environment: 'production',
  },
});

app.synth();

This approach generates the Kubernetes YAML manifests from your CDK8s code. You cannot directly edit YAML files or run Helm commands when using CDK8s - all configuration must be specified in the CDK8s chart definition.

4. Check Permissions

The Resolve Satellite reads from the Kubernetes API with a ClusterRole. Verify the permissions granted:

Describe permissions

kubectl describe clusterrole resolve-satellite

Core Resources: ConfigMaps, Events, Namespaces, Nodes, Pods, Services
Workload Controllers: DaemonSets, Deployments, ReplicaSets, StatefulSets
CRDs: ArgoRollout, istioVirtualService, istioGateway

5. Verify Connection

In the Resolve UI, check Kubernetes Integrations to verify that the satellite is connected.

Next: Enable DNS Tap

Now that the Resolve Satellite is installed, enable cross-application investigations with Resolve using DNS Tap.

Upgrading the Satellite

The Satellite supports rolling upgrades with zero downtime. When new versions are released, you can upgrade your deployment using Helm while maintaining connectivity to Resolve’s backend.

Since version 1.1.0, the Satellite uses StatefulSets instead of Deployments to enable PVC templates. This allows persistent storage for features like the Git integration, so repositories aren’t cloned from scratch on every pod restart.PVCs are disabled by default and upgrading to v1.1.0+ does not require any special consideration. See the Git integration documentation on configuring storage size and type.

Upgrade to Latest Version

To upgrade your Satellite to the latest version, use the Helm upgrade command. This pulls the latest Satellite image and applies any configuration changes from your values file.

helm upgrade resolve-satellite \
  oci://registry-1.docker.io/resolveaihq/satellite-chart \
  --values resolve-values.yaml

Upgrade to Specific Version

To upgrade to a specific version, specify the chart version in your command. View available versions at Docker Hub Helm Chart Tags.

helm upgrade resolve-satellite \
  oci://registry-1.docker.io/resolveaihq/satellite-chart \
  --version <chart-version> \
  --values resolve-values.yaml

Verify Upgrade

After upgrading, verify the Satellite is running the new version. Check the pod status and image version:

kubectl get pods -l app.kubernetes.io/name=satellite
kubectl describe pod resolve-satellite-0 | grep Image:

Check the Resolve UI Kubernetes Integrations page to confirm the Satellite is connected and healthy.

Rollback if Needed

If you encounter issues after upgrading, rollback to the previous version:

helm rollback resolve-satellite

3. Integrations

The Resolve Satellite connects ResolveAI to your on-premises observability stack. Each integration is configured in your resolve-values.yaml file with credentials stored in Kubernetes secrets. The Satellite automatically detects configuration changes through a built-in file watcher—no manual restarts required.

Configuration Approach

All integrations follow a consistent pattern:

Create a Kubernetes secret containing credentials (API tokens, passwords)
Reference the secret in your resolve-values.yaml file
Specify connection parameters (URLs, filters, options)
Deploy or upgrade your Satellite with the new configuration

Secret Management

For production environments, we strongly recommend using secure secret storage through Kubernetes Secrets with etcd encryption at rest or external secret managers like AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, and Google Secret Manager. For a complete guide on configuring secrets, see Secret Management.

Integration Scoping by Team

You can manage per-team enablement for Satellite-managed integrations from your Satellite Helm values file by adding an integrationScopes block to an integration. Use this when integration access should be controlled through Helm instead of the Resolve UI. Add integrationScopes as a sibling of connection, not inside it. Each key must be a Resolve team ID, visible in the team URL as /teams/<teamId>. Each entry currently supports enabled: true or enabled: false.

integrations:
  grafanaOnPrem:
    type: grafana
    create: true
    secretName: grafana-token
    connection:
      url: https://grafana.internal.company.com
      alertScrapingEnabled: true
    integrationScopes:
      <team-id-1>:
        enabled: true
      <team-id-2>:
        enabled: false

When integrationScopes is configured for an integration:

Helm manages that integration’s per-team enable/disable state.
Teams set to enabled: false cannot use the integration.
Teams set to enabled: true, and teams not listed, are enabled by default.
The Resolve UI locks the per-team enable/disable controls for that integration.
Team-specific connection overrides remain editable in the UI and are preserved across Satellite re-registration.

Because unlisted teams are enabled by default, list every team that should be disabled. To return scope management to the Resolve UI, remove the integrationScopes block from the integration and run helm upgrade; the UI will become editable again using the last stored scoped settings as its starting point.

Integration Examples

The Kubernetes integration is included by default. To customize namespace filtering, specify which namespaces to include in your connection configuration. For example, to limit scraping to production, staging, and monitoring namespaces, set namespaceIncludeList to a comma-separated string of namespace names.

integrations:
  kubernetesOnPrem:
    type: kubernetes
    create: true
    secretName: <your-kubernetes-secret>
    connection:
      namespaceIncludeList: "production,staging,monitoring"

On-Premises Observability Tools

Example configurations for common tools demonstrate the standard integration pattern. For Prometheus, enable service map construction from traces if desired:

integrations:
  prometheusOnPrem:
    type: prometheus
    create: true
    secretName: prometheus-token
    connection:
      url: https://prometheus.internal.company.com
      serviceMapEnabled: true

For Grafana, enable alert scraping to ingest alerts from Grafana’s AlertManager:

integrations:
  grafanaOnPrem:
    type: grafana
    create: true
    secretName: grafana-token
    connection:
      url: https://grafana.internal.company.com
      alertScrapingEnabled: true

For Elasticsearch, specify which indices to allow for log queries using an index pattern:

integrations:
  elasticsearchOnPrem:
    type: elasticsearch
    create: true
    secretName: elasticsearch-token
    connection:
      url: https://elasticsearch.internal.company.com
      indexAllowList:
        - application-logs-*
        - system-logs-*

For detailed configuration parameters for each integration type, including filters, multi-tenancy options, and advanced settings, see the Reference Schema.

Git Integration

The Git integration enables ResolveAI to access repositories for investigations. For a complete setup guide, see Git Integration.

4. Security Controls

The Resolve Satellite is designed with security as a foundational principle. This section covers the security features and controls available for hardening your deployment.

Encrypted Communication

All communication between the Satellite and Resolve’s backend is over HTTP/2.0 with encryption. These long-lived connections span 30+ minutes and use token authentication to verify every request.

Secret Storage & Management

All integration credentials (API tokens, passwords) are stored in Kubernetes secrets or within your secrets manager within your cluster. The Satellite mounts these secrets as files at /etc/secrets/<secret-name>/. Raw secret values never leave your infrastructure or transit to Resolve’s cloud. For production deployments, we recommend using Kubernetes secrets with etcd encryption at rest or integrating external secret managers like AWS Secrets Manager, HashiCorp Vault, and Azure Key Vault. Rotate credentials regularly using secret updates without Satellite downtime. For a complete guide, see Secret Management.

Configuration Immutability (Config Override)

The configOverride setting (default: false) controls whether Resolve’s SaaS platform can remotely modify integration configurations through the UI. When disabled (default), all configuration changes require Helm chart updates. This enforces GitOps workflows and change approval processes, ensuring configuration remains immutable and auditable. No remote configuration tampering is possible. When enabled, administrators can edit integration settings from the Resolve web interface. This is useful for rapid testing and development environments but not recommended for production. By defaulting to false, the Satellite enforces the principle of least privilege and configuration-as-code practices.

Satellite Config Override

Domain Allowlist

The domainAllowList setting restricts outbound API requests from the Satellite to specific integration domains. This prevents data exfiltration and unauthorized external API calls. The allowlist accepts an array of domain strings and supports wildcard patterns (e.g., *.example.com for subdomains). The Satellite validates all HTTP requests before execution and throws an error if the target domain is not allowed. An empty list permits all domains (default). Example for Grafana:

integrations:
  grafanaOnPrem:
    type: grafana
    create: true
    secretName: grafana-resolve-secret
    connection:
      url: https://yourteam.grafana.com
      domainAllowList:
        - yourteam.grafana.com
        - "*.yourcompany.com"

Audit Logging

Audit logging captures detailed information about every HTTP request made to external integrations for security, compliance, and debugging purposes. When enabled, audit logging records the request method, URL, request body, response status code, integration key, and success/failure status. All audit logs are tagged with "audit": true for filtering. Enable audit logging in your integration configuration:

integrations:
  kubernetesOnPrem:
    type: kubernetes
    create: true
    secretName: <your-kubernetes-secret>
    connection:
      enableAuditLogging: true

View audit logs in your Satellite pod:

kubectl logs statefulset/resolve-satellite --tail=100 | grep '"audit":true'

If running multiple replicas, this shows logs from one pod. Check others with kubectl logs resolve-satellite-1, etc. Audit logging provides a comprehensive audit trail for security investigations and compliance audits.

Sensitive Data Redaction

The Satellite supports configurable PII redaction for integrations that collect or process sensitive data. Specify JSON paths to redact in the integration configuration. The Satellite will mask values at those paths before transmitting data. Example for Datadog:

integrations:
  datadogOnPrem:
    type: datadog
    create: true
    secretName: datadog-credentials
    connection:
      site: datadoghq.com
      redactionConfig:
        enabled: true
        targetJsonPaths:
          - "$.tags.user_email"
          - "$.attributes.customer_name"

For a complete guide, see Sensitive Data Redaction.

HTTPS Certificate Configuration

For integrations behind custom certificate authorities or requiring mutual TLS, configure certificates in your integration settings. Certificate options include httpAgentCertificate (CA certificate for verifying the server), httpAgentClientCert (client certificate for mutual TLS), and httpAgentClientKey (client private key for mutual TLS). Certificates can be specified as raw content or file paths. Example for Splunk with mutual TLS:

splunkIntegration:
  secretDir: /etc/secrets/splunkIntegration
  create: true
  type: splunk
  connection:
    url: https://splunk.internal.company.com
  httpAgentCertificatePath: /certs/ca-cert.pem
  httpAgentClientCertPath: /certs/client-cert.pem
  httpAgentClientKeyPath: /certs/client-key.pem

Running as Non-Root User

For enhanced security, configure the satellite to run as a non-root user. Add the podSecurityContext and securityContext settings to your resolve-values.yaml file.

Where to add these settings: Both podSecurityContext and securityContext are top-level keys in your values file - they go at the same level as ingest, clusterName, and integrations, not nested inside any other key.

# Your existing configuration
ingest:
  token: <your resolve satellite token>

clusterName: <your cluster name>
environment: <your environment>

# Pod-level security context (applies to the entire pod)
# Controls user/group IDs and filesystem permissions
podSecurityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000

# Container-level security context (applies to the satellite container)
# Controls privilege escalation and Linux capabilities
securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

# Your integrations continue here...
integrations:
  # ...

What each setting does:

podSecurityContext (Pod level): Applies to all containers in the pod. Sets runAsNonRoot, runAsUser, runAsGroup, and fsGroup.
securityContext (Container level): Applies to the satellite container. Controls allowPrivilegeEscalation and capabilities.

The fsGroup setting ensures mounted volumes (including the Git integration data volume) are accessible to the non-root user.

Resolve Satellite Security Features

Config Override

The configOverride setting in the satellite resolve-values.yaml file (default: false) controls whether the Resolve SaaS platform can remotely modify the Satellite’s integration configurations through the UI. When enabled (set to true), administrators can edit integration settings from the Resolve web interface; when disabled, the edit config is not shown in the UI, ensuring that only the local Helm values file controls the satellite’s configuration. This is beneficial for security because it enforces the principle of least privilege and configuration-as-code practices - organizations can prevent unauthorized or accidental changes to critical infrastructure integrations by requiring all configuration changes to go through their standard GitOps workflows and approval processes rather than allowing real-time UI modifications. By defaulting to false in production deployments, the Satellite ensures that configuration remains immutable and auditable, with changes only possible through version-controlled Helm chart updates that can be reviewed, tested, and rolled back if needed.

Satellite Config Override

Domain Allowlist

domainAllowList is a security configuration for HTTP-based integrations running on the Satellite that restricts outbound API requests to specific domains. It accepts an array of domain strings with support for wildcard patterns (e.g., *.example.com for subdomains). When configured, the Satellite validates all HTTP request URLs against the list before execution, throwing an error if the target domain is not allowed. If the list is empty or undefined, all domains are permitted by default. Here is an example for Grafana:

integrations:
  grafanaOnPrem:
    type: grafana
    create: true
    secretName: "grafana-resolve-secret-name"
    connection:
      url: https://yourteam.grafana.com
      domainAllowList:
        - yourteam.grafana.com
        - "*.yourcompany.com"

Frequently Asked Questions

What are the resource requirements?

CPU: 1 Core
Memory: 8 GB
Storage: 1 GB (base) + additional for the Git integration (see storage configuration)

The satellite keeps most working data in memory. Storage is used for container images and temporary file sources, as well as code repositories cloned by the Git integration.

Where can I find the Satellite Helm chart and image?

What data sources does the Resolve Satellite use?

The Satellite relies on two primary sources, the Kubernetes API Server and DNS Tap.Kubernetes API Server:

Collects from: Pods, Services, Deployments, Jobs, ConfigMaps, Events, Nodes, PVCs, CRDs
Uses Watch API with caching and concurrency
Default interval: every 10 minutes (configurable)
Namespace concurrency: 10 threads (contact us to configure)
Scrapes customResourceDefinitions from Kubernetes:
- Ingest popular CRDs like ArgoRollout, IstioVirtualService, IstioGateway
- Ingest custom CRDs (contact us to configure)

DNS Tap:

Open source DNS log monitoring
Captures service-to-service DNS traffic (e.g., from CoreDNS)
Enables automatic runtime dependency discovery
Non-intrusive push model (no polling)

Does the Satellite write to the Kubernetes API server?

No. It is read-only and leverages the Kubernetes watch cache, minimizing impact on cluster performance.

How often does the Satellite collect data?

Kubernetes API reads occur every 5 minutes by default.
This interval is configurable (e.g., every 10 or 15 minutes depending on your needs).
- Note: you will need to get in touch with your ResolveAI contact to make this configuration change.
Namespace-level concurrency is also tunable (default: 10 concurrent read threads).

Does it work with our internal proxy?

If your proxy supports long-lived HTTP2.0 connections: The satellite communicates with the Resolve server using a bidirectional gRPC/HTTP2.0 streaming connection. These are long-lived connections spanning over 30 minutes. If the proxy supports long-lived HTTP2.0 streaming connections, then yes, satellites should be able to support it.Otherwise: Allowlist the static IP for the Resolve server so the satellite can communicate with it.

What IP addresses should I allowlist?

We have a CIDR block of IP addresses for the satellite to securely connect to the ResolveAI backend. Add this set of addresses to your allowlist, a /29 block of 8 IPs: 18.97.138.16/29.

How does the satellite communicate with the Resolve server?

The Resolve Satellite is a lightweight proxy that establishes a bidirectional gRPC/HTTP2.0 streaming connection with the Resolve server and executes HTTP requests to local on-prem integrations — both observability data sources and Kubernetes.

What is the performance impact?

The satellite periodically fetches data from Kubernetes and other on-prem integrations to update its Knowledge Graph, but this frequency is configurable and we ensure minimal load on your servers.Assuming that your typical cluster sizes are:

Namespaces: ~1000
Nodes: 400
Pods: 10,000

Here are some numbers that illustrate the load placed on your Kubernetes API server:

Polling interval is 10 minutes (configurable)
Each poll is sharded and fetches about 1-2MiB of data.
We further limit the concurrency of these shards to 10 (configurable) and it roughly approximates to ~25 requests per second.

There should not be any observable load or latency on your system.

How do I handle PII data?

Resolve supports Sensitive Data Redaction to handle PII.

What are the scaling and performance limits for an individual satellite, and when should we scale it up or out?

The satellite architecture supports horizontal scaling through multiple replicas, allowing it to handle very large loads by adjusting the replica count as needed. Load balancing for the satellites is managed on our backend, ensuring efficient distribution of data and operational control.

Can I configure the satellite to support integrating to multiple Kubernetes clusters?

Yes. One Satellite instance can connect to multiple Kubernetes clusters as long as the kubeconfig is supplied within the secret value.First, create a Kubernetes secret containing your kubeconfig.yaml file. The stringData field in a Kubernetes Secret enables you to provide secret values as plain text strings, which are then automatically base64-encoded and stored in the data field.Secret Definition Example:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: k8s-resolve
stringData:
  kubeconfig.yaml: |
    apiVersion: v1
    kind: Config
    clusters:
    - name: your-cluster
      cluster:
        server: https://your-cluster-api-server:6443
        certificate-authority-data: <base64-encoded-ca-cert>
    users:
    - name: your-user
      user:
        token: <your-service-account-token>
    contexts:
    - name: your-context
      context:
        cluster: your-cluster
        user: your-user
    current-context: your-context

Then, apply your secret:

kubectl apply -f k8s-resolve.yaml

Lastly, add this into your resolve-values.yaml file:

integrations:
  kubernetesIntegration:
    type: kubernetes
    create: true
    secretName: "k8s-resolve"
    connection:
      contextName: "your-context"         # Optional
      environment: "production"

How do I configure HTTPS certificates for an integration behind a satellite?

You can provide the httpAgentCertificate for authentication, along with the httpAgentClientCert and httpAgentClientKey if the endpoint requires mutual TLS. Each can be specified either as a raw certificate or as a file path.Example using file paths (Splunk):

splunkIntegration:
  secretDir: /etc/secrets/splunkIntegration
  create: true
  type: splunk
  connection:
    url: <your-splunk-url>
  httpAgentCertificatePath: <path-to-ca-cert>
  httpAgentClientCertPath: <path-to-client-cert>
  httpAgentClientKeyPath: <path-to-client-key>

Example using raw certificates (Splunk):

splunkIntegration:
  secretDir: /etc/secrets/splunkIntegration
  create: true
  type: splunk
  connection:
    url: <your-splunk-url>
  httpAgentCertificate: <ca-certificate-content>
  httpAgentClientCert: <client-certificate-content>
  httpAgentClientKey: <client-key-content>

​1. Core Capabilities

​Understanding Your Infrastructure

​Discovering Service Dependencies in Real Time

​Connecting On-Premises Observability Tools

​Scaling to Meet Your Needs

​2. Deployment & Upgrades

​Prerequisites

​Install the Resolve Satellite

​1. Create Ingest Token

​2. Configure Your Ingest Token

​3. Install Helm Chart

​4. Check Permissions

​5. Verify Connection

​Next: Enable DNS Tap

​Upgrading the Satellite

​Upgrade to Latest Version

​Upgrade to Specific Version

​Verify Upgrade

​Rollback if Needed

​3. Integrations

​Configuration Approach

​Secret Management

​Integration Scoping by Team

​Integration Examples

​On-Premises Observability Tools

​Git Integration

​4. Security Controls

​Encrypted Communication

​Secret Storage & Management

​Configuration Immutability (Config Override)

​Domain Allowlist

​Audit Logging

​Sensitive Data Redaction

​HTTPS Certificate Configuration

​Running as Non-Root User

​Resolve Satellite Security Features

​Config Override

​Domain Allowlist

​Frequently Asked Questions

1. Core Capabilities

Understanding Your Infrastructure

Discovering Service Dependencies in Real Time

Connecting On-Premises Observability Tools

Scaling to Meet Your Needs

2. Deployment & Upgrades

Prerequisites

Install the Resolve Satellite

1. Create Ingest Token

2. Configure Your Ingest Token

3. Install Helm Chart

4. Check Permissions

5. Verify Connection

Next: Enable DNS Tap

Upgrading the Satellite

Upgrade to Latest Version

Upgrade to Specific Version

Verify Upgrade

Rollback if Needed

3. Integrations

Configuration Approach

Secret Management

Integration Scoping by Team

Integration Examples

On-Premises Observability Tools

Git Integration

4. Security Controls

Encrypted Communication

Secret Storage & Management

Configuration Immutability (Config Override)

Domain Allowlist

Audit Logging

Sensitive Data Redaction

HTTPS Certificate Configuration

Running as Non-Root User

Resolve Satellite Security Features

Config Override

Domain Allowlist

Frequently Asked Questions