> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vulpy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Tip>
  **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.)
</Tip>

## 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                   |

<Note>
  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.
</Note>

## 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.

<Warning>
  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.
</Warning>

<Tip>
  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.
</Tip>

<CardGroup cols={2}>
  <Card title="Missions" icon="list-check" href="/fox/missions">
    Where you and Fox use these features together.
  </Card>

  <Card title="Deploy to a VPS" icon="server" href="/deploy/production">
    See how Fox is isolated on production hosts.
  </Card>
</CardGroup>