Run Jobs With Mounted Volumes

Trigger scripts that need mounted directories, datasets, model files, or output paths by running them through a customer-owned TrigRun executor.

Use this pattern when a job needs filesystem access: host directories, NFS mounts, EFS volumes, model artifacts, backup folders, or generated output paths.

TrigRun does not mount volumes into TrigRun-managed infrastructure. Instead, TrigRun triggers a workspace executor that runs in your infrastructure, and that executor runs the command in an environment where the volumes are already mounted.

How it works

TrigRun schedule or run-now
        |
        v
Customer executor connection
        |
        v
Container, VM, or Kubernetes pod with mounted volumes
        |
        v
Script reads /mnt/input and writes /mnt/output
        |
        v
Executor returns stdout, stderr, exit code, and output to TrigRun

Use callback or poll mode for long-running work. TrigRun parks the execution while your executor works, then records the result when the executor calls back or when polling reports completion.

Example: Docker executor with host volumes

Run a TrigRun executor in your infrastructure and mount the directories your jobs need.

docker-compose.yml

services:
  trigrun-executor:
    image: ghcr.io/your-org/trigrun-executor:latest
    restart: unless-stopped
    ports:
      - "8789:8789"
    environment:
      PORT: "8789"
      PUBLIC_BASE_URL: "https://runner.example.com"
      TRIGRUN_AUTH_MODE: "hmac"
      TRIGRUN_HMAC_SECRET: "${TRIGRUN_EXECUTOR_HMAC_SECRET}"
      ALLOWED_COMMAND_PREFIXES: "node /opt/jobs/,python /opt/jobs/"
      RUN_RETENTION_MS: "3600000"
    volumes:
      - /srv/trigrun/jobs:/opt/jobs:ro
      - /srv/customer-data:/mnt/input:ro
      - /srv/customer-output:/mnt/output

In this setup:

Path inside executor	Purpose
`/opt/jobs`	Versioned job scripts, mounted read-only
`/mnt/input`	Input data, mounted read-only
`/mnt/output`	Output directory for generated files

The command TrigRun sends should reference the container paths, not the host paths.

Step 1: Store executor auth in TrigRun

Use a shared secret for the executor connection. HMAC auth is recommended for production executor dispatch.

trigrun secrets create \
  --name runner-hmac-secret \
  --value "$TRIGRUN_EXECUTOR_HMAC_SECRET"

If the script itself needs secrets, store those separately:

trigrun secrets create \
  --name report-api-token \
  --value "$REPORT_API_TOKEN"

Step 2: Register the executor connection

trigrun executors create \
  --name volume-runner \
  --base-url https://runner.example.com \
  --mode callback \
  --auth-type hmac \
  --auth-secret runner-hmac-secret

trigrun executors test EXECUTOR_ID

EXECUTOR_ID is the id returned by trigrun executors create.

Step 3: Create a job that uses the mounted paths

This job runs inside the executor, where /mnt/input and /mnt/output are mounted.

trigrun jobs create-script \
  --name "Daily report from mounted data" \
  --cron "0 2 * * *" \
  --executor EXECUTOR_ID \
  --executor-mode callback \
  --command "python /opt/jobs/build-report.py --input /mnt/input/orders.csv --output /mnt/output/orders-report.json" \
  --env REPORT_TOKEN=secret://report-api-token \
  --timeout-ms 7200000

For a one-off run, create and trigger the job immediately:

trigrun jobs create-script \
  --name "Backfill mounted customer data" \
  --executor EXECUTOR_ID \
  --executor-mode callback \
  --command "python /opt/jobs/backfill.py --input /mnt/input/customers.parquet --output /mnt/output/backfill-result.json" \
  --timeout-ms 7200000 \
  --run-now

For an existing job, trigger it with:

trigrun jobs run JOB_ID

Step 4: Inspect the execution

trigrun executions list --job JOB_ID
trigrun executions get EXECUTION_ID

The execution record shows the executor connection, remote run id, stdout, stderr, exit code, timing, and final status. Keep large artifacts in your mounted output directory or object storage, and return a small structured reference in stdout or output.

Dynamic per-run mounts

If each run needs a different volume, keep that decision inside your executor gateway. The safer pattern is:

TrigRun sends a constrained command or job name.
Your executor maps that command to an approved volume definition.
Your executor starts the real container, VM task, or Kubernetes job with those mounts.
The executor returns the normalized result to TrigRun.

Avoid accepting arbitrary host paths, raw Docker flags, or Kubernetes volume specs from the TrigRun job payload. Treat mount selection as infrastructure policy owned by your executor.

For example, your executor can map a job name to a known container profile:

executor-profiles.json

{
  "daily-report": {
    "image": "ghcr.io/your-org/report-runner:2026-05-03",
    "mounts": [
      "/srv/customer-data:/mnt/input:ro",
      "/srv/customer-output:/mnt/output"
    ],
    "command": ["python", "/opt/jobs/build-report.py"]
  }
}

TrigRun should trigger daily-report; the executor should decide which image, mounts, and runtime options are allowed.

Kubernetes variant

In Kubernetes, run the executor as a service and mount a PersistentVolumeClaim into the executor pod, or have the executor create per-run Jobs with approved volume templates.

executor-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: trigrun-executor
spec:
  replicas: 1
  selector:
    matchLabels:
      app: trigrun-executor
  template:
    metadata:
      labels:
        app: trigrun-executor
    spec:
      containers:
        - name: executor
          image: ghcr.io/your-org/trigrun-executor:latest
          ports:
            - containerPort: 8789
          env:
            - name: PUBLIC_BASE_URL
              value: "https://runner.example.com"
            - name: TRIGRUN_AUTH_MODE
              value: "hmac"
            - name: TRIGRUN_HMAC_SECRET
              valueFrom:
                secretKeyRef:
                  name: trigrun-executor
                  key: hmac-secret
            - name: ALLOWED_COMMAND_PREFIXES
              value: "python /opt/jobs/"
          volumeMounts:
            - name: job-scripts
              mountPath: /opt/jobs
              readOnly: true
            - name: input-data
              mountPath: /mnt/input
              readOnly: true
            - name: output-data
              mountPath: /mnt/output
      volumes:
        - name: job-scripts
          configMap:
            name: trigrun-job-scripts
        - name: input-data
          persistentVolumeClaim:
            claimName: customer-input-data
        - name: output-data
          persistentVolumeClaim:
            claimName: customer-output-data

Safety checklist

Mount input directories read-only whenever possible.
Use a dedicated output directory for generated files.
Use bearer or hmac auth for the executor connection.
Do not send secret:// env vars to unauthenticated executors.
Keep ALLOWED_COMMAND_PREFIXES narrow.
Do not allow user-supplied host paths or container runtime flags.
Prefer callback or poll mode for jobs that can run longer than a normal HTTP request.
Return small logs and artifact references to TrigRun instead of large files.

Run Jobs With Mounted Volumes

On this page