> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/solutions-and-use-cases/secure-what-you-ship-on-vercel.md).

# Secure Deployments on Vercel

Connect Vercel and Heeler lists every project, the commit live in production, and the vulnerabilities, weaknesses, and secrets in the code behind it — including projects deployed straight to Vercel th

Connect Vercel and Heeler lists every project, records the exact commit live in production, and scans the code behind each one for vulnerable dependencies, code weaknesses, exposed secrets, and risky agent files.

The projects worth finding first are the ones deployed straight to Vercel. They have no repository to clone, so source-control scanning never sees them — yet they are serving production traffic. Heeler pulls their source from Vercel's API and analyzes it as a repository in its own right.

This playbook runs it end to end: connect, see what is live, cover the projects with no repository, triage their findings, and gate the changes you can.

{% hint style="info" %}
**For:** security engineers and platform owners with applications on Vercel. **Prerequisites:** a [Vercel connection](/mrecEO40m5D6bt7Pq5pE/get-started/cloud-and-runtime/vercel.md) (an access token scoped to your team). Connecting the repositories behind your projects gives the richest result, but code deployed without one is still covered.
{% endhint %}

## Adding Vercel projects

{% stepper %}
{% step %}

### Connect Vercel with an access token

Follow [Connect Vercel](/mrecEO40m5D6bt7Pq5pE/get-started/cloud-and-runtime/vercel.md). Projects, deployments, teams and members, and Marketplace stores harvest on their own. Scope the token to the team you want Heeler to see.
{% endstep %}

{% step %}

### See every project and the commit live in production

Each project's current production and staging deployment becomes a service deployment carrying its deployed commit SHA. For many teams this is the first single view of what is running on Vercel and which commit it came from — the baseline every later question depends on.
{% endstep %}

{% step %}

### Cover the projects with no connected repository

In **Catalog → Repositories**, projects split two ways. Those linked to a repository you already monitor resolve to it. Those deployed straight to the platform appear as their own repositories, sourced from Vercel — and they arrive already analyzed, carrying modules, dependencies, endpoints, and findings exactly like the ones that came from your SCM.

That second group is where to start: production code that was outside your source-control coverage entirely, and is now inside it without anyone having to onboard those projects.
{% endstep %}

{% step %}

### Triage their SCA, SAST, endpoint, and secret findings

Triage exactly as you would anywhere else — [SCA](/mrecEO40m5D6bt7Pq5pE/findings/open-source-sca.md) for vulnerable dependencies, [SAST](/mrecEO40m5D6bt7Pq5pE/findings/code-security-sast.md) for code weaknesses, [Secrets](/mrecEO40m5D6bt7Pq5pE/findings/secrets.md) for exposed credentials, and [Endpoints](/mrecEO40m5D6bt7Pq5pE/catalog/endpoints.md) for the API surface you've published. Same prioritization, same [remediation](/mrecEO40m5D6bt7Pq5pE/fix.md) and ticketing.
{% endstep %}

{% step %}

### Score the agent files shipping in that code

Modern Vercel apps frequently *are* AI applications, and the instruction files that steer coding agents ship in the same repositories. The agent-file catalog runs as part of the same analysis, so [Agent Files](/mrecEO40m5D6bt7Pq5pE/findings/agentic-supply-chain-agent-files.md) found in Vercel-hosted code are inventoried and scored alongside the rest — including in projects that never passed through a monitored repository.
{% endstep %}

{% step %}

### See which data entities and stores each project touches

Vercel apps are usually the front door to real data. Two things to check: the [Data Inventory](/mrecEO40m5D6bt7Pq5pE/catalog/data-inventory.md) entry for these repositories, which reports the entities and classified fields their code declares and the regulations that follow; and Marketplace **stores**, which are harvested as data stores and linked to the projects that use them. Together they answer "what would be exposed if this app were compromised?"
{% endstep %}

{% step %}

### Gate future changes with PR guardrails

For projects linked to a git repository, put [PR Guardrails](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails.md) on it so a vulnerable dependency or a new weakness is stopped before it deploys. For projects deployed straight to Vercel there are no pull requests to gate — so the decision is whether to move that project behind a repository, or accept detection-after-deployment as the control for it.
{% endstep %}
{% endstepper %}

## The outcome

You can name every project running on Vercel and the commit each one is serving. Every project's code has been scanned — including the ones with no repository behind them. You know which of them handle regulated data, which carry agent files, and who owns them. And the projects that can be gated at the pull request are gated.

## How Heeler gets this from Vercel

* **Lineage comes from Vercel's API, not from inference.** Vercel exposes the git origin of every project and the commit SHA of every deployment through its own API. Heeler reads that directly, so lineage for a Vercel app needs no runtime agent and no correlation heuristics — it's metadata, and it's exact.
* **Vercel states the environment explicitly.** A deployment declares whether it targets production or staging, so environments resolve without tag conventions or naming rules.
* **Code with no repository is still analyzed.** A project deployed straight to Vercel has nothing to clone. Heeler fetches its file tree from the platform API and analyzes it as a source repository in its own right — the same pipeline, not a reduced one.
* **Once a project is modeled, the rest of Heeler applies to it.** Dependency and code findings, endpoints, secrets, agent files, data classification, ownership, and SLOs all work on a Vercel project exactly as they do on an SCM-connected repository.

## Validate success

* Every project in your Vercel account appears in **Catalog → Repositories** — as a repository you already monitored, or as a platform-sourced one.
* Platform-sourced repositories show real module and dependency counts, and findings where they exist, rather than empty rows.
* Each project's current production deployment carries a commit SHA and resolves to an environment.
* The projects you chose to link resolve to their git repository, and their pull requests are covered by guardrails.

## Where to go next

* [Connect Vercel](/mrecEO40m5D6bt7Pq5pE/get-started/cloud-and-runtime/vercel.md) — setup and everything Heeler harvests.
* [Repositories](/mrecEO40m5D6bt7Pq5pE/catalog/repositories.md) — the inventory Vercel projects appear in.
* [Data Inventory](/mrecEO40m5D6bt7Pq5pE/catalog/data-inventory.md) — the data these applications handle.
* [PR Guardrails](/mrecEO40m5D6bt7Pq5pE/prevent/pr-guardrails.md) — what linking a repository unlocks.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/solutions-and-use-cases/secure-what-you-ship-on-vercel.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.