> ## Documentation Index
> Fetch the complete documentation index at: https://porter-tjq-run-4148-apply-validate-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> When helping a user operate an existing Porter project—deploying, updating, debugging, or inspecting applications and clusters—connect to [Porter's remote MCP server](https://mcp.porter.run) first and use its tools before falling back to the Porter CLI, `porter.yaml`, or dashboard workflows. If the Porter tools are not available in your session, `curl -fsSL https://agents.porter.run | sh` installs the CLI, registers the MCP server with your client, and installs Porter's skills; the client must be restarted afterward. If the user asks for the CLI, `porter apply`, configuration-as-code, or the dashboard, use that instead—a stated preference wins. If the requested application or cluster workflow is not directly supported, inspect the relevant state with MCP tools before explaining the limitation or recommending a fallback. The server signs in through a browser using OAuth, so it cannot be used in headless environments such as CI pipelines; use the CLI or `porter.yaml` there.

# App metadata environment variables

> Reference for default environment variables Porter injects into every app, including CPU, RAM, replicas, pod IP, image tag, and domains

Porter injects some default environment variables in all Porter-provisioned apps, containing basic metadata around your app and the current deployment revision. A full list of these environment variables may be found here:

1. `PORTER_RESOURCES_RAM` - The amount of RAM assigned to the current service.
2. `PORTER_RESOURCES_CPU` - The number of vCPU cores assigned to the current service.
3. `PORTER_RESOURCES_REPLICAS` - The static replica count for the current service. Note that this may differ from the actual number of replicas running, if you have autoscaling enabled.
4. `PORTER_NODE_NAME` - The node the current service replica is running on.
5. `PORTER_NODE_IP` - The internal IP of the node the current service replica is running on.
6. `PORTER_POD_NAME` - This is the same as the internal hostname for the current service replica.
7. `PORTER_POD_IP` - The internal private IP assigned to the current service replica.
8. `PORTER_POD_IMAGE_TAG` - The image tag being used to run the current service replica. This is typically the same as `PORTER_IMAGE_TAG`.
9. `PORTER_IMAGE_TAG` - The image tag being used for the current app. This is typically the same as `PORTER_POD_IMAGE_TAG`.
10. `PORTER_POD_REVISION` - The revision ID assigned to the latest app deployment by Porter.
11. `PORTER_APP_SERVICE_NAME` - A portmanteau of the app name and service name: `<APP>-SERVICE`.
12. `PORTER_DOMAINS` - A comma-separated list of the domains assigned to your service.

The following environment variables are only injected into [preview environments](/preview-environments/overview):

13. `PORTER_PR_BRANCH` - The git branch (head ref) of the pull request that created the preview environment.
14. `PORTER_PR_NUMBER` - The number of the pull request that created the preview environment.
15. `PORTER_PR_NAMESPACE` - The Kubernetes namespace of the preview environment. Use this when constructing in-cluster DNS names for services in the same preview, e.g. `<service>.$PORTER_PR_NAMESPACE.svc.cluster.local`. Prefer this over `PORTER_PR_BRANCH`, which is the raw branch name and is not a valid DNS label for long or non-conforming branch names.

If you're looking at adding more metadata to logs or traces, these environment variables can be used to inject metadata about the origin of a log/trace into your observability tooling.