Deploy Dry Runs Turn Into Release Contracts

Vercel shipped two small-looking platform changes this week that matter for anyone letting CI, scripts, or agents near production deploys. The first is vercel deploy --dry, which previews the framework preset, included files, ignored paths, size distribution, and largest files before creating a deployment. The second is Service Bindings, which lets one Vercel service call another inside the same deployment while Vercel handles internal routing, authentication, and TLS.

GitHub also removed a common automation footgun: Copilot CLI can now run in GitHub Actions with the built-in GITHUB_TOKEN, provided the workflow has copilot-requests: write and the organization policy allows billing. That reduces long-lived PAT sprawl, but it also makes it easier for automated workflows to do more real work.

The pattern is clear: deployment automation is becoming safer and more capable at the same time. The missing layer is the release contract that decides what is allowed to pass.

What a dry run should prove

A dry run is valuable because it answers questions that are hard to see in a code diff:

• Did the platform detect the framework you expected?
• Which files will be uploaded, and which will be ignored?
• Did a large asset, test fixture, local database, or generated folder sneak into the deployment?
• Did .vercelignore remove something that the app actually needs at runtime?
• Has the deployable surface changed more than the pull request suggests?

The useful move is to convert those answers into checks. For a small business site, ecommerce frontend, local-service booking flow, or internal dashboard, the deployment contract can be simple:

framework: nextjs
max_deployment_size_mb: 25
forbidden_paths:
  - .env
  - .env.local
  - test-results
  - playwright-report
  - data/exports
required_paths:
  - public
  - src
review_if_largest_file_over_mb: 2

The exact thresholds are less important than having thresholds at all. Without them, a dry run is just another log line that everyone ignores until the deploy is slow, broken, or leaking something embarrassing.

Why service bindings change the review surface

Service bindings make multi-service apps easier to operate. A frontend can call a backend through an injected binding rather than hard-coding public URLs and manually wiring auth. That is a good reliability and security improvement.

It also changes what reviewers need to inspect. A pull request that adds or changes a binding is not just a refactor. It may alter which service can call which internal API, which environment variable becomes available, and which deployment boundary now carries trust.

For practical teams, that means service configuration deserves the same review as application code:

• list every service-to-service binding in version control;
• require a reason when a new caller can reach an internal API;
• separate read-only internal endpoints from write-capable ones;
• make preview environments use preview bindings, not production backends;
• log the caller service name on sensitive internal operations.

This is especially important for quote forms, booking systems, lead-routing tools, and ecommerce admin helpers. Those systems often look small, but a bad internal call can still change a customer record, trigger an email, reserve a slot, or expose a lead list.

The agent angle: fewer secrets, more permissions

GitHub's Copilot CLI update is directionally right: using GITHUB_TOKEN in Actions is safer than creating long-lived PATs for every automation. It narrows credential lifetime and lets permissions live with the workflow.

But teams should not confuse fewer secrets with fewer risks. If an AI-assisted workflow can inspect code, generate patches, run commands, and create deploys, the important control becomes the workflow boundary:

permissions:
  contents: read
  pull-requests: write
  copilot-requests: write

Then create separate workflows for separate jobs. A diagnostic workflow may need Copilot requests and read access. A release workflow may need deployment permissions. Very few workflows need both broad repository writes and production deploy rights by default.

A practical release contract for small teams

Start with a plain checklist that CI can gradually enforce.

1. Manifest gate: run the deploy dry run and save the JSON output as a CI artifact.
2. Size gate: fail if total deploy size, largest file size, or file count jumps beyond an agreed threshold.
3. Path gate: fail if forbidden files are included or required runtime files are absent.
4. Framework gate: warn when framework detection changes unexpectedly.
5. Binding gate: require review when service bindings are added, removed, or pointed at a different service.
6. Secret gate: prefer platform tokens like GITHUB_TOKEN where possible, but keep workflow permissions minimal.
7. Promotion gate: do not let an agent-created change promote itself to production without passing the above checks.

That is enough to catch the boring failures that hurt real businesses: shipping the wrong bundle, missing runtime files, silently changing internal trust boundaries, or leaving an automation secret with more power than it needs.

The useful habit

Whenever a platform adds a safer primitive, turn it into a policy while the change is still fresh. vercel deploy --dry is useful on a laptop, but it becomes business leverage when every pull request can prove what it would ship. Service bindings are cleaner than public internal URLs, but they need a small access map. GITHUB_TOKEN is better than a PAT, but it still needs scoped workflow permissions.

The teams that get the most from agentic development will not be the ones that deploy the fastest. They will be the ones that make deployment intent visible before any automation is allowed to act.