Skip to content
Docs

Password Protection

Password Protection is available on Enterprise and Pro plans

Those with the owner, member and admin roles can manage Password Protection

Password Protection requires visitors to enter a pre-defined password before they can access your deployment. You can set the desired password from your project settings when enabling the feature, and update it any time.

Deployment protected with Password Protection authentication screen.
Deployment protected with Password Protection authentication screen.

Password Protection pricing depends on your plan and when your team started using the feature:

Plan or billing modelPriceCoverage
HobbyNot availableUpgrade to Pro to enable Password Protection
Pro$20 per month per protected projectThe project where you enable Password Protection
EnterpriseIncludedEvery project through Team Level Password Protection
Existing Pro teams with the legacy Advanced Deployment Protection package$150 per month per teamEvery project through Team Level Password Protection

For project-priced Pro teams, Edgenivo adds the charge when you enable Password Protection for a project. Disabling Password Protection stops future charges for that project. The project's remaining Deployment Protection settings determine who can access its deployments.

See Usage & Pricing for Deployment Protection for the full feature and plan comparison.

The table below outlines key considerations and security implications when using Password Protection for your deployments on Edgenivo.

ConsiderationDescription
Environment ConfigurationCan be enabled for different environments. See Understanding Deployment Protection by environment
CompatibilityCompatible with Edgenivo Authentication and Trusted IPs
Bypass MethodsCan be bypassed using Shareable Links and Protection bypass for Automation, or by callers listed in Trusted Sources
Password PersistenceUsers only need to enter the password once per deployment, or when the password changes, due to cookie set by the feature being invalidated on password change
Password ChangesUsers must re-enter a new password if you change the existing one
Disabling ProtectionAll existing deployments become unprotected if you disable the feature
Token ScopeJWT tokens set as cookies are valid only for the URL they were set for and can't be reused for different URLs, even if those URLs point to the same deployment

You can manage Password Protection through the dashboard, API, or Terraform.

  1. From your Edgenivo dashboard:

    1. Select the project you want to enable Password Protection for
    2. Go to Deployment Protection in the sidebar
  2. From the Password Protection section:

    1. Use the toggle to enable the feature
    2. Select the deployment environment you want to protect
    3. Enter a password of your choice
    4. Finally, select Save

    All your existing and future deployments will be protected with a password for the project. The next time you access a deployment, you'll need to enter the password. After you enter it, a cookie is set in your browser for that deployment URL so you don't need to enter the password again.

    Enabling Password Protection.
    Enabling Password Protection.

You can manage Password Protection using the Edgenivo API endpoint to update an existing project with the following body.

ParameterTypeDescription
deploymentTypestringThe scope of protection. Accepted values are prod_deployment_urls_and_all_previews (Standard Protection), all (All Deployments), or preview (Only Preview Deployments)
passwordstringThe password visitors must enter

To enable or update Password Protection, send the passwordProtection object:

{
  "passwordProtection": {
    "deploymentType": "prod_deployment_urls_and_all_previews",
    "password": "your_password_here"
  }
}

To disable Password Protection, set passwordProtection to null:

{
  "passwordProtection": null
}

You can configure Password Protection using password_protection in the vercel_project data source in the Edgenivo Terraform Provider.

Password Protection checks every request before it reaches your application, including requests from CI jobs, end-to-end tests, and webhooks. Those requests can't enter a password, so they receive a 401 response as soon as you enable protection. Set up Protection Bypass for Automation when you enable Password Protection, and send the secret in the x-vercel-protection-bypass header.

For test runners, add the header to every request and set x-vercel-set-bypass-cookie to true so in-browser navigation doesn't hit the password prompt. See the Playwright and Cypress configurations.

To check the bypass, request a protected deployment with the secret. A 200 response means the bypass works:

terminal
curl -I -H "x-vercel-protection-bypass: $VERCEL_AUTOMATION_BYPASS_SECRET" \
  https://your-deployment.vercel.app

If requests that worked before you enabled Password Protection now return 401, find the matching symptom:

SymptomCauseFix
Cross-origin requests fail because the OPTIONS preflight returns 401Browsers don't send cookies or custom headers with a CORS preflight, so the preflight can't pass protection.Add the API's path prefix, such as /api, to the OPTIONS Allowlist.
A fetch from your own server code to the deployment's URL returns 401The server-side request doesn't include the visitor's authentication cookie.Use the incoming request's origin and forward its cookie header. In the browser, use relative paths. See How to migrate to Standard Protection.
Webhooks from services such as Stripe or Slack return 401, or URL verification failsThe service can't enter a password or send the authentication cookie.Send the bypass secret in the x-vercel-protection-bypass header. If the service accepts only a URL, add the secret as a query parameter.
Requests to an API on a different subdomain return 401 after you enter the passwordThe authentication cookie is valid only for the URL where you entered the password.Call the API on the same origin with relative paths, or send the bypass header from automated callers.
Tests return 401 after you regenerate a bypass secretExisting deployments still use the previous secret value.Redeploy so the deployment uses the new secret.
Last updated September 15, 2026

Was this helpful?

supported.