Skip to main content
The Vercel integration connects your Vercel team to Keldyn’s continuous-evidence engine. Once connected, Keldyn reads your deployment, environment, configuration, edge-security (firewall/TLS), monitoring and alerting (fired alerts, webhook destinations, log drains), redundancy, auto-scaling, and logging posture on a schedule and turns it into live evidence for the related controls — so you don’t have to re-check and re-attach that evidence by hand. Some of that evidence depends on you telling Keldyn which environment variables your rotation policy covers. Keldyn proposes those mappings; you confirm them, and nothing counts toward that control until you do — see Confirm your environment-variable mappings.
Integrations and automated evidence are typically managed by workspace admins. See Evidence & audits for how automated evidence fits alongside manual evidence.

​
What it’s used for

Keldyn uses the data it reads from Vercel to keep the evidence for your hosting and deployment controls current. Each nightly refresh updates the evidence and the freshness status shown on the integration’s Controls covered table. The integration contributes evidence to these ISO 27001 controls: It also contributes evidence to these SOC 2 controls:
Full coverage means the data is the artifact the control asks for. Partial coverage means the data usefully contributes but does not, on its own, replace everything the control requires (for example, A.8.32 also needs change authorization, impact assessment, and rollback records that live in your change-management process). Keldyn labels partial coverage in the auto-generated evidence so it isn’t mistaken for complete coverage.
Vercel’s edge firewall blocks or challenges matched traffic rather than enforcing a classic default-deny allowlist, and the Vercel API doesn’t expose cipher-suite/TLS-version policy or the certificate record itself — keep that in mind when using this evidence for Firewalls at access points and Encryption in transit. Network monitoring alerts now needs all of a configured alert-rule/history source, a wired webhook destination, and an active log drain to fully pass — still not a full SIEM. System redundancy reflects configuration, not a tested failover, and Auto-scaling configuration reflects that Vercel functions scale by design rather than a load-tested outcome. Segregated change environments stays Partial: the environment inventory contributes to, but does not replace, the architecture diagram and access-control documentation in your change-management document. A.5.17 / Authentication information stays unsatisfied until you confirm which environment variables are in rotation scope — see below.

​
Before you begin

1

Install as a Vercel team admin

You connect by installing the Keldyn integration on your Vercel team. This is a connect once flow — after install, Keldyn refreshes evidence on its own with no further action from you. Installing requires permission to add integrations to the team.
2

Know which features your plan includes

The Vercel Firewall (WAF), Log Drains, general Alerts, and Webhooks are available on higher Vercel plans (Pro/Enterprise). On plans that don’t include one of them, the affected controls show Access required for that source instead of failing — Network monitoring alerts still refreshes from whichever of its sources remain available, and the rest of the evidence refreshes normally.
3

Keldyn only ever reads

The integration is granted read access only. Keldyn never deploys, changes configuration, or writes to your Vercel team.

​
Set up the integration

1

Open Integrations

In the Keldyn web app, go to Integrations and select Vercel.
2

Connect

Select Connect. You’re redirected to Vercel to install the Keldyn integration on your team. Review the requested read access and approve it; Vercel returns you to Keldyn once the install completes.
3

Run the first sync

After connecting, select Sync now to pull evidence immediately, or wait for the next scheduled refresh. The Controls covered and Evidence sources tables then show what was collected and how fresh it is.
From an integration’s detail page, Controls covered shows, per control, whether Vercel is actively feeding it and whether the control is satisfied. Evidence sources shows each data fetch, the controls it covers, and its freshness.

​
Confirm your environment-variable mappings

Keldyn can read every environment variable configured on your projects — its name, which environments it targets, and when it was last updated. What it cannot know is which of those variables are actual credentials your rotation policy covers, versus a feature flag or a public config value that never needs to rotate. So Keldyn proposes, and you confirm. After the first sync, the Environment-variable mappings card on the Vercel integration page lists every environment variable Keldyn can see as a rotation-scope candidate.
A proposed mapping evidences nothing. Until you confirm it, that environment variable’s timestamp does not count toward A.5.17 (Authentication information), and the control stays unsatisfied if no variable has been confirmed. This is deliberate: an auditor should never be shown a control marked satisfied on the strength of a guess Keldyn made about which of your variables are credentials.
For each proposal you can:
  • Confirm it, which records your name and the time against the mapping and sets its rotation period (defaulting to 90 days) — its last-updated timestamp then counts toward A.5.17 on the next sync.
  • Reject it, which stops Keldyn proposing it again. A rejected mapping is never revived by a later sync.
Keldyn reads environment-variable names and timestamps only — Vercel returns variable values only when explicitly decrypted, and Keldyn never requests or stores one.
Confirm the variables your rotation policy genuinely covers — database credentials, API keys, signing secrets — not every variable in the project. A feature flag or public config value adds noise without adding evidence.

​
What data Keldyn collects and why

Keldyn requests read-only access and never writes to your Vercel team. It collects only the data below, and only to build control evidence.
A project with a single function region and no cross-region failover, or a domain without TLS/HTTPS enforced, is recorded as real (unfavorable) evidence rather than a sync failure — that’s what surfaces as a gap on the matching control.

​
Authentication

Keldyn authenticates as a Vercel integration installation. Installing the integration returns a long-lived, team-scoped access token that Keldyn stores encrypted, so there is no password to rotate and no repeated re-authorization. The integration’s read scopes are configured on the integration itself in Vercel. Removing the integration in Vercel, or selecting Disconnect in Keldyn, immediately severs access.

​
Troubleshooting “Access required”

A control shows Access required when the connected team can’t read the underlying data — most often because the feature isn’t included in your Vercel plan. For example:
  • The Vercel Firewall (WAF) is required for the networks-security control and for the firewall leg of network-monitoring-alerts.
  • Log Drains are required for the logging control and for the log-drain leg of network-monitoring-alerts.
  • Alerts and Webhooks are required for the fired-alert-history and webhook-destination legs of network-monitoring-alerts, respectively.
Upgrade the Vercel plan to include the feature, or enable it for the team, then run Sync now again. Controls not affected by the gap keep refreshing normally.

​
Keeping evidence current

Keldyn refreshes Vercel evidence automatically each day. Evidence that hasn’t refreshed within its expected cadence is marked stale, and failed pulls are marked failed so you can spot gaps. You can also trigger an immediate refresh at any time with Sync now.

​
Next steps

Evidence & audits

Learn how automated integration evidence works alongside manual evidence and audits.