- contact@verticalserve.com
The CLI is great for building and testing. Production is a different problem: who owns the credentials, which skill version is running, who can trigger it, who sees the audit trail when it does something. The Enterprise control plane gives you all of it from one place — so your workers are governed, not just running.
Every production worker pulls a specific version of a signed skill bundle on startup. No drift, no surprise behavior changes — and rollback is a single config update in the control plane.
Each deployment gets its own scoped Personal Access Token. Runs are attributed to the service account, not a human. Revoke from one place, instantly.
Dev workers can use any model and any tool. Production workers inherit a stricter policy — model whitelist, tool blocklist, token quotas, off-hours windows — enforced server-side on every policy fetch.
Production can't pause for /app done. Define rules once: auto-approve read-only tools, escalate writes to Slack or PagerDuty, hard-block destructive ones.
Every production run shows up in the same Dashboard / Usage / Activity views as developer runs — filterable by deployment, team, or skill. No separate observability stack.
Every prompt, tool call, model response, and approval decision is logged with the deployment ID, signed skill version, and policy bundle signature in force at that moment. Auditable end-to-end.
A production worker is just a containerized InsightWorker runtime configured to run unattended. On startup it fetches its effective policy bundle and pinned skill version from the control plane. It reports usage back. Triggers come from your existing infrastructure: cron, queue, webhook, or chat channel.
Same worker runtime, same skill bundles, same control plane. The only thing that changes is what wakes the worker up.
A container that runs insightworker worker on a schedule, executes one app, reports usage, exits. Best for batch and recurring work.
# k8s CronJob — runs the weekly sprint digest every Monday at 9am apiVersion: batch/v1 kind: CronJob metadata: name: iw-weekly-digest spec: schedule: "0 9 * * 1" jobTemplate: spec: template: spec: containers: - name: iw-worker image: ghcr.io/verticalserve/insightworker-worker:2.1.11 args: ["worker", "--skill=weekly-sprint-digest@1.4.0"] env: - name: IW_API_URL value: https://iw.your-org.com - name: IW_PAT valueFrom: { secretKeyRef: { name: iw-pat, key: token } } restartPolicy: OnFailure
A container that starts on an event (webhook, queue message, file drop), runs one app, posts back, exits. Best for fast-reaction automations.
# Cloud Run service — handles a PagerDuty webhook # PagerDuty fires → Cloud Run starts container → runs L1 skill → exits $ gcloud run deploy iw-l1-responder \ --image=ghcr.io/verticalserve/insightworker-worker:2.1.11 \ --args="worker,--mode=webhook,--skill=l1-incident-response@2.1.0" \ --set-env-vars=IW_API_URL=https://iw.your-org.com \ --set-secrets=IW_PAT=iw-l1-pat:latest \ --region=us-east1 --no-allow-unauthenticated # Then point PagerDuty at the Cloud Run URL: # https://iw-l1-responder-xxx.run.app/webhook # Worker: # 1. Reads the PagerDuty payload (incident.triggered) # 2. Pulls effective policy + l1-incident-response@2.1.0 skill bundle # 3. Runs the app: ack alert → tail logs → pull dashboards → draft update # 4. Posts the update to PagerDuty notes + #incidents Slack channel # 5. Reports usage event back to the control plane and exits
A persistent container connected to a chat channel or a queue, handling many requests over a session. Best for conversational agents.
# docker-compose.yml — Slack-attached support agent services: iw-support-bot: image: ghcr.io/verticalserve/insightworker-worker:2.1.11 command: ["worker", "--mode=slack", "--channel=#support", "--skill=l1-support-agent@3.0.0"] restart: always environment: IW_API_URL: https://iw.your-org.com IW_PAT: ${IW_SUPPORT_PAT} SLACK_BOT_TOKEN: ${SLACK_BOT_TOKEN} SLACK_APP_TOKEN: ${SLACK_APP_TOKEN} healthcheck: test: ["CMD", "insightworker", "healthcheck"] interval: 30s # Bot listens on #support, threads each user request as its own run, # reports each run as a usage event with thread_id as the correlation key.
Once a worker is deployed, you manage it from the Enterprise UI alongside your dev devices and human users. Same audit, same usage analytics, same policy editor.
List of every production worker, its skill version, its environment, last-run status, error rate. One row per deployment with a sparkline.
Each deployment points at one signed skill version. Promote v2.1.0 → v2.2.0 with an audit-logged config change; if it misbehaves, click "rollback to last good".
Notify on error spikes, quota breaches, or unexpected model usage. Email, Slack, or PagerDuty — your channel of choice.
Filter the Usage and Activity views by deployment. See tokens, cost, top skills, error mix, and recent runs for any worker — same UI your team already uses.
Define which tool calls run unattended and which escalate. "Read-only tools auto-approve, writes to prod systems escalate to #ops, destructive operations hard-block."
One scoped PAT per deployment, rotated on a schedule. Revoke from the Credentials page; the worker is locked out on its next policy fetch.
# 1. Build the app on your laptop (CLI / Desktop / VS Code) $ insightworker /app create "process new broker submissions in inbox folder" $ insightworker /app run process-broker-submission # 2. When it works end-to-end, package it as a skill $ insightworker /app publish broker-submission-triage # 3. Submit to the Enterprise marketplace for approval (admin signs it) $ # Publishes via `iw app publish` to the configured S3 bucket (IW_APP_STORE) # 4. Create the deployment in the Enterprise UI # Settings → Deployments → New → mode=Event-triggered, skill=broker-submission-triage@1.0.0 # Pick environment (prod), service account, approval policy, alert channels. # 5. Point your trigger at the deployment endpoint and watch runs flow in # Dashboard → Usage → filter by deployment → see tokens, cost, runs in real time.
Production deployment, central management, signed skill versions, and full audit are part of InsightWorker Enterprise. Start a conversation — we can have your first deployment running in a week.
Talk to us about Enterprise See what else Enterprise includes