env0 MCP Server

The env0 MCP Server is env0’s official Model Context Protocol server for infrastructure-as-code and cloud-management work. It connects an MCP-capable AI client to the env0 platform. According to the README, it can query projects and environments, trigger or cancel deployments, retrieve plan and apply logs, inspect Cloud Compass resources, and generate Terraform code for discovered resources. The official product page places these capabilities in GitOps and IDE workflows: teams can investigate status, failed runs, and approvals in their editor instead of continually switching to the platform. That makes it suitable for DevOps and Automation, not because an agent should operate infrastructure autonomously, but because it provides a deliberately bounded connection to existing IaC processes.

A local container, not a hosted MCP endpoint

This record is classified as local. The official repository explicitly requires Docker and documents operation as a container. For this repository variant it does not name a public MCP endpoint operated by env0. In its default mode, the container communicates through stdio with a local MCP client. The README also documents HTTP mode: an operator sets MCP_TRANSPORT=http, exposes a local port, and points the client to that service’s /mcp path. HTTP therefore remains an operator-run container service, not evidence of an env0-hosted remote service. For development, the repository documents Node.js dependencies, npm install, npm start, and the MCP Inspector. Those are for developing or debugging a copy of the server, not a required replacement for the documented container path.

IaC and cloud context

According to the provider, env0 manages cloud environments and their IaC workflows. The MCP server can therefore do more than search static documentation: README examples include projects, named environments, deployment status, plan and apply logs, resource inventories, and drift findings. Cloud Compass supplies resource context; the README names AWS resources, S3 buckets, and Terraform generation for a resource as examples. Those results can accelerate triage, audit preparation, and planning an import. They are not a reviewed change, however: generated Terraform, an error analysis, or a drift finding must be checked against the repository, plan, policies, and the correct account.

Authentication and permissions

The README says the container needs an env0 API key and API secret, plus an organization ID where applicable. They are supplied to the container as ENV0_API_KEY, ENV0_API_SECRET, and ENV0_ORGANIZATION_ID; the organization ID helps select the intended organization when a user belongs to more than one. The official API-key documentation distinguishes administrator, user, and personal keys. Administrator keys can, among other things, change organization settings, deploy environments, and approve them. User keys can be bound to existing RBAC through project permissions and teams; personal keys follow the rights of the relevant account. This creates a firm security boundary: initial use needs a dedicated, non-administrator key with minimum project rights in a secret store or unversioned local runtime configuration. Never copy keys, secrets, .env files, or container-inspection output into commits, prompts, screenshots, or tickets.

Mutations, approvals, and the model data path

According to the source, the server can start or cancel deployments, and the product page also describes approving a plan. Each action changes external infrastructure activity or its governance state. It must not be initiated by an unattended agent, by a summary of log text, or by prompt injection hidden in logs. Begin with read-only tools, confirm the organization, project, and environment ID in the env0 UI, and require explicit human approval stating the target and expected effect before a deploy, cancellation, or approval. env0 states on its product page that secrets and variables are not exposed through the MCP server. That does not remove the need to assess data flow: log excerpts, error context, resource names, IDs, IaC fragments, and tool results can still be sensitive. A local container also does not mean that all processing is local; the connected AI client may transmit prompts and tool context to its model provider. Review client, model, retention, and enterprise policies separately, minimise queries, and redact sensitive content before sharing it.

License, cost, and popularity signal

The concrete repository is Apache-2.0 licensed; its LICENSE file is authoritative. The server can run locally as an open-source container, while the env0 account, cloud resources, Docker host, and AI client each have their own terms. This public entry intentionally gives no fixed prices. Immediately before seeding on 2026-09-08, the GitHub API reported exactly 4 stars. That is a point-in-time repository-popularity signal, not evidence of quality, security, or suitability.

FAQ

Does the server replace GitOps approvals? No. It brings information and selected platform actions into a client; policies, RBAC, audit logs, and human approvals remain the essential controls.

Does the server run entirely locally? The README documents a local Docker container. Its connection to the env0 platform and any data path from the MCP client to a model provider must be assessed separately.

Docker, an MCP-capable client, and an env0 API key and API secret; also an organization ID when using multiple organizations.

Use Docker as documented in the official README, run env0 MCP Server as a local container, and pass ENV0_API_KEY, ENV0_API_SECRET, and, where needed, ENV0_ORGANIZATION_ID only as runtime secrets. Use stdio by default; enable HTTP only for a deliberately bounded local or self-operated network deployment.

docker build -t env0/mcp-server .

env0 API key and API secret via ENV0_API_KEY and ENV0_API_SECRET; ENV0_ORGANIZATION_ID selects the correct organization when multiple organizations are available. Permission scope follows the key type and env0 RBAC.

The API key determines env0 rights. The server can enable read queries plus deployment, cancellation, and approval flows; therefore use a dedicated least-privilege key and human approval before mutations.

The local container communicates with the env0 platform and returns tool results to the MCP client. env0 says secrets and variables are not exposed through the MCP server; log and resource context can still be sensitive, and the client can transmit it to a model provider.

Powerful API credentials, deploy/cancel/approval mutations, selecting the wrong organization or environment, prompt injection in logs, and transmission of tool context to external model providers.