I experienced the same behavior on a newly created Vercel Hobby project.

Environment:

• Vercel CLI 56.3.2

• Node.js 24.18.0

• GitHub integration not enabled

• Two synthetic environment variables configured only for Preview

• No Production environment variables configured

• No deployments existed before the test

I ran:

1
vercel deploy --yes
2

I did not include --prod. I expected a Preview deployment, but Vercel reported:

1
Deployed to production
2

It also assigned a production alias.

I immediately removed the deployment and verified that the project now has zero deployments and no Production URL.

These Preview-targeted local commands completed successfully without creating a remote deployment:

1
vercel pull --environment=preview --yes
2
vercel build --target=preview
3

Can Vercel confirm whether this is a known CLI or platform issue and provide a workflow that guarantees a remote deployment will be classified as Preview rather than Production?

I will not attempt another remote deployment until Preview classification can be guaranteed.

I independently reproduced the same behavior on a newly created Hobby project.

Environment:

• Vercel CLI 56.3.2 / Node.js 24.16.0
• Production branch tracking: main
• Preview branch tracking: all unassigned Git branches
• Vercel Authentication: Standard Protection
• Preview-only environment variables; no Production variables
• No custom environment, branch matcher, or deployment-target setting

Reproduction:

1. An explicit vercel deploy --target=preview --yes request was classified as Production and assigned the project alias.
2. After connecting a private GitHub repository, a real pull request from a non-main branch was also classified as Production.

Neither deployment was used for QA. Both were deleted immediately, Git auto-deploy was disconnected, and the project now has zero deployments and zero domains.

The in-dashboard Vercel Agent confirmed that both results are unexpected and noted an empty targets: {} history. It recommended engineering investigation, but the Hobby case form does not allow dedicated CI/CD → Environments support. A git-metadata command was suggested only as something that should route to Preview, not as a guarantee, so I have not retried it.

Can Vercel confirm whether this first-deployment/empty-target behavior is intentional, and provide a supported request that guarantees built-in Preview classification? I do not authorize or need another Production deployment for troubleshooting. No project, repository, deployment, credential, or environment-variable identifiers are included here.

Additional diagnostic update:

I used Vercel’s authenticated Support Agent to inspect the affected project. The Agent confirmed:

• The project is correctly detected as Next.js

• Preview environment variables are configured correctly

• No Git integration is connected

• The project currently has zero deployments

• No Production alias is assigned

• The local .vercel/project.json contains no target, Production, alias, or Git-related settings

• No root vercel.json exists

• The observed behavior contradicts Vercel’s documented CLI behavior

• No configuration issue was found that explains the Production classification

The Agent described the incident as anomalous and prepared a platform support case, but the Hobby-plan case form prevented submission for a Vercel CLI issue and redirected back to the Community.

vercel@56.4.1 is now available. The original unintended Production deployment occurred with 56.3.2. I have not repeated the deployment with 56.4.1 because I have found no release note or staff confirmation that this classification issue was fixed, and another test could create another unintended Production deployment.

The project remains preserved with zero deployments. Could a Vercel staff member confirm whether 56.4.1 contains a relevant fix or provide a Preview-safe verification procedure that cannot create a Production deployment?