Whenever you create a new Project on Vercel, the platform will try to preselect the right default configuration for you.

For example, this happens through detecting which frontend framework you're using, and then selecting the right Build & Development Settings for your Project automatically, or applying default routing rules based on the framework that was detected.

These defaults will let you deploy your Project to Vercel with zero configuration, and you will be offered to customize them as needed during the process of creating your Project.

Routing Rules

If you'd like to forward a URL path to a different one, apply headers to it, rewrite it, or simply change its visual appearance, you can do so by configuring custom routing rules.

Typically, your framework provides its own configuration file for this purpose. In the case of Next.js, for example, you can configure rewrites, redirects, and headers by placing them inside a file named next.config.js:

module.exports = {
  async redirects() {
    return [
      {
        source: '/about',
        destination: '/',
        permanent: false,
      },
    ];
  },
};

Configuring a redirect that forwards visitors from the /about URL path to /.

Take a look at your framework's documentation to learn more about which routing rules it supports. Vercel will automatically accept those out of the box.

In the case that your framework doesn't provide the kind of routing rule you need, you can configure rewrites, redirects, headers, trailing slashes, and HTML extension stripping by placing them inside a file named vercel.json instead.

If you're unsure about whether your Project would benefit from one of the routing rules mentioned above, check out the respective documentation sections to learn about their individual purposes before using them.

API Routes

To allow for serving data from the server-side to browsers or other types of clients, and consuming it, you can configure API Routes.

Instead of placing your entire API in a single server, Vercel will automatically deploy and scale each of your API Routes as an independent service, which is enabled through defining them as Serverless Functions like so:

module.exports = function (req, res) {
  res.send('Hello!');
};

Configuring an API Route that returns "Hello!" as a response.

Just like with routing rules, your framework typically provides its own location in the source code for these files. In the case of Next.js, for example, the API Route shown above could be placed in pages/api/index.js.

In the case that your framework doesn't support API Routes (or doesn't support the language you'd like to use), you can place them inside an api directory and have Vercel take care of them automatically. In that case, the above example could be placed inside a file located at api/index.js.

If you want to, you can learn more about the concept of Serverless Functions on Vercel.

Environment Variables

If you've created your Project on the dashboard, you were given the opportunity to configure custom Environment Variables to influence the behavior of your source code, even before its first Deployment was created.

Those Environment Variables were added to all three Environments that Vercel offers:

  • Production (served to visitors)
  • Preview (used for testing changes)
  • Development (used for local development by your entire team)

If you'd like to configure different ones for each Environment, you can do so on the Environment Variables page in the Project Settings:

The Environments available for selection when adding Environment Variables.

As you can see, the right side of the page allows you to select the individual Environments that you'd like to add your Environment Variable to. Pick the ones you care about, fill in the name and the value, and submit it.

If you've already added an Environment Variable while creating the Project, you can also find it in the list at the bottom of the page, select Edit from its menu, and configure it to apply to different Environments:

Editing an existing Environment Variable.

In order to use a different value for every Environment, you then need to add another Environment Variable with the same name at the top, but select a different Environment while doing so.

Different values for different Environments provide better security and protection from accidents. While Preview and Development can use the same value, it is recommended to at least use a different one for Production.

In general, Production would, for example, be used for connecting to a database containing real user data, while Preview and Development should only connect to a separate database containing testing data. This will make it impossible for you and your team to leak or modify user data by accident.

Up Next

Continue getting started on Vercel: