Env Presets¶
Env presets add tools, runtimes, and capabilities to your bot instance. Each preset is a self-contained package under presets/envs/<name>/ in the dev-bot repo.
Using Env Presets¶
Add preset names to the envs list in your instance.yaml:
# instance/<your-config>/agent/instance.yaml
workflow: jira-sprint
source: jira
envs:
- node # nvm + Node.js
- go # goenv + Go
- browser # Chromium + chrome-devtools MCP
- slack # Slack notifications
Presets are installed during docker build — their install.sh scripts run automatically. No runtime setup needed.
node¶
Path: presets/envs/node/
Installs nvm (Node Version Manager) with Node.js 22 LTS as the default. The bot can switch versions per-repo at runtime.
What gets installed:
- nvm v0.40.3 at /usr/local/nvm
- Node.js 22 (LTS) as default
- node, npm, npx symlinked to /usr/local/bin/
- Shell init via /etc/profile.d/nvm.sh
When to use: Any instance working on repos with package.json — frontend, Node.js backends, monorepos.
Version switching (the bot does this automatically if a repo needs a different version):
Depends on: nothing
go¶
Path: presets/envs/go/
Installs goenv (Go version manager) with Go 1.24.13 and 1.25.13, plus golangci-lint.
What gets installed:
- goenv at /usr/local/goenv
- Go 1.24.13 (default) and 1.25.13
- golangci-lint v2.13.2
- go, gofmt, golangci-lint symlinked to /usr/local/bin/
- Shell init via /etc/profile.d/goenv.sh
When to use: Any instance working on repos with go.mod — Go services, operators, CLI tools.
Version switching:
Depends on: nothing
patternfly-mcp¶
Path: presets/envs/patternfly-mcp/
Installs the hcc-pf-mcp MCP server, which gives the bot PatternFly component guidance — available components, props, examples, and CSS utilities.
What gets installed:
- @redhat-cloud-services/hcc-pf-mcp (npm global package)
- Registered as the hcc-patternfly-data-view MCP server
When to use: Frontend instances working on PatternFly-based UIs. Helps the bot use correct PF components and patterns.
Depends on: node preset (needs npm)
browser¶
Path: presets/envs/browser/
Installs Chromium and the chrome-devtools MCP server for visual verification. The bot can take screenshots, inspect the DOM, and verify UI changes in a real browser.
What gets installed:
- Chromium (via Playwright)
- chrome-devtools-mcp MCP server
- gh-release-upload skill (for uploading screenshots to PR comments)
- Runtime init script at entrypoint.d/10-chromium.sh
When to use: Any instance working on UI repos where visual verification matters. The bot starts a dev server, navigates to the relevant page, and takes screenshots.
Custom DNS (extra-hosts): Create instance/<name>/agent/extra-hosts to inject hostnames into /etc/hosts before Chrome starts. Standard hosts format:
# Dev proxy hostname — resolves to localhost where Caddy listens
127.0.0.1 stage.foo.redhat.com
::1 stage.foo.redhat.com
The entrypoint loads this file automatically. Instances without extra-hosts are unaffected. Use this when Chrome needs to resolve hostnames that don't exist in public DNS (e.g. dev-proxy targets).
Requires env var: PLAYWRIGHT_BROWSERS_PATH (set automatically in the container)
Depends on: nothing
container-scan¶
Path: presets/envs/container-scan/
Installs Grype (vulnerability scanner) and Buildah (container image builder) for CVE investigation and scanning.
What gets installed: - Grype — scans container images for known vulnerabilities - Buildah — builds container images without Docker daemon
When to use: Instances handling CVE tickets or security scanning. The bot builds the Dockerfile, scans the image, and reports findings.
Depends on: nothing
dev-proxy¶
Path: presets/envs/dev-proxy/
Installs a custom Caddy reverse proxy for verifying frontend changes against stage environments.
What gets installed:
- Custom Caddy build with HCC-specific modules
- start-dev-proxy.sh script
- Runtime init script at entrypoint.d/20-dev-proxy.sh
When to use: Frontend instances that need to verify UI changes against a running stage deployment (e.g. console.redhat.com stage).
Requires env var: PROXY_HOST (the stage hostname to proxy to)
Depends on: nothing
slack¶
Path: presets/envs/slack/
Adds the Slack notification skill. The bot sends alerts when PRs are created, tickets are blocked, or infrastructure errors occur. 48-hour cooldown per ticket prevents spam.
What gets installed:
- slack-notify skill
When to use: Any instance where the team wants Slack notifications about bot activity.
Requires env var: SLACK_WEBHOOK_URL — supports two webhook types:
- Incoming Webhook (https://hooks.slack.com/services/...) — full mrkdwn support including <url|label> hyperlinks, <!subteam^ID> mentions, bold, block quotes. Recommended.
- Workflow Builder Webhook (https://hooks.slack.com/triggers/...) — variable content is plain text inside rich_text blocks; mrkdwn link syntax and mentions are not rendered.
The payload key is auto-detected from the URL: {"text": ...} for Incoming Webhooks, {"msg": ...} for Workflow Builder.
Optional env vars:
- SLACK_NOTIFY_MODE — immediate (default) or daily_digest. In immediate mode, each event sends a separate Slack message with 48h cooldown. In daily digest mode, individual notifications are suppressed and a daily snapshot of open PRs (from the tasks table) is sent at the configured hour.
- SLACK_DIGEST_HOUR — UTC hour (0-23) when the daily digest is sent. Opt-in: digest is disabled unless this is set. The bot runner triggers it automatically after each cycle — zero LLM tokens spent.
Both SLACK_NOTIFY_MODE=daily_digest and SLACK_DIGEST_HOUR must be set to enable digest mode. Without SLACK_DIGEST_HOUR, digest is disabled (notifications still suppressed but no digest is sent).
Depends on: nothing
Creating a New Env Preset¶
- Create
presets/envs/<name>/in the dev-bot repo - Add
install.sh— must be idempotent (detect existing installs and skip): - Add
manifest.yaml: - Test: build a Docker image, run
my-tool --versioninside it - Add to your
instance.yamlenvs:list - Open a PR against dev-bot
Install scripts run during docker build via the loop in Dockerfile.runner (line 155):
They run as root and must be idempotent — the Docker layer cache means they may run multiple times during development.