Install the On-Prem Worker
BigPanda's L1 Agent On-Premises Worker is a lightweight containerized agent that runs on your infrastructure to execute runbook automation steps. It connects to BigPanda using mutual TLS (mTLS) authentication and executes pre-registered workflows on demand.
This guide covers a first install: download the image, configure it to route through your corporate HTTP CONNECT proxy, run it, and confirm it reaches a healthy state. Workflow-specific configuration is added in a follow-up step coordinated with BigPanda.
For architecture, security, and FAQs, see the On-Prem Worker parent page.
Multiple versions available
Two supported worker versions are available. If you are onboarding a new worker, use the current version. The previous version's guide remains available for customers already running it. Follow the instructions that match the version you are running or onboarding.
To check the version you are running:
docker images | grep adr-temporal-worker
Worker version | Status | Install guide |
|---|---|---|
v13.6.3 | Latest | |
<v13.6.3 | Supports existing deployments only, closed to new installs |
Pin to your version. Each guide is self-contained for that version. Cert filenames, environment variables, and proxy support changed between versions; follow only the guide matching your image tag.
v13.6.3
The worker ships as a Docker container image. BigPanda provides a presigned download URL during onboarding.
Install the worker
Before you start
Make sure you have the following ready:
Docker installed on the target host (Linux x86_64)
The mTLS certificate bundle from BigPanda (provided during onboarding): your client certificate (tls.crt), its private key (tls.key), and BigPanda's CA certificate (ca.crt).
A corporate HTTP CONNECT proxy allowlisted for CONNECT temporal.bigpanda.io:7233, with TLS inspection (SSL decryption) disabled for that destination. TLS-inspecting proxies break the mTLS chain. Major enterprise proxies (Zscaler, Palo Alto, Squid, Forcepoint, BlueCoat, Cloudflare Gateway) support per-destination decryption exclusions.
Outbound network access from the host to your proxy, and from the proxy to temporal.bigpanda.io:7233.
Deploy the worker with Docker
Download and load the image
BigPanda shares a presigned S3 URL (valid for 24 hours). Download the tarball:
curl -L '' -o adr-temporal-worker-v13.6.3.tar.gz
If your host reaches S3 through the corporate proxy, prefix with HTTPS_PROXY:
HTTPS_PROXY=http://: \ curl -L '' -o adr-temporal-worker-v13.6.3.tar.gz
Expected file size is approximately 143 MB (149,713,933 bytes). Verify, then load:
ls -la adr-temporal-worker-v13.6.3.tar.gz docker load -i adr-temporal-worker-v13.6.3.tar.gz
Expected output: Loaded image: adr-temporal-worker:latest. Confirm:
docker images | grep adr-temporal-worker
Install certificates
Place the three files BigPanda sent into a certs/ directory next to where you will create the .env file:
certs/ ├── tls.crt # Client certificate (identifies your organization) ├── tls.key # Client private key (keep secure, do not share) └── ca.crt # BigPanda CA certificate (validates the Temporal server)
Restrict permissions on the private key:
chmod 0400 certs/tls.key
Create a configuration file
Create .env in the same directory as certs/:
# --- Connection (provided by BigPanda) --- TEMPORAL_ADDRESS=temporal.bigpanda.io:7233 TEMPORAL_TLS_CERT_PATH=/certs/tls.crt TEMPORAL_TLS_KEY_PATH=/certs/tls.key TEMPORAL_TLS_CA_PATH=/certs/ca.crt # --- Corporate egress proxy (required — provided by your network team) --- # Format: http://[user:pass@]host:port (HTTP CONNECT only) TEMPORAL_PROXY_URL=http://: # With basic auth (URL-encode '@' as %40, ':' as %3A in user/pass): # TEMPORAL_PROXY_URL=http://:@: # --- HTTP integrations (provided by BigPanda during onboarding) --- # JSON array of the HTTP endpoints the worker may call. Each integration's # credentials are supplied via its own secret_env variable, set separately. ADR_HTTP_INTEGRATIONS=[ ... see Configuration reference ... ] # --- Operational (optional) --- LOG_LEVEL=info METRICS_PORT=8080
Run the worker
docker run -d \ --name adr-temporal-worker \ --restart unless-stopped \ --log-opt max-size=50m \ --log-opt max-file=3 \ -p 8080:8080 \ -v $(pwd)/certs:/certs:ro \ --env-file .env \ adr-temporal-worker:latest
Verify the deployment
Confirm the container is running:
docker ps | grep adr-temporal-worker
Check the logs. You should see, in approximately this order: Health server listening (port 8080), Worker started (taskQueue <org>-tasks), Worker state changed state: 'RUNNING', and Schedule registration complete. A Routing ... proxy line also appears when a proxy is configured.
docker logs adr-temporal-worker
Check the health endpoints from the host:
curl http://localhost:8080/health # Expected: {"status":"ok","startedAt":""}
curl http://localhost:8080/ready # Expected: {"status":"ready"}Both endpoints returning HTTP 200 means the worker is connected to BigPanda's Temporal through your proxy and is ready to receive work.
Container health checks. These curl commands are for manual verification from the host. The image includes node but not curl or wget, so automated container health checks use a node one-liner. See Container health check below.
Deploy the worker with Kubernetes
If you are deploying to Kubernetes, use the following manifests as a starting point.
Create certificates and the monitoring API key:
apiVersion: v1 kind: Secret metadata: name: adr-temporal-worker-secrets namespace: bigpanda type: Opaque stringData: DEVICE_API_KEY: "<your-monitoring-platform-api-key>" --- apiVersion: v1 kind: Secret metadata: name: adr-temporal-worker-certs namespace: bigpanda type: Opaque data: tls.crt: <base64-encoded-cert> tls.key: <base64-encoded-key> ca.cert: <base64-encoded-ca>
Create the deployment
apiVersion: apps/v1 kind: Deployment metadata: name: adr-temporal-worker namespace: bigpanda spec: replicas: 1 selector: matchLabels: app: adr-temporal-worker template: metadata: labels: app: adr-temporal-worker spec: containers: - name: worker image: adr-temporal-worker:latest ports: - containerPort: 8080 envFrom: - secretRef: name: adr-temporal-worker-secrets env: - name: TEMPORAL_ADDRESS value: "temporal.bigpanda.io:7233" - name: TEMPORAL_TLS_CERT_PATH value: "/certs/tls.crt" - name: TEMPORAL_TLS_KEY_PATH value: "/certs/tls.key" - name: TEMPORAL_TLS_CA_PATH value: "/certs/ca.cert" volumeMounts: - name: certs mountPath: /certs readOnly: true resources: requests: memory: "256Mi" cpu: "100m" limits: memory: "512Mi" cpu: "500m" livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 15 volumes: - name: certs secret: secretName: adr-temporal-worker-certs
Configuration reference
Connection
Variable | Description | Value |
|---|---|---|
TEMPORAL_ADDRESS | BigPanda Temporal Server address | temporal.bigpanda.io:7233 |
TEMPORAL_TLS_CERT_PATH | Path in the container to the client certificate | /certs/tls.crt |
TEMPORAL_TLS_KEY_PATH | Path in the container to the client private key | /certs/tls.key |
TEMPORAL_TLS_CA_PATH | Path in the container to the BigPanda CA certificate | /certs/ca.crt |
ADR_HTTP_INTEGRATIONS | JSON array of HTTP integrations the worker may call | See below |
ADR_HTTP_INTEGRATIONS
A JSON array with one object per HTTP endpoint the worker may reach. Per-entry fields: name (unique identifier), type (integration kind, for example grafana, datadog, jira), base_url, optional description, and auth.
Supported auth.type values: bearer (token in secret_env), basic (credentials in secret_env), and header (one or more headers, each backed by its own secret_env). Each secret_env names an environment variable holding the actual secret — define those alongside the worker's other env vars or inject them from your secret store. Never put raw tokens in ADR_HTTP_INTEGRATIONS itself.
ADR_HTTP_INTEGRATIONS=[
{
"name": "grafana-eu-1",
"type": "grafana",
"base_url": "https://grafana-eu.example.internal",
"description": "EU production Grafana",
"auth": { "type": "bearer", "secret_env": "GRAFANA_EU_1_TOKEN" }
},
{
"name": "datadog-eu",
"type": "datadog",
"base_url": "https://api.datadoghq.eu",
"auth": { "type": "header", "headers": [
{ "name": "DD-API-KEY", "secret_env": "DD_API_KEY" },
{ "name": "DD-APPLICATION-KEY", "secret_env": "DD_APP_KEY" }
] }
}
]Proxy
Proxy data should be provided by your network team.
Variable | Description | Example |
|---|---|---|
TEMPORAL_PROXY_URL | HTTP CONNECT proxy URL. Format http://[user:pass@]host:port. Only the http:// scheme is supported — the tunneled traffic is TLS-encrypted end-to-end, but the hop to the proxy is HTTP. | http://corpproxy.yourdomain.com:8080 |
The worker validates this URL at startup and exits immediately if: it is not a valid URL, the scheme is not http:, no port is included, a path component is present, only one of username/password is set, or the decoded username/password contains : or @.
Optional
Variable | Default | Description |
|---|---|---|
METRICS_PORT | 8080 | Port for the health and ready endpoints |
LOG_LEVEL | info | Log level (debug, info, warn, error) |
Health and monitoring endpoints
Endpoint | Response | Purpose |
|---|---|---|
GET /health | {"status":"ok","startedAt":"..."} | Returns 200 if the worker process is running |
GET /ready | {"status":"ready"} | Returns 200 if the worker has initialized |
Container health check
The image includes node but not curl or wget, so automated container health checks use a node one-liner (works in ECS, Docker, and Kubernetes exec probes):
node -e "require('http').get('http://localhost:8080/health',r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))"ECS: wrap it as the CMD (exec) array — use
CMD, notCMD-SHELL.Kubernetes: simplest is a native
httpGetprobe on path/healthport 8080.Give a generous startup window (ECS
startPeriod, K8sinitialDelaySeconds) — the health endpoint comes up only after the worker connects to Temporal.
Network requirements
Direction | Source | Destination | Port | Protocol | Purpose |
|---|---|---|---|---|---|
Outbound | Worker host | Corporate HTTP CONNECT proxy | (proxy port) | HTTP CONNECT | Establish tunnel to BigPanda Temporal |
Outbound | Corporate proxy | temporal.bigpanda.io | 7233 | gRPC + mTLS over the CONNECT tunnel | Temporal Server connection |
Inbound | — | — | — | — | None required |
No inbound ports need to be opened. The worker makes outbound connections only.
The connection to BigPanda's Temporal uses mutual TLS. The worker presents tls.crt to identify your organization and validates BigPanda's server certificate against ca.crt. For the corporate proxy in between to work, it must allow CONNECT temporal.bigpanda.io:7233 as a pass-through TCP tunnel and must not perform TLS interception for this destination. A TLS-inspecting proxy cannot present your client certificate, and the worker rejects its substituted server certificate.
Ask your proxy team to add temporal.bigpanda.io:7233 to the decryption exclusion list (also called SSL inspection bypass or splice rule).
Supported: HTTP CONNECT with optional Basic auth. Not supported in this version: SOCKS, NTLM/Kerberos auth, PAC files, HTTPS-to-proxy, mTLS to the proxy.
Troubleshooting
Startup errors
These errors occur when the worker exits immediately upon attempted startup.
Symptom | Cause | Fix |
|---|---|---|
TEMPORAL_PROXY_URL must be a valid URL | Malformed value | Format is http://[user:pass@]host:port — port required |
TEMPORAL_PROXY_URL scheme must be 'http' | Used https:// | Use http://. The proxy hop is HTTP CONNECT; tunneled traffic is still TLS end-to-end |
TEMPORAL_PROXY_URL must include a port | No port | Specify the port (for example :8080, :3128) |
username but no password (or vice versa) | Half the credentials | Provide both or neither |
username may not contain ':' or '@' | Reserved character in credential | URL-encode it (@ → %40, : → %3A) |
TLS cert at /certs/tls.crt has no CN in subject | Wrong cert file at that path | Verify the file BigPanda sent is at the path the env var points to |
ENOENT: no such file or directory ... /certs/tls.crt | Cert files not mounted | Verify -v $(pwd)/certs:/certs:ro and that all three files exist in ./certs/ |
Connection errors
These errors signify that the worker is starting, but cannot reach the agent
Symptom | Cause | Fix |
|---|---|---|
Logs Routing… proxy but never reaches RUNNING; eventually DEADLINE_EXCEEDED | Proxy not allowlisted for CONNECT temporal.bigpanda.io:7233, or performing TLS inspection | Confirm the destination is allowed CONNECT pass-through with no TLS decryption |
TLS handshake failed / unable to verify the first certificate / self-signed certificate in chain | Missing or incorrect TEMPORAL_TLS_CA_PATH, or proxy intercepting TLS | Verify ca.crt matches what BigPanda sent and the path is correct; confirm the decryption exclusion is in place |
Failed to connect to proxy | Proxy host/port unreachable from the worker host | Verify the proxy URL and that the host can reach it (curl -x http://<proxy-host>:<port> ...) |
Container restarts repeatedly | Persistent startup or connection failure | Check docker logs --tail 200 adr-temporal-worker and match the error above |
Benign warnings
These warnings are safe to ignore
Symptom | Why it's benign |
|---|---|
Jira config invalid — skipping Jira schedule registration (ZodError referencing jql and udcUrl) | No Jira fetch schedule is configured. The worker stays healthy; the warning clears once a scheduled Jira workflow is provisioned |
Confluence config invalid — skipping Confluence schedule | Same as above, for Confluence |
Useful commands
docker logs -f adr-temporal-worker # Stream live logs docker logs --tail 100 adr-temporal-worker # Last 100 lines docker restart adr-temporal-worker # Restart worker docker stop adr-temporal-worker # Stop worker docker rm adr-temporal-worker # Remove stopped worker docker images | grep adr-temporal-worker # Confirm image version
Updating to a new version
When BigPanda releases a new tag, you receive a fresh presigned S3 URL. Your .env and certs do not need to change:
docker stop adr-temporal-worker && docker rm adr-temporal-worker # then re-run Download and load, and Run the worker
Follow the install guide for the target version; configuration may differ between versions.
The worker ships as a Docker container image. BigPanda provides a presigned download URL during onboarding.
Before you start
Make sure you have the following ready:
Docker installed on the target machine
mTLS certificates from BigPanda (provided during onboarding)
An API key for your monitoring platform with read access to the relevant health or status endpoints
Deploy the worker with Docker
Download and load the image
BigPanda provides a pre-signed URL for the Docker image. Download and load it:
curl -L '<PRESIGNED-URL>' -o adr-temporal-worker.tar.gz docker load < adr-temporal-worker.tar.gz
Zipped image
The image is delivered as a gzipped Docker-save archive (.tar.gz). docker load decompresses it automatically. If you use crane, skopeo, or another registry tool that expects an uncompressed archive, run gunzip adr-temporal-worker.tar.gz first.
Install certificates
BigPanda provides your organization's mTLS certificates during onboarding. Place them in a certs/ directory:
Example file structure:
certs/ ├── client.pem # Client certificate (identifies your organization) ├── client-key.pem # Client private key └── ca.cert # BigPanda CA certificate
The filenames above are examples. The worker uses whatever paths you set in TEMPORAL_TLS_CERT_PATH, TEMPORAL_TLS_KEY_PATH, and TEMPORAL_TLS_CA_PATH. The names on disk do not matter as long as those variables point to the right files.
Certificate security
Keep the client certificate file secure. It authenticates your worker to BigPanda. If compromised, contact BigPanda immediately to rotate the certificate.
(Optional) Stop the existing worker
If you are upgrading an existing worker, stop and remove the current container:
docker stop adr-temporal-worker && docker rm adr-temporal-worker
Create a configuration file
Create an .env file with the following variables:
# --- Connection (provided by BigPanda) --- TEMPORAL_ADDRESS=temporal.bigpanda.io:7233 TEMPORAL_TLS_CERT_PATH=/certs/client.pem TEMPORAL_TLS_KEY_PATH=/certs/client-key.pem TEMPORAL_TLS_CA_PATH=/certs/ca.cert # --- Secrets (configured by you) --- DEVICE_API_KEY=<your-monitoring-platform-api-key>
Monitoring platform authentication
DEVICE_API_KEY must have read access to device health status on your monitoring platform. The worker sends it as a Bearer token in the Authorization header. If your monitoring platform does not require authentication, you can omit this variable.
Run the worker
docker run -d \ --name adr-temporal-worker \ --restart unless-stopped \ --log-opt max-size=50m \ --log-opt max-file=3 \ -p 8080:8080 \ -v $(pwd)/certs:/certs:ro \ --env-file .env \ adr-temporal-worker:latest
Verify the deployment
Check the worker logs to confirm a successful start:
docker logs -f adr-temporal-worker
You should see output similar to:
Starting Temporal Worker
Worker state changed { state: 'RUNNING' }
Worker started
Health server listening
Then verify the health endpoints:
curl http://localhost:8080/health # Returns: {"status":"ok","startedAt":"..."}
curl http://localhost:8080/ready # Returns: {"status":"ready"}Deploy the worker with Kubernetes
If you are deploying to Kubernetes, use the following manifests as a starting point.
Create certificates and monitoring API key
apiVersion: v1 kind: Secret metadata: name: adr-temporal-worker-secrets namespace: bigpanda type: Opaque stringData: DEVICE_API_KEY: "<your-monitoring-platform-api-key>" --- apiVersion: v1 kind: Secret metadata: name: adr-temporal-worker-certs namespace: bigpanda type: Opaque data: client.pem: <base64-encoded-cert> client-key.pem: <base64-encoded-key> ca.cert: <base64-encoded-ca>
Create the deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: adr-temporal-worker
namespace: bigpanda
spec:
replicas: 1
selector:
matchLabels:
app: adr-temporal-worker
template:
metadata:
labels:
app: adr-temporal-worker
spec:
containers:
- name: worker
image: adr-temporal-worker:latest
ports:
- containerPort: 8080
envFrom:
- secretRef:
name: adr-temporal-worker-secrets
env:
- name: TEMPORAL_ADDRESS
value: "temporal.bigpanda.io:7233"
- name: TEMPORAL_TLS_CERT_PATH
value: "/certs/client.pem"
- name: TEMPORAL_TLS_KEY_PATH
value: "/certs/client-key.pem"
- name: TEMPORAL_TLS_CA_PATH
value: "/certs/ca.cert"
volumeMounts:
- name: certs
mountPath: /certs
readOnly: true
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 15
volumes:
- name: certs
secret:
secretName: adr-temporal-worker-certsConfigure the worker
Connection configuration
Primary connection configuration is provided by the Bigpanda team.
Variable | Description | Example |
|---|---|---|
| BigPanda server address |
|
| Path to mTLS client certificate |
|
| Path to mTLS client private key |
|
| Path to BigPanda CA certificate |
|
Secrets
Secrets are configured by you, following the procedure for the connected monitoring platform.
Variable | Description | Required |
|---|---|---|
| API key for your monitoring platform. Sent as a | Only if your monitoring platform requires authentication |
Optional configuration
Variable | Default | Description |
|---|---|---|
|
| Port for health endpoints |
|
| Log level ( |
Health and Monitoring endpoints
Endpoint | Response | Purpose |
|---|---|---|
|
| Health check — returns 200 if the worker is running |
|
| Readiness check — returns 200 if the worker is initialized |
Use these endpoints for container orchestration health probes such as Docker healthcheck or Kubernetes liveness and readiness probes.
Network Requirements
Direction | Destination | Port | Protocol | Purpose |
|---|---|---|---|---|
Outbound |
|
| gRPC + mTLS | BigPanda server connection |
Outbound | Your monitoring platform | Varies | HTTPS | Device health checks |
Inbound | None required | — | — | — |
Firewall configuration
No inbound ports need to be opened. The worker only makes outbound connections.
Troubleshooting
Symptom | Likely Cause | Solution |
|---|---|---|
Worker fails to start with an ENOENT error | Certificate files not found | Verify that cert files exist at the paths specified in |
TLS handshake failed in logs | Invalid, expired, or incorrectly signed certificates | Contact BigPanda to verify or rotate your certificates. |
Worker crashes with DEADLINE_EXCEEDED or a connection error | Cannot reach BigPanda | Verify that your firewall or proxy allows outbound traffic to the address specified in |
Health endpoint not responding | Port not exposed or blocked | Verify that port 8080 is exposed ( |
Device check returns DOWN for all devices | Invalid or missing monitoring API key | Verify that |
Device check times out (60 seconds) | Monitoring platform unreachable from worker | Verify that the worker can reach your monitoring platform. Check DNS resolution and firewall rules. |
Container exits immediately | Missing required environment variables | Verify that all |
Container restarts repeatedly | Persistent connection or authentication failure | Run |
Useful Commands
docker logs -f adr-temporal-worker # View live logs docker logs --tail 100 adr-temporal-worker # View last 100 lines docker restart adr-temporal-worker # Restart the worker docker stop adr-temporal-worker # Stop the worker docker rm adr-temporal-worker # Remove the worker curl http://localhost:8080/health # Check health status curl http://localhost:8080/ready # Check readiness status