Encryption and TLS

Every deployment on Vercel is served over an HTTPS connection. Vercel automatically generates SSL certificates for these unique URLs at no cost.

The CDN automatically forwards any HTTP requests to your deployment to HTTPS using the 308 status code:

HTTP/1.1 308 Moved Permanently
Content-Type: text/plain
Location: https://<your-deployment-host>

HTTPS redirection is an industry standard and can't be disabled. This ensures that all web content is served over a secure connection, protecting your users' data and privacy.

​Vercel supports TLS version 1.2 and TLS version 1.3.

​Vercel supports both Session Identifiers and Session Tickets for TLS session resumption. This improves Time to First Byte (TTFB) for returning visitors.

Vercel staples an OCSP response to each TLS handshake. This lets clients skip the network request to check certificate revocation, improving TTFB for first-time visitors.

To protect data integrity, Vercel only supports strong ciphers with forward secrecy.

Supported cipher algorithms:

• TLS_AES_128_GCM_SHA256 (TLS 1.3)
• TLS_AES_256_GCM_SHA384 (TLS 1.3)
• TLS_CHACHA20_POLY1305_SHA256 (TLS 1.3)
• ECDHE-ECDSA-AES128-GCM-SHA256 (TLS 1.2)
• ECDHE-RSA-AES128-GCM-SHA256 (TLS 1.2)
• ECDHE-ECDSA-AES256-GCM-SHA384 (TLS 1.2)
• ECDHE-RSA-AES256-GCM-SHA384 (TLS 1.2)
• ECDHE-ECDSA-CHACHA20-POLY1305 (TLS 1.2)
• ECDHE-RSA-CHACHA20-POLY1305 (TLS 1.2)

This is the recommended configuration from TLSRef.

Vercel offers the X25519MLKEM768 key exchange mechanism during TLS handshakes to protect your deployments against future quantum computing attacks. Your browser negotiates this mechanism automatically if you use:

• Chrome 131 and above
• Firefox 132 and above
• Safari 26 and above

Encrypted Client Hello (ECH) encrypts the Server Name Indication (SNI) during the TLS handshake. The SNI is the one part of an otherwise-encrypted HTTPS connection that still exposes which hostname a visitor is connecting to. With ECH, network observers see a connection to Vercel's shared public name, vercel-ech.com, rather than your domain.

Vercel manages ECH at the platform level and enables it automatically where it's available.

Browsers use ECH when they can read the ECH configuration from your domain's HTTPS DNS record. ECH works in recent versions of Chrome, Edge, and Firefox. When a browser or its DNS resolver doesn't support ECH, the connection falls back to a standard TLS handshake with no loss of security.

The .vercel.app domain (and therefore all of its sub domains, which are the unique URLs set when creating a deployment) support HSTS automatically and are preloaded.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload;

Custom domains use HSTS, but only for the particular subdomain.

Strict-Transport-Security: max-age=63072000;

You can modify the Strict-Transport-Security header by configuring custom response headers in your project.

You can set the max-age parameter to a different value. It controls how long the client remembers that your site is HTTPS-only. Since Vercel doesn't allow HTTP connections, there's no reason to shorten it.

Vercel uses a wildcard certificate issued for .vercel.app to handle all deployment URLs. Vercel generates these certificates through LetsEncrypt and keeps them updated automatically.

When you generate custom certificates with vercel certs issue, Vercel stores the keys in the database and encrypts them at rest within the CDN.

When a hostname is requested, the CDN reads the certificate and key from the database to establish the secure connection. Both are cached in memory for optimal SSL termination performance.

For a complete breakdown, see the SSL Labs report for vercel.com. You can select any IP address — the results are the same for all.