Know which Vercel integration you are using
TradeVulcan’s documented Work connection is the Vercel REST API adapter, using your own token and an explicitly selected team/project. It is not an automatic installation of the official Vercel MCP client. The permissions and setup screens for those products are not interchangeable.
This guide concerns customer websites connected to Work. It does not change how the TradeVulcan platform itself is hosted or deployed. Vercel account charges and limits remain with the customer’s provider account.
Select and verify one project
- Open Work Mode → Connections → Vercel in the correct workspace.
- Enter the customer team and existing project selection requested by the secure form, or reserve an exact new project name when that option is offered.
- Provide the personal token only through the secure connection form.
- Inspect the verification result and begin with a read of the selected project, Git link, deployments or domain status.
Use the correct source path
For an existing Git-linked website, edit its authorized repository and deploy the exact reviewed commit. Do not send a handful of replacement files as if they were the complete website. For an unlinked project, file-based deployment requires the complete supported source rather than a partial update.
A reserved project name is only an allowed target for possible creation. Creating that project still requires the appropriate provider access and separate approval.
Default to a preview
Read the selected Vercel project and confirm its Git repository link. Prepare a preview deployment of the exact approved commit. Do not change production or connect a domain. After approval, report the deployment state and preview URL.
Check the project, source commit and target in the proposal. If the Git link or repository selection is missing, resolve it explicitly. Never substitute a different project because it is easier to deploy.
A provider READY state describes build readiness. Inspect the resulting browser page, its routes, images and important customer contact paths before calling the change successful. Test failures are not fixed by simply repeating the deployment request.
Production and domains are separate decisions
An explicit production release request must identify the reviewed source and selected target. Review that proposal separately from the preview. Domain addition or verification also has its own scope.
Work can read domain ownership and DNS recommendations and prepare supported project/domain actions. Changes at an external registrar are a separate handoff. Protect email and unrelated DNS records, follow the exact verified requirements and check HTTPS and the public site after the change.
After an interrupted request
Read the saved operation and deployment list before creating another deployment. Provider acceptance is not final completion. If the effect is unknown, inspect the exact project and preserve the operation reference for support.
Refreshing the connection or changing its scope can invalidate old previews. Reread the project and prepare a fresh proposal rather than applying stale approval data.