Environment context and actions in the WebUI

The env-context banner shows live shop state; env-actions runs the approved, dev-only operations Fox proposes. Together they gate every change Fox makes.

Fox knows what environment it is looking at because two WebUI features work together: env-context reports live state and picks the target environment, and env-actions runs the safe, approved operations you allow. This page explains what each does and the guardrails around them.

Ask Fox to check state and propose actions. env-context and env-actions are the surfaces; Fox is the one that reads them and proposes what to do.

Try prompts like:

• “Which env am I on and is everything healthy?”
• “Show me service health for dev.”
• “Pull data from staging into dev.” (Fox proposes; you approve.)

env-context: live shop state

The env-context feature renders the environment row at the top of the WebUI and inside the side panel. It shows:

• Which environment the current conversation is targeting (always dev unless a human switches it outside Fox).
• Live service state: storefront, Medusa, Postgres, Redis, Matomo when it is up.
• Ports and health checks so you can see quickly whether the shop is up.

When you start a new conversation, env-context fires a session event that env-actions listens for, so both features stay in sync.

env-actions: safe, approved operations

env-actions is the action bar Fox uses to propose operations. You approve, and only then does it run. Real button ids that ship today:

Button	What it does
pull-data	Pull data from another environment into the current one
push-staging	Promote from dev to staging (hidden when staging is not present)
push-live	Promote from staging to live (hidden until staging is the current env)
logs	Show recent service logs for the current environment

Env-actions target the dev environment by default and hide destinations that do not apply. Push-to-live is not offered from a dev conversation.

Guardrails

Fox is fenced in on purpose. The Hermes container has no Docker socket and cannot create environments. Environment lifecycle commands (pnpm vulpy env add|up|down|golive) refuse inside the container. Staging and live directories are hidden from Fox’s mount. Fox proposes; you dispatch anything that touches other environments.

On AWS EC2 or Lightsail, the IMDS lock is on by default. It blocks 169.254.169.254 for the host and containers with an nft reject rule, so Fox cannot pick up the VM IAM role. Set VULPY_IMDS_LOCK=0 to opt out, or provide an explicit provider API key.

Fox joins its own Tailscale identity via a sidecar when Tailscale access is on. Host Tailscale is a separate opt-in during install, so SSH and Fox stay on distinct identities inside your tailnet.

Missions

Where you and Fox use these features together.

Deploy to a VPS

See how Fox is isolated on production hosts.