Platform Version Detection

Vercel CLI will automatically upgrade your deployment to the latest platform version if you import a project or if your project meets certain criteria. In order for this to work, you must:

  • Remove any Dockerfile.
  • Remove the type property from your vercel.json file.
  • Remove the start script from your package.json file.
  • Remove the server.js file from the root of your project.

It is possible to opt out of this behavior by creating a vercel.json file with a version property.

If you are yet to upgrade to the latest platform version, please read our upgrade guide.

Green Energy Policy

Vercel works with multiple cloud partners in order to provide services to end users.

The Serverless approach is an energy-efficient alternative to traditional servers because your code runs only on-demand.

For more information on our cloud partners' Green energy policies, we recommend viewing their documentation:

What can I deploy with Vercel?

Vercel is best at deploying technologies that can be served over HTTP and distributed through our CDN network:

  • Static websites and static generators (Next.js, React, Vue, Angular, etc)
  • Code that renders HTML on the server-side
  • API endpoints that query databases or web APIs and return dynamic data

In general, most popular technologies and languages already have quickstarts or guides you can start taking advantage of today.

Missing Public Directory

The build step will result in an error if the output directory is missing, empty, or invalid (if it’s actually not a directory). To resolve this error, you can try the following steps:

  • Make sure that the output directory is specified correctly in project settings. Here’s the documentation.
  • If the output directory is correct, double check the Build Command (documentation) or the root directory (documentation).
  • Try running the Build Command locally and make sure that the files are correctly generated in the specified output directory.

Missing Build Script

Note: This is only relevant if you’re using Vercel CLI 16.7.3 or older.

If your project contains a package.json file, no api directory, and no vercel.json configuration, it is expected to provide a build script that performs a static build of your frontend and outputs it to a public directory at the root of your project.

When properly configured, your package.json file would look similar to this:

{
  "scripts": {
    "build": "[my-framework] build --output public"
  }
}

An example build script in a package.json file that specifies the output directory.

Once you have defined the build script, this error will disappear. Furthermore, it will not be displayed if you are using package.json purely to provide dependencies for your Serverless Functions located inside the api directory.

Broken Preview Deployment Suffix

The Preview Deployment Suffix feature (available optionally on the "General" team settings page) allows for replacing the now.sh suffix of every freshly created deployment with a custom domain of your choice.

In order for this feature to function properly, the custom domain you configured must be:

  • Active (not deleted)
  • Available within the team that enabled the Preview Deployment Suffix
  • Backed by an active wildcard certificate

The easiest way to satisfy all of these constraints is to ensure the domain is also added to a project located within the same team. This project would ideally contain a single index.html that would display when someone visits the bare domain.

Maximum Team Member Requests

No more than 10 requests of users wanting to join a team can be open at the same time. In order to allow for more requests, the existing ones have to be approved or declined by an owner of the team.

This ensures the list always remains managable and protected against spam.

Inviting Users to Team Who Requested Access

If a user already requested access to a team, it's not possible to invite them. Instead, their request must be approved by an owner of the team in order for the user to gain acess.

This ensures no requests are accidentally accepted.

Unused Project Settings with Non-Zero-Config Deployments

Project settings are only applied to zero-configuration deployments. A deployment that uses the builds property will not apply the settings or take them into consideration.

Invalid Route Source Pattern

The source property follows the syntax from path-to-regexp, not the RegExp syntax.

For example, negative lookaheads must be wrapped in a group.

Before

{
  "source": "/feedback/(?!general)",
  "destination": "/api/feedback/general"
}

After

{
  "source": "/feedback/((?!general).*)",
  "destination": "/api/feedback/general"
}

Invalid Route Destination Segment

The source property follows the syntax from path-to-regexp.

This means that a colon (:) defines the start of a named segment parameter.

A named segment parameter defined in the destination property must also be defined in the source property.

Before

{
  "source": "/feedback/:type",
  "destination": "/api/feedback/:id"
}

After

{
  "source": "/feedback/:id",
  "destination": "/api/feedback/:id"
}