Skip to main content
Use this guide after the first successful deployment when you need explicit control over the source and environment that Veryfront Cloud serves.

​
Prerequisites

  • A project that works with veryfront dev.
  • A Veryfront login or VERYFRONT_API_TOKEN.
  • A page, API route, or agent request that you can verify after deployment.
For a first deployment, use Deploy with Veryfront Cloud. For your own infrastructure, use Self-host Veryfront Code.

​
Pick one deployment boundary

Choose one behavior to check in development, preview, and production:

​
Build and serve locally

veryfront build writes browser assets to build.outDir, which defaults to dist/. For the default production preset, this configured directory must be inside the project because Veryfront clears it before writing. Use veryfront build --output <dir> for a one-off external destination. The embedded preset does not clear its output root and allows an external build.outDir. API routes, agents, workflows, and tasks remain in the project source and are loaded by veryfront serve. Before uploading source, verify that build.outDir contains the browser assets and that server-executed API routes, agents, workflows, and tasks remain in the project source.

​
Keep release browser artifacts together

Each production build writes a content-addressed hydration runtime beside the release’s router and other browser assets. When Veryfront renders an immutable release, the HTML references that release-baked runtime. It does not substitute the runtime from the currently serving Veryfront process. This pairing is a compatibility boundary. Keep the hydration runtime for as long as its immutable release can be deployed or served. Retire the release and its browser artifacts together; never delete only the hydration runtime or redirect its hashed URL to newer bytes. A release that is missing its single versioned runtime fails rendering instead of falling back to a potentially incompatible runtime. Veryfront’s required browser regression job exercises the current server against an aged release artifact set. The build contract test also verifies that every promoted artifact set contains exactly one discoverable versioned hydration runtime, so an incompatible pairing blocks promotion in CI. This policy follows incident #264 and the immediate compatibility fix in veryfront-code PR #3124.

​
Push a preview

Push creates or links the Cloud project, uploads the current source, and prints the preview URL. It stores project identity in ignored .veryfront/project.json and the source digest in .veryfront/push-receipt.json. It does not write veryfront.json. Push preserves remote-only files by default. Preview an exact mirror before removing them:
Apply the mirror only when those deletions are intentional:

​
Deploy an environment

Deploy uses the last verified Push receipt, confirms the release source digest, and prints the environment URL. If the receipt is missing, Deploy first runs a quiet Push. For a named nonproduction environment:

​
Resolve project identity

Project references use this precedence:
  1. VERYFRONT_PROJECT_SLUG or environment configuration.
  2. veryfront.config.ts.
  3. Legacy veryfront.json.
  4. Tenant or project ID environment references.
  5. The ignored .veryfront/project.json link.
Keep .veryfront/project.json ignored unless the project intentionally uses committed configuration.

​
Check environment access

Veryfront Cloud environments are protected by default. Open a protected URL in a browser signed in as a project member. To make an environment public, enable Public Environment in Veryfront Studio. See Cloud environment access for sign-in redirects, non-browser clients, API-token behavior, and public access.

​
Recover environment URLs

Deploy prints the environment URL. To reopen the canonical site URL:
For automation:
veryfront open opens the project in the Cloud dashboard, not the deployed site. open --site constructs the canonical Veryfront domain and cannot discover a configured custom domain. Record the URL Deploy printed when automation must use the custom domain.

​
Understand readiness checks

Deploy chooses a readiness route only from static page routes. An API-only project or a project with only dynamic pages can deploy successfully without a root page returning 200; Deploy skips the browser readiness probe when there is no static route to check. An acknowledged release can still report a data-plane warning after commit. Do not retry only because a shared proxy acknowledgment is delayed.

​
Verify it worked

If the app uses Application authentication, configure APP_URL, OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET, and VERYFRONT_AUTH_SESSION_SECRET in the deployment environment. Store the client secret and session secret as deployment secrets. Every horizontally scaled instance for the same environment must receive the same values. Rotate the session secret as a coordinated deployment because old sessions are rejected after rotation. Use the environment URL that Deploy printed and repeat the check from development and preview. Validate the status or behavior that the selected route normally returns. For a protected environment, Deploy already probes the URL with an environment access token obtained by exchanging your API key and prints a warning when only the access gate answered. Repeat the check in a browser signed in as a project member, or exchange the token yourself as described in Cloud environment access. For a public agent route:
The response emits AG-UI data: lines.

​
Tear a project down

Delete the project and its environments, releases, files, and uploads:
Use Deploy from CI for reviewed Git commits and protected production environments.