# Pipekit Agent Configuration

When using a self-hosted Pipekit installation, the Pipekit Agent requires additional configuration to communicate with your Pipekit services instead of the SaaS cloud service.

The Pipekit Agent connects clusters running Argo Workflows to your Pipekit installation. For detailed installation instructions, refer to the [main Pipekit Agent documentation](https://docs.pipekit.io/pipekit-agent/helm-chart).

## Required Configuration for Self-Hosted Pipekit

When installing the Pipekit Agent, you **must** configure two additional parameters to point to your self-hosted Pipekit installation:

* `configMap.messengerBaseUri`: Points to the Pipekit Messenger service
* `configMap.usersBaseUri`: Points to the Pipekit Users service

## Deployment Scenarios

### Remote Cluster (Recommended)

In large-scale installations, it is recommended to run the Pipekit Agent on a different cluster from your Pipekit installation to isolate the effects of your workflows from the Pipekit installation.

When the Pipekit Agent runs on a different cluster from your Pipekit installation, use your external ingress URLs:

```yaml
configMap:
  messengerBaseUri: "https://pipekit.example.com"
  usersBaseUri: "https://pipekit.example.com"
```

This configuration uses your external Pipekit domain and routes through your ingress controller using HTTPS for secure external communication.

### Same Cluster as Pipekit Control Plane

Some load balancers may not support hair-pinning, so it is recommended to use internal cluster DNS to avoid this.

To use internal cluster DNS, use something like the following configuration:

```yaml
configMap:
  messengerBaseUri: "http://messenger.pipekit.svc.cluster.local:8080"
  usersBaseUri: "http://users.pipekit.svc.cluster.local:8080"
```

This configuration uses internal Kubernetes service DNS (`svc.cluster.local`) to avoid network hair-pinning issues and provides the most reliable connectivity. This uses HTTP, but the traffic is lower-risk as it remains within your cluster network