> ## Documentation Index
> Fetch the complete documentation index at: https://docs.porter.run/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. Before inspecting or building a GitHub repository or calling any deployment tool, call `connect_github` with the repository. Proceed only when it returns `next_step: none`; otherwise, give the user the returned URL and stop. 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.

# QM Use Cases

> [QM](/addons/qm) gives your team AI teammates that share context, files, and schedules. At Porter, we run QM on our own infrastructure, allowing our agents to securely deploy internal apps and connect to existing data. This page outlines three ways we use QM internally:

> [card] [Automatic Workload Rightsizing](#automatic-workload-rightsizing)
>
> Cutting costs for users

> [card] [Tracking Sales Leads](#tracking-sales-leads)
>
> Tracking and enriching sales leads

> [card] [Deploying Vibe Coded Apps](#deploying-vibe-coded-apps)
>
> Shipping internal tools without engineering overhead

## Automatic workload rightsizing

We’ve given QM a weekly task to check the CPU and RAM utilization of our own internal services and flag any opportunities to cut costs. QM uses a read-only role that only grants access to relevant usage data.

Identifying these services used to be a slow and manual process. Fortunately, the agent does a good job of using context about our systems to weigh recommendations in a way that a fixed formula can’t. For instance, a CPU spike from a one-off job is probably fine to absorb, whereas recurring pressure gets flagged.

QM is able to differentiate between dangerous and ordinary spikes in usage and account for reasonable headroom in its rightsizing recommendations.

We receive these reports as a weekly digest of recommendations in slack and have reduced our AWS bill by upwards of 20%.

## Tracking sales leads

Porter has always been a product-led company operating with a lean growth team. A lot of valuable information for our sales pipeline doesn’t naturally fit in our CRM, like product alerts and activity from interested users who explore the platform through self-service.

Since QM runs in our own infrastructure, we were able to easily bring together non-sensitive customer activity, sales pipeline data, and support interactions to give QM the context it needs to understand the entire customer journey.

Instead of manually piecing together information across systems, we can now query QM to identify where customers get stuck, uncover expansion opportunities, and surface accounts that need attention. Crucially, QM makes these insights accessible without engineering overhead. Our growth team can explore new questions, refine campaigns, and act on emerging signals simply by asking QM within Slack.

## Deploying vibe coded apps

Recently, our team started building internal apps by describing them to QM instead of writing the code by hand. Our largest project so far is a CRM built around product-led growth.

Traditional CRMs are designed for sales-led teams, so they often miss much of what self-serve users do. Our CRM brings signups, product activity, and pipeline data into one place. The growth team can see which accounts are active and which ones have stalled. They can also spot expansion opportunities before reaching out.

QM built the CRM and its underlying data pipelines. We've since used the same approach to create internal revenue dashboards.

Once the apps were built, we deployed them to a dedicated cluster for low-trust code. Each app sits behind a Porter private load balancer, which keeps it off the public internet. Porter's forward authentication adds a sign-in step, so only our teammates can open the apps. The apps also access our data using read-only credentials, so they can't change anything they touch.

[Deploy QM →](https://docs.porter.run/addons/qm)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.