What is a sub-second artifact deployment on Vercel?

Vercel CLI can detect a small eligible directory of HTML or Markdown artifacts, skip the build step, upload it, and return a live deployment URL in under a second under suitable network conditions.

What are the limits for instant artifact deployment?

Vercel's September 2026 announcement supports directories containing up to 10 HTML or Markdown files with a total size of 5 MB or less. The CLI must be version 59.16.0 or later.

Is this the same as vercel deploy --prebuilt?

No. The prebuilt flow uploads a .vercel/output directory produced by vercel build or another Build Output API process. Instant artifact deployment detects a small static directory and skips a conventional build.

Can coding agents use this for preview links?

Yes. An agent can write a report or prototype to a clean directory, run Vercel CLI, capture the URL from stdout, and attach that URL to its task result. The deployment should still use scoped credentials and an appropriate retention policy.

Are generated Vercel deployment URLs private?

Not necessarily. Generated URLs can be publicly accessible unless Deployment Protection is enabled. Do not deploy sensitive reports until access controls and data handling have been reviewed.

When should I use a normal framework deployment instead?

Use the normal build path when the artifact needs server code, a large asset set, a framework compilation step, environment-dependent generation, complex routing, or more than the instant deployment limits allow.

Sub-Second Vercel Deployments for Static Artifacts

Most preview deployments spend time doing work a static report does not need. The platform installs dependencies, detects a framework, runs a build, packages output, and creates a deployment even when the input is one HTML file and a small stylesheet.

Vercel CLI now has a shorter path. Version 59.16.0 and later can recognize an eligible directory of HTML or Markdown artifacts, skip the build step, and return a live URL. Vercel's launch example completed in 802 milliseconds.

This is useful for coding-agent reports, disposable prototypes, benchmark results, design reviews, and small documentation previews. It is deliberately constrained: up to 10 supported files and 5 MB total. The constraints are a feature because they keep the fast path predictable.

The result is still a deployment. It has a URL, access policy, retention behavior, storage footprint, and possible production alias. Fast publishing should not turn temporary output into unmanaged infrastructure.

What Vercel Added

Vercel announced sub-second artifact deployments on September 17, 2026. Run vercel deploy against a small directory, and the CLI automatically determines whether it can use the instant path.

Eligible directories currently have:

No more than 10 files
A combined size of 5 MB or less
HTML, HTM, or Markdown files
Vercel CLI 59.16.0 or later

Vercel creates a project when needed, uploads the valid artifacts, and returns a deployment URL. Passing --prod can create a production deployment and assign the configured production domain.

npx vercel@latest deploy ./report

The general Vercel CLI deployment documentation notes that standard output is always the deployment URL. That makes the command easy to compose into scripts and agent workflows.

deployment_url="$(npx vercel@latest deploy ./report --yes)"
printf '%s\n' "$deployment_url"

Keep diagnostic output on standard error and treat standard output as data. A script that scrapes the prettiest line from interactive logs will break eventually.

Instant Artifacts Are Not Prebuilt Deployments

Vercel already supports vercel build followed by vercel deploy --prebuilt. That flow produces .vercel/output using the Build Output API, then uploads the prepared result.

vercel build
vercel deploy --prebuilt

Prebuilt deployment is useful when you want to build locally, inspect the output, avoid sharing source, or use a custom build pipeline. It still involves a build somewhere.

The new artifact path is smaller. You point the CLI at a directory that is already the thing you want to publish. There is no framework build to transfer or execute. For a one-page report, that can remove most of the latency and most of the configuration.

Use --prebuilt when your deployment has the full Vercel Build Output structure. Use the instant artifact path when the deliverable is a tiny set of static HTML or Markdown files.

A Minimal Static Report

Create a clean output directory. Do not point the deploy command at the repository root, where credentials, source maps, fixtures, and unrelated files may be present.

report/
├── index.html
└── details.html

The HTML should be self-contained or reference only assets that will remain available. A simple report can embed a small stylesheet and avoid JavaScript entirely.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="robots" content="noindex,nofollow" />
    <title>Accessibility review</title>
    <style>
      body { max-width: 760px; margin: 3rem auto; padding: 0 1rem; font: 16px/1.6 system-ui; }
      .pass { color: #176b35; }
      .fail { color: #a51d2d; }
      code { background: #f3f4f6; padding: .1rem .3rem; }
    </style>
  </head>
  <body>
    <main>
      <h1>Accessibility review</h1>
      <p>Generated from commit <code>4f89c2a</code>.</p>
      <h2>Summary</h2>
      <p class="pass">31 checks passed.</p>
      <p class="fail">2 checks need review.</p>
    </main>
  </body>
</html>

noindex is useful for temporary reports, but it is not access control. Anyone who can reach an unprotected URL may still read the page.

A Safe Coding-Agent Publishing Pattern

A coding agent can produce an artifact and publish it as one step in a larger task. Keep generation, validation, and deployment separate.

task request
  -> agent writes files to ./artifact
  -> validator checks type, count, size, and forbidden content
  -> human or policy approves publication
  -> Vercel CLI deploys ./artifact
  -> workflow records URL and deployment ID

The validator should reject symlinks, hidden files, unexpected extensions, oversized files, embedded credentials, and references to local-only resources. It should confirm that index.html exists when the output is meant to open as a site.

artifact_dir="./artifact"

test -d "$artifact_dir"
test -f "$artifact_dir/index.html"

file_count="$(find "$artifact_dir" -type f | wc -l | tr -d ' ')"
test "$file_count" -le 10

size_bytes="$(du -sk "$artifact_dir" | awk '{print $1 * 1024}')"
test "$size_bytes" -le 5242880

find "$artifact_dir" -type l -print -quit | grep -q . && exit 1

Use a more precise validator in production, especially on systems where du and find behave differently. The point is to validate the exact publication directory instead of trusting the agent's statement that it only wrote a report.

Build a CI Workflow Around the Artifact Directory

Keep the deployment job narrow enough that its review is boring. The job should receive a known artifact, validate it again, and deploy only that directory. It should not check out unrelated branches, install arbitrary project dependencies, or give the report generator a production token.

name: Publish static review artifact

on:
  workflow_dispatch:
    inputs:
      source_run_id:
        description: "Approved workflow run containing the artifact"
        required: true

permissions:
  contents: read
  actions: read

jobs:
  deploy:
    runs-on: ubuntu-26.04
    environment: artifact-previews
    steps:
      - name: Download approved artifact
        run: |
          # Download only from the expected workflow and repository.
          # Extract into ./artifact without executing its contents.
          true

      - name: Validate files
        run: ./scripts/validate-static-artifact.sh ./artifact

      - name: Deploy preview
        env:
          VERCEL_TOKEN: ${{ secrets.VERCEL_ARTIFACT_TOKEN }}
        run: |
          npx vercel@59.16.0 deploy ./artifact \
            --yes \
            --token "$VERCEL_TOKEN" > deployment-url.txt

      - uses: actions/upload-artifact@v5
        with:
          name: deployment-record
          path: deployment-url.txt

The comments stand in for repository-specific artifact retrieval. Do not copy an untrusted archive into a working directory and rely on unzip defaults. Reject absolute paths and .. traversal during extraction.

Use an environment approval if publishing is consequential. A preview project token should not be able to change the main website's production domain.

Handle Failure as a First-Class Result

Fast deployment can fail before or after upload: CLI authentication can expire, file eligibility can change, network access can fail, the project can hit a limit, or protection settings can make the returned URL inaccessible to the intended reviewer.

Return a structured failure instead of asking the agent to repeat the command indefinitely.

{
  "status": "failed",
  "stage": "deploy",
  "retryable": false,
  "reason": "artifact exceeds 5 MB instant-deployment limit",
  "artifactBytes": 6812400,
  "suggestedPath": "normal-build"
}

Classify limits as non-retryable until the artifact or deployment path changes. Classify a transient network response as retryable with a small attempt ceiling and backoff. Store stderr privately, since command errors can expose project names or paths that do not belong in a public report.

After receiving a URL, verify it with an authenticated request if protection is enabled. Confirm the expected title or provenance marker instead of treating any HTTP 200 page as success.

Capture Provenance With the URL

A live URL is not enough to reproduce a report. Store the inputs and versions that created it.

Record:

Source repository and commit
Task or pull-request identifier
Agent and model configuration if AI generated the artifact
Generator version
Validation result
Deployment URL and ID
Creation and expiry date

Embed a small provenance block in the page when appropriate. Do not expose private prompt content or credentials. A commit SHA and timestamp are often enough for a reviewer to connect the page to its source.

Vercel's generated URL documentation explains that each deployment receives a unique URL and that CLI deployments also receive project and author-related aliases. Unique URLs are convenient for immutable review links, while an alias can point to the newest version.

Choose deliberately. A pull-request comment should usually link to the immutable deployment. A team dashboard may use a stable alias.

Preview and Production Mean Different Things

Running vercel deploy creates a preview deployment by default. Running with --prod creates a production deployment and may move production domains.

Do not add --prod to an automated agent simply because the output is static. Production aliasing is an external side effect. It should require explicit policy or approval.

Vercel supports a staged production flow:

vercel deploy --prod --skip-domain
vercel promote <deployment-id-or-url>

The first command creates a production-targeted deployment without immediately assigning the production domain. The second promotes it after review. Vercel documents this flow in its CLI deployment guide.

For disposable reports, stay with preview deployments unless a permanent public URL is part of the requirement.

Protect Reports That Contain Internal Information

Generated deployment URLs should be treated as public unless protection is configured. A hard-to-guess URL is not a permission system.

Vercel's Deployment Protection documentation describes Vercel Authentication, password protection on supported plans, and trusted IP controls for Enterprise. Standard Protection can restrict generated deployment URLs while leaving a production custom domain available.

Review the protection policy before the first automated deployment. Do not wait until an agent has published an incident report with customer identifiers.

Sensitive material may not belong on this path at all. Authentication reduces casual access, but deployment storage, logs, backups, integrations, and recovery behavior still need to satisfy the organization's data policy.

Keep Deployment Tokens Narrow

An agent that can run vercel deploy --prod with a team-wide token may be able to affect more than one temporary report. Use a dedicated project and a credential scoped as narrowly as the platform allows.

Separate projects by trust level. Public demonstrations, internal reports, and customer-specific previews should not share one project merely because the files are small.

Set a budget and rate limit around automated publishing. A broken loop can create hundreds of deployments in minutes. The upload is fast enough that the failure becomes an inventory problem before anyone notices the command is repeating.

Use an idempotency key in the surrounding workflow, even if the CLI itself creates a new deployment per call. A source commit, task ID, and artifact digest can identify an existing successful publication. If the same request arrives again, return the stored URL or make an explicit new-version decision.

Do not use a broad personal token for unattended deployment. The automation should remain valid when one employee leaves and should have no authority beyond the artifact project and required environment.

Plan Retention Before the Queue Grows

Every deployment consumes deployment storage and remains reachable for as long as the retention policy and protection exceptions keep it.

Vercel's deployment retention documentation lets projects define retention periods for canceled, errored, preview, and production deployments. Some deployments remain protected by exceptions, such as current production or aliased deployments.

Hobby accounts receive 10 GB of deployment storage. Vercel changed Hobby retention in September 2026 so older deployments outside the protected set are deleted sooner when the account exceeds its allowance. A stable branch or custom alias can still keep a deployment active.

For automated artifacts, define an expiry policy that matches their value. A pull-request report rarely needs to survive for years. A compliance artifact may require a different storage system with explicit retention guarantees.

Avoid creating one Git branch per generated report. That can generate branch aliases and preview deployments that stay protected. Use CLI deployments to a dedicated artifact project and retain the source artifact in the system of record.

Know When the Fast Path Is the Wrong Path

The 10-file and 5 MB limits rule out many applications. Use a normal project build when you need:

Framework compilation or server rendering
Functions, middleware, or API routes
Large images, fonts, or JavaScript bundles
Environment-dependent generation
Complex rewrites, redirects, or headers
More than a small collection of documents

Do not split a real application into ten strange files to keep an impressive deployment time. The fast path is for artifacts that are naturally small.

Markdown support is convenient for plain reports, but rendering expectations should be tested before relying on it for a client-facing page. HTML gives you direct control over semantics, styling, metadata, and accessibility.

Keep the Artifact Accessible and Self-Contained

A report that deploys quickly can still be unpleasant to review. Use semantic headings, a single main landmark, sufficient color contrast, keyboard-accessible controls, and useful link text. Include a viewport declaration and test the page at a narrow width.

Avoid loading a large framework from a CDN for a static table. It adds another availability and security dependency while working against the reason the artifact qualified for the fast path.

When external assets are necessary, pin or control them. A report that references an image in a temporary CI URL will become incomplete after the job expires. A stylesheet fetched from a mutable third-party URL can change the meaning or appearance of an archived review.

For diagrams, inline a modest SVG only after sanitizing it. SVG can contain scripts, links, and external references. Treat agent-generated markup as untrusted until a sanitizer and a content security policy say otherwise.

A small Content Security Policy can reduce risk for reports that need no scripts:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src 'none'; style-src 'unsafe-inline'; img-src 'self' data:; base-uri 'none'; form-action 'none'"
/>

Test the policy against the report. If a feature needs broader access, add the narrow source it requires instead of replacing the policy with default-src *.

Use Stable Aliases Sparingly

An immutable deployment URL is useful evidence because it continues to identify one artifact. A stable alias is useful for "latest report" workflows, but it changes what the same URL means over time.

Keep both when the use case needs them. The review record can point to the immutable URL, while a team bookmark points to the alias. Record which deployment currently owns the alias.

Aliases also affect cleanup. Vercel retention policies can protect aliased deployments from deletion. An automation that assigns a new custom alias for every task may accidentally convert disposable reports into retained storage.

Prefer one rotating alias per report class, such as latest-accessibility-review, and immutable deployment URLs for individual runs. Remove obsolete custom aliases when the workflow ends.

Do Not Confuse Speed With Cacheability

Skipping a build shortens creation time. It does not determine how browsers or the CDN cache the content. Test response headers and update behavior if the artifact is consumed by automation.

An immutable URL can use long-lived caching because its contents should not change. A stable alias that moves between deployments needs cache behavior that lets clients observe the new target. Avoid adding client-side cache workarounds until you have inspected the actual headers Vercel returns for the deployment and alias.

If the report includes private data, browser and intermediary caching belong in the threat model. Deployment authentication controls access to a request; it does not automatically erase content already cached by an authorized client.

Useful Automation Examples

Pull requests can receive a static quality report after tests finish. A benchmark job can publish its task summary and link to raw artifacts stored elsewhere. A design agent can publish a small HTML prototype for review. A migration script can create a before-and-after route report.

The common trait is bounded output. The deployment is the final presentation layer, not the build system or source of truth.

A reliable workflow returns a structured result:

{
  "deploymentUrl": "https://example.vercel.app",
  "sourceCommit": "4f89c2a",
  "artifactFiles": 2,
  "artifactBytes": 18432,
  "visibility": "protected-preview",
  "expiresAfterDays": 14
}

That record can be audited and deleted. A URL pasted into a chat message cannot.

A Small Deployment Still Needs Ownership

Sub-second deployment removes ceremony from sharing a small artifact. It does not remove the need to decide what was published, who can read it, how long it stays, and whether the URL represents preview or production.

Keep the pipeline narrow: generate into a clean directory, validate the files, require approval for production, protect non-public content, record provenance, and expire old deployments. With those controls in place, a coding agent can turn a result into a reviewable page almost as quickly as it can write the final sentence.