Changelog
Surfacing the Environment of Deployments and Domains
The following Dashboard pages now display the Environment of Deployments and Domains:
- The Deployment View
- The Deployment List
- The Domain List in your Project Settings
In the case of Domains and Environment Variables, the Environment reflects the Environment of the Deployments that they're assigned to.
This change will make it easier for you to determine which Deployments, Domains, and Environment Variables relate to each other.
Check out the documentation as well.
Git Fork Protection can now be disabled
If you receive a pull request from a fork of your Git repository that includes a change to the vercel.json file or the Project has Environment Variables configured, Vercel will require authorization from you or a member of your Team to deploy the pull request.
This behavior protects you from accidentally leaking sensitive Project information.
If you're certain your Environment Variables do not contain sensitive information, you can now disable Git Fork Protection by visiting the Security section of your Project Settings.
Check out the documentation as well.
Environments Variables per Git branch
You can now add Environment Variables to a specific Git branch in the Preview Environment.
When you push to a branch, a combination of Preview Environment Variables and branch-specific variables will be used. Branch-specific variables will override other variables with the same name. This means you don't need to replicate all your existing Preview Environment Variables for each branch – you only need to add the values you wish to override.
Also, you no longer need to specify the type of Environment Variable (Plaintext, Secret, Provided by System) because all values are now encrypted. The new design is optimized for both security and convenience, ensuring you can easily view the value later by editing in the UI or running vercel env pull to fetch Development Environment Variables locally.
We previously introduced the Provided by System option as some frameworks need to map system variables like VERCEL_URL to framework prefixed variables like NEXT_PUBLIC_VERCEL_URL. You no longer need to configure this mapping because the prefixed variables are added automatically based on your Framework Preset.
Check out the documentation as well.
Integration Webhooks are now easier to configure
You can now specify a generic Webhook URL in your Integration settings. If your Integration relies on Webhooks, it will now be much easier to configure and use them. Each of the following events will be sent as a POST request:
- Deployment Created, Deployment Ready, and Deployment Error events can be sent for each Project your Integration is installed to.
- Integration Removed and Permission Updated events can be sent for each Integration Configuration created by your Integration.
- Project Created and Project Removed events can be sent when an Integration has access to all Projects in a Vercel scope, and a Project was created or removed in that scope.
It's been possible to manually list, create, and delete Webhooks via the Vercel API, but this API is deprecated and will be removed on August 20th, 2021.
We no longer support a Delete Hook URL that receives a DELETE request when an Integration Configuration was removed. If a Delete Hook URL was set, it is now set as a Webhook URL, and "Integration Removed" is turned on. At the moment, the Integration Removed event is sent as two events (a POST request and a DELETE request). The DELETE requests will no longer be sent starting August 20th, 2021.
Check out the updated documentation and API reference to learn more.
Domains can now easily be transferred out
Starting today, if you are looking to transfer out domains you purchased from or transferred into Vercel, you can access the authentication code for initiating the transfer to another registrar directly on your Domains overview.
Previously, this was only possible by contacting Support.
Check out the documentation as well.
Domains now include their `www` counterpart
Adding a domain to a project will now also suggest adding its www counterpart. This ensures visitors can always access your site, regardless of whether they type www when entering the domain, or not.
Using a www domain guarantees that the Vercel Edge Network can reliably and securely route incoming traffic as quickly as possible, so redirecting non-www to the www domain is recommended. Redirecting the other way works too if you prefer a cleaner URL address.
Existing domains are not affected by this change, but we recommend ensuring that your project already has a www redirect in place.
Check out the documentation as well.
The build cache can now be enabled when redeploying
To surface the default behavior and provide granular control, you can now find an option for including the build cache when redeploying an existing Deployment.
This update also comes with a refreshed UI for the redeploying functionality, which states more clearly which Domains will be applied to the new Deployment.
Check out the documentation as well.
Faster builds with per-branch caching
The Build Step now considers the current Git branch when reading and writing the cache.
Since the first push to a branch will create a deployment without a branch-specific cache, it will read from the Production branch's cache. Subsequent pushes to that branch will read from its own branch-specific cache.
This means that Preview branches will no longer write to the Production branch's cache. This leads to faster builds because changing dependencies in one branch won't change the cache of another branch.
In addition, we no longer delete the build cache when a build fails. Instead, you can manually trigger a build without cache by using the "Redeploy" button on the Dashboard.
Our tests with a large Next.js app brought down incremental build times from 13 minutes to 4 minutes.
Check out the documentation as well.
IP Geolocation for Serverless Functions
Requests received by Serverless Functions on Pro and Enterprise Teams are now enriched with headers containing information about the geographic location of the visitor:
X-Vercel-IP-Country– The 2-letter country code of the IP sending the request.X-Vercel-IP-Country-Region– The ISO 3166-2 region code associated to the IP.X-Vercel-IP-City– The city name associated to the IP.
As an example, a request from Tokyo is now enriched with the following headers:
X-Vercel-IP-Country: JP X-Vercel-IP-Country-Region: 13 X-Vercel-IP-City: Tokyo
This feature is now automatically activated for all new and existing Serverless Functions on Pro and Enterprise Teams — no code or configuration change needed.
Check out the documentation as well.
Every push now receives a new unique URL
Today, we're announcing that every Git push and Vercel CLI invocation will result in a new unique URL and a new immutable Deployment.
Existing Deployments will no longer be re-used if you try to create a new one.
This change will likely not impact you in a meaningful way. On November 20th 2020, we enabled automatic System Environment Variables by default. If that option is enabled, a new immutable Deployment will already be created every time.
Vercel always strives to give you real-time feedback on every change you push. To this end, we are working on leveraging smart incremental computation techniques to avoid redoing work that’s already been done.
Nuxt analytics available on Vercel Analytics
Nuxt analytics are now available for all Nuxt projects on Vercel as part of Vercel Analytics, with zero configuration. This allows developers to understand the Real Experience Score for Nuxt projects.
To enable, after importing your Nuxt project:
- Open a Nuxt project in your Vercel dashboard.
- Select the "Analytics" tab and follow the flow.
No code changes are required, and options for self-hosted applications are available for enterprises.
Once deployed, your application will automatically report Core Web Vitals to Vercel.
Check out the documentation as well.
Vercel Analytics are now real-time
Vercel Analytics now updates your Real Experience Score in near real-time as visitors load your website:
- Data is available seconds after enabling Analytics (down from ~30 minutes).
- Immediately see updated metrics after new Production Deployment (down from ~3 hours).
- Enjoy a reactive dashboard experience, even when viewing data for long time spans.
- Improved search, loading, and sorting for Pages/URLs for better page-by-page analysis.
In addition to near real-time updates, you can now adjust the score interval granularity to help you understand your Real Experience Score better than ever before.
Enable Vercel Analytics for your project today, or visit the documentation.
Jekyll deployments are now 15x faster
Starting today, Jekyll dependencies from bundle install will be cached and used for subsequent Deployments. A "hello world" Jekyll application now builds 15x faster – down from 3 minutes to 11 seconds with cache.
You can verify that the build cache was used by viewing your Deployment's build logs.
Detailed usage metrics are now available
With the introduction of a new Usage overview, the dashboard now provides detailed insight into all the relevant usage metrics for your Team, and visualizes them as different charts:
- The Networking section helps you ensure all responses are made as efficient as possible, split by cached and uncached responses.
- The Functions section helps you track down misbehaving Serverless Functions through understanding requests that failed, timed out or were throttled.
- The Builds section helps you ensure your Deployments spend the least amount of time possible in the Build Step.
Navigate to the new "Usage" tab available to Teams on the Pro or Enterprise plan and start optimizing your Projects today.
Check out the documentation as well.
Domains can now be redirected with a custom status code
You can now select a temporary or permanent status code for Domain Redirects.
There are some subtle differences between these status codes:
- 307 Temporary Redirect: Not cached by client, method and body never changed.
- 302 Found: Not cached by client, method may or may not be changed to GET.
- 308 Permanent Redirect: Cached by client, method and body never changed.
- 301 Moved Permanently: Cached by client, method may or may not be changed to GET.
We recommend using status code 307 or 308 to avoid the ambiguity of non-GET methods, which is necessary when your application needs to redirect a public API.
Check out the documentation as well.
Node.js 10 is being deprecated
Following the release of Node.js 14 last week, Vercel is announcing the deprecation of Node.js 10, which reaches its offical end of life on April 30th 2021.
On April 20th 2021, Node.js 10 will be disabled in the Project Settings and existing Projects that have Node.js 10 selected will render an error whenever a new Deployment is created. The same error will show if the Node.js version was configured in the source code.
Serverless Functions of existing Deployments that are using Node.js 10 will be migrated to Node.js 12 on the date mentioned above.
If your Project is using Node.js 10 (which you've either defined in engines in package.json or on the General page in the Project Settings), we recommend upgrading it to the latest version (Node.js 14).
Need help migrating to Node.js 14? Let us know and we'll help you out.
The Directory Listing feature will be disabled for older projects
Last month, Vercel announced that the Directory Listing feature could now be toggled directly from the Project Settings and that it would be disabled for newly created Projects.
In favor of security, and to prevent unexpected behavior for older Projects, the Directory Listing feature will be disabled for all Projects that were created before January 12th 2021, which is the release date of the respective Project Setting.
The change will be applied on March 8th 2021.
Because the Directory Listing feature allows for accessing the source code of a Deployment if no index file is present within it, it's safer to disable it by default. If you want, however, you can turn the feature back on right afterwards, if you're relying on it.
Check out the documentation as well.
Node.js 14 LTS is now available
As of today, version 14 of Node.js can be selected in the Node.js Version section on the General page in the Project Settings (newly created Projects will default to the new version).
Among other features, the new version introduces Diagnostic Reports, which can be logged to Log Drains (recommended) like so:
const report = process.report.getReport(); // Similar to process.report.writeReport() output console.log(JSON.stringify(report, null, 2));
The following features were introduced through v8:
The exact version used is 14.15.4 (changelog), but automatic updates will be applied for new minor and patch releases. Therefore, only the major version (14.x) is guaranteed.
Check out the documentation as well.
Correcting Request URLs with Python Serverless Functions
At the moment, the URLs of incoming requests to Python Serverless Functions deployed on Vercel are decoded automatically.
Because this behavior is not consistent with a "standalone" Python server, Vercel will stop decoding them for newly created Serverless Functions starting March 2nd, 2021. Existing Deployments will not be affected.
As an example, take a look at the Python Serverless Function code shown above and imagine that the URL of the incoming request ends in /hi%21:
- With the incorrect behavior,
self.pathwill be set to/hi!. - With the updated correct behavior,
self.pathwill be set to/hi%21, which matches the behavior of the built-inHTTPServerclass in Python.
To try out this change, define a FORCE_RUNTIME_TAG Environment Variable for your project, set it to canary and create a new Deployment.
Projects can now be transferred without downtime
Personal Accounts on Vercel are great for hobby projects. Once you need to deploy more powerful sites, collaborate with other people and customize your workflow, Teams are the right way to go.
Migrating from a Personal Account to a Team previously wasn't possible without incurring downtime. It required removing Projects from their old location and deploying them again in the new one. As of today, it's only a matter of a few clicks on the dashboard.
Transferring projects without downtime is now as easy as navigating to the Advanced page in the Project Settings, following the flow and watching the magic happen.
All Deployments, Domains, Environment Variables, and any other configuration of your Project will automatically be moved to the target Team for you. Even optional features you might've enabled can be transferred over.
Check out the documentation as well.
Node.js Version now customizable in the Project Settings
For easy customization and in preparation for Node.js 14 LTS landing in the future, the General page in the Project Settings now contains a section for defining the Node.js version used in the Build Step and Serverless Functions.
Previously, defining an engines property in the package.json file was required to customize the Node.js version. However, this property will take precedence over the Project Setting.
Check out the documentation as well.
Invoices are now available on a dedicated page
Invoices for your payments on Vercel were previously found in the Past Invoices section of the Usage tab in the Dashboard.
To make it easier to navigate, they have been moved to a dedicated Invoices page alongside Billing in the Personal Account and Team Settings.
Even though the Upcoming Invoice section has been removed with this change, the Billing page in the Personal Account and Team Settings now provides the same insight.
URLs are becoming consistent
A lot of feedback we've gathered has shown that the URLs Vercel currently provides you with are too complicated. As part of our strategy for making them simpler, we're starting with applying a consistent format on February 20th 2021:
- Custom Domains and Automatic URLs ending in
now.shwill instead end invercel.app. - Automatic Deployment URLs like
project-d418mhwf5.vercel.appwill gain the slug of the owner Vercel scope to match Automatic Branch URLs:project-d418mhwf5-team.vercel.app. - Automatic Branch URLs like
project-git-update.team.vercel.appwill lose their second subdomain level in favor of a dash:project-git-update-team.vercel.app. - Automatic Project URLs like
project.team.vercel.appand Automatic Team Member URLs likeproject-user.team.vercel.appwill be adjusted like Automatic Branch URLs.
It is recommended to not rely on any of the Automatic URLs for Production use cases and instead use Custom Domains for that. If that's not possible, please ensure any program sending requests to these URLs supports 308 redirects – like modern browsers do.
Serverless Functions are now deployed to US East by default
Many Serverless Functions communicate with third-party services. Because most of these services are available in the US East region, deploying Serverless Functions to US West leads to slower response times.
For that reason (and to decrease the latency for requests arriving from Europe), newly created projects will default to the US East region (Washington, D.C., USA) instead of US West (San Francisco, USA) when deploying Serverless Functions.
Existing projects will be unaffected, but can be switched to the new default from the new "Serverless Functions" page in the Project Settings.
Check out the documentation as well.
Failed payments can now be retried
If a payment had failed for your Team because of an issue with your payment method, you previously had to reach out to our Support Team and ask them to retry it, so that you could create Deployments again.
Since that's quite a slow process, we instead added a button to the Billing page in your Team Settings that you can click to immediately issue a new charge. If that charge succeeds, your Team will be able to create Deployments again right after.
Changing the payment method will automatically issue a charge too, so this button is particularily helpful if you've fixed an issue with an existing payment method.
Listing the content of directories can now be toggled
Until now, directories used to list the directory's contents whenever their path was visited (provided they didn't contain an index file).
In cases where this was considered a security issue, turning off the Directory Listing required configuring a rewrite rule in vercel.json.
As of today, the Directory Listing is disabled for all newly created Projects and can be toggled on the "Advanced" page in the Project Settings.
Check out the documentation as well.
Git repositories can now be searched for and imported easily
Importing a Git repository into Vercel used to require navigating to it on the Git provider of your choice, copying its URL from the address bar, pasting it in the project creation flow on Vercel and then following the steps.
Thanks to its most recent update, however, the project creation flow now renders a list of recommended Git repositories to import and allows for searching for a particular one as well, annotated with icons for the frameworks that are being used within those Git repositories.
Cloning a Template is now also much easier than before, as they are presented on the same page as the recommended Git repositories.
Check out the documentation as well.
Multiple Git namespaces per Personal Account and Team
When connecting a Project on Vercel to a Git repository, the Git repository previously had to be located in the same Git scope as the Git repositories of all other Projects within that Personal Account or Team.
Now that this connection is defined on the Project-level (see above) instead of being configured on the Personal Account or Team, this limitation is lifted. Additionally, problems with an active connection are now surfaced there too.
Every Personal Account or Team can now contain Vercel Projects that are connected to Git repositories located in various different Git scopes. This also means that, when importing one, Vercel no longer forces a certain destination Personal Account or Team.
Check out the documentation as well.
Environment Variables can now be filtered
Previously, Environment Variables defined in the Project Settings used to be sharded into different Environments using tabs in the UI. To make it easier to add them to multiple Environments at once and edit them like that, however, they now live in a single list.
In order to make it easy for you to still only view the Environment Variables you're interested in, we just added a new search field and a select field on the right that lets you filter the Environment Variables down to a specific Environment.
Build and Function Logs now render ANSI color codes nicely
If the logs that your source code or your framework are exposing within the Build Step or within your Serverless Functions contain ANSI color codes for providing more clarity, Vercel previously directly printed them out in the respective views on the Dashboard.
As of today, however, all of those codes are automatically parsed within the Deployment View, which contains Build Logs on the main page, but also the logs for your Serverless Functions on the "Functions" tab.
In the example above, you can see that ANSI codes are now automatically rendered as the colors they are supposed to represent, which makes the text much easier to understand.
System Environment Variables are now available by default
Previously, consuming values provided by the Vercel platform in your Environment Variables (like the URL of your Deployment) required adding System Environment Variables using the "Environment Variables" page in the Project Settings.
All new Projects created as of today, however, will automatically receive all System Environment Variables by default – without you having to expose them explicitly.
This setting can also be controlled from existing Projects, which means that you can easily opt into the new behavior for those as well.
Furthermore, the available System Environment Variables were revamped to have much more straightforward names and don't differentiate between Git providers anymore. For example, you can now use VERCEL_GIT_COMMIT_REF to retrieve the Git commit SHA for GitHub, GitLab and Bitbucket instead of having to use several different System Environment Variables for that.
Check out the documentation as well.
Projects can now be renamed
For all the Projects you've deployed on Vercel in the past, the platform either automatically selected a name for you based on the name of your Git repository or local directory, or you manually customized it before the Project was created.
Previously, it wasn't possible to change the name of a Project after it was created. As of today, however, you can do it directly from the "General" page in the Project Settings.
When changing the name of your Project, no interruptions in your or your Team's workflow will occur, considering that you're either deploying from a Git repository or you've linked the Project to a local directory using Vercel CLI.
Check out the documentation as well.
Dependencies can now be installed with a custom command
By default, Vercel automatically determines the right command for installing your project's code dependencies in the Build Step based on the Framework Preset configured for your project and the presence of certain files (like package-lock.json) in your source code.
As of today, you can customize the command that Vercel will run within the Build Step for installing your code dependencies.
In the new Install Command section within the Project Settings, you can now enter any command of your choice that will be run instead of having Vercel automatically determine the right one for you.
Check out the documentation as well.
Auto Renewal can now be disabled for Domains
Once you've purchased a Domain with Vercel or transferred it in from a different platform, Vercel will automatically make sure that your Domain is renewed every year – before it expires.
Like this, you never have to worry about your projects becoming unavailable. Instead, you will automatically be charged the renewal fee every year and your Domain will continue working.
Previously, the only way to prevent a Domain from being renewed again (in the case that you don't want to continue using it, for example) was contacting our Support Team, who disabled auto renewal for you.
As of today, you can toggle the auto renewal behavior of a Domain right on the Dashboard by navigating to the "Domains" tab on your Personal Account or Team, clicking the Domain you're interested in and toggling the option on the top right.
Check out the documentation as well.