Hi Vercel Community,
I need to confirm the supported deployment and rollback behavior for a dedicated staging project on the Hobby plan before authorizing any changes.
Project characteristics:
- Plan: Hobby
- Framework: Next.js
- Root Directory: apps/dntm-v4
- Node.js: 22.x
- Production branch: codex/v4-rebuild
- Stable domain: a project-level *.vercel.app domain
- Vercel Authentication: enabled
- Auto-Assign Custom Production Domains: currently enabled
- Ignored Build Step: currently Automatic
- The repository-root vercel.json contains git.deploymentEnabled=false for the production branch and legacy cron configuration.
- There is no app-level vercel.json under apps/dntm-v4.
No settings have been changed and no deployment has been created during this review.
Our intended release sequence is:
- Create a staged Production deployment without assigning the stable domain.
- Verify its immutable deployment URL.
- Promote that exact Production deployment without rebuilding.
- Verify the stable domain.
- Roll back immediately to the previous Production deployment if verification fails.
Could someone from Vercel please confirm the following?
-
On Hobby, are these commands fully supported?
vercel deploy --prod --skip-domain vercel promote
Does --skip-domain guarantee that the existing stable project domain remains assigned to the current deployment until promote?
-
Does promoting a staged Production deployment serve the exact same build without rebuilding or creating another deployment?
-
Are manual CLI deployments affected by:
- the project’s Ignored Build Step;
- “Don’t build anything”;
- git.deploymentEnabled=false for the connected branch?
Please distinguish behavior for:
- Git-triggered deployments;
- initial manual CLI deployments;
- redeployments;
- promotions.
-
When Root Directory is apps/dntm-v4 but vercel.json exists only at the repository root:
- Is that root vercel.json applied to this project?
- How can the effective configuration be verified without making a deployment?
- Could its legacy cron configuration be included in the app deployment?
-
On Hobby, after promoting exactly one new Production deployment with no intervening Production deployment:
- Is the deployment that previously served Production guaranteed to be the immediately previous rollback target?
- Is rollback order based on deployment creation time or the order in which deployments served Production traffic?
- Can Hobby roll back only to the immediately previous Production deployment, or to a specified deployment ID?
-
After rollback:
- Which project domains and aliases are restored?
- Is production-domain auto-assignment disabled?
- Can it remain disabled while manual staged deployments and promotions continue?
- Does promoting another staged deployment or using Undo Rollback re-enable auto-assignment?
- What is the supported sequence for restoring service while retaining manual release control?
-
Can a staged Production deployment be created directly from an exact commit in the connected Git repository, without uploading a local working tree?
If yes, please identify the supported Dashboard, CLI, or API mechanism and whether it is available on Hobby.
-
With Vercel Authentication enabled, can an authorized project Owner access the immutable staged Production URL using the existing browser login, without creating a shareable link or automation bypass secret?
-
Do skipped or cancelled deployments create deployment records or consume Hobby deployment/build/concurrency quotas?
-
Is there a recommended fixed Vercel CLI version for this workflow, rather than using latest?
We understand that application routes tied to the configured stable origin cannot be positively tested on the immutable deployment URL. Our proposed validation is therefore:
- Before promotion: deployment provenance/configuration, protection, GET /health = 200, and unauthenticated GET /readiness = 503 as a fail-closed negative check.
- After promotion: verify the stable domain, deployment ID, SHA/configuration, protection, GET /health = 200, and the same unauthenticated readiness behavior.
- Managed authenticated readiness and business E2E are separate later gates.
We are not asking anyone to deploy or change the project. We only need authoritative clarification before preparing an approved execution plan.
Thank you.