Skip to content

Advanced Operations

Jump to bottom
m4xx3d0ut edited this page May 12, 2026 · 2 revisions

Advanced Operations

This page covers WorkerBee features that are useful once the basic local loop is working.

Runtime Selection

WorkerBee supports:

  • auto: select an available runtime.
  • podman: use Podman.
  • docker: use Docker.
  • containerd: advanced direct-containerd mode.

Examples:

workerbee --runtime podman mcp restart
workerbee --runtime docker mcp restart
workerbee --runtime containerd profile list

Persist defaults for the local user:

workerbee config set --runtime podman
workerbee config show
workerbee config clear

MCP Remote Bind Guardrail

WorkerBee MCP binds to loopback by default. Non-loopback MCP binds are refused unless explicitly allowed:

workerbee mcp serve --host 0.0.0.0 --allow-remote-mcp

Use this only for controlled local-network transport testing. WorkerBee does not yet implement standards-compliant remote MCP authorization.

LAN ingress is separate from remote MCP. You can expose app ingress to the LAN while keeping MCP on loopback:

workerbee mcp restart --ingress-exposure lan

Containerd Privilege

Direct containerd workflows may need elevated access to the containerd socket and CNI resources. Inspect current state:

workerbee --runtime containerd containerd-privilege status

Start commands with an explicit strategy:

workerbee --runtime containerd --containerd-privilege sudo-helper profile list
workerbee --runtime containerd --containerd-privilege unprivileged profile list

Stop the helper when it is no longer needed:

workerbee --runtime containerd containerd-privilege stop-helper

Revoke deprecated ACL leases:

workerbee --runtime containerd containerd-privilege revoke-acl-leases

Remote k1s Deploy

WorkerBee can deploy staged manifests to a remote k1s server:

workerbee manifest deploy-k1s \
  --stage app \
  --server https://k1s.example.internal:6443 \
  --token "$K1S_TOKEN" \
  --namespace demo

Remote deploy fails closed for native k1s secretRef values by default because the referenced secret paths resolve on the remote controller. Opt in only when the remote environment is prepared:

workerbee manifest deploy-k1s \
  --stage app \
  --server https://k1s.example.internal:6443 \
  --token "$K1S_TOKEN" \
  --allow-remote-secretrefs

Bundle Handoff

Export native k1s:

workerbee bundle export --stage app --format k1s

Export practical Kubernetes YAML:

workerbee bundle export --stage app --format k8s

Export a Helm skeleton:

workerbee bundle export --stage app --format helm

Exports preserve Secret references but not Secret values. Create environment-specific Secret objects before applying exported Kubernetes or Helm artifacts.

Security Assessment

Assess staged manifests, generated exports, and optional runtime ingress:

workerbee security assess --stage app

Review a deployed project:

workerbee security review-project --stage app

Security checks are advisory and should feed code review, not replace it.

Advanced Diagnostics

Capture status:

workerbee mcp status --json
workerbee ingress status --json
workerbee projects --json

Probe ingress through WorkerBee MCP when possible. Agents should use workerbee_v1_ingress_probe because it knows the WorkerBee CA, host routing, and project scope.

Use workerbee_v1_ingress_status to discover active CA commands, DNS details, base domain, and readiness before asking a user to configure another device.

Clone this wiki locally