Vercel Error: Public Framework Prefix Cannot Use visibility: secret

If Vercel shows an error like:

Environment variables with a public framework prefix cannot use visibility: secret. Use visibility: config instead.

the important clue is the phrase public framework prefix.

Vercel now separates environment variables into two visibility types:

• Config — values remain readable to authorized project members
• Secret — values are write-only after saving and are intended for sensitive credentials

At the same time, frontend frameworks use prefixes such as NEXT_PUBLIC_ to mark variables that are intentionally exposed to browser-side code.

Those two ideas conflict if you try to mark a public-prefixed variable as Secret.

Quick fix

If the variable is intentionally public, keep the public prefix and use Config.

For example:

vercel env add NEXT_PUBLIC_API_URL production \
  --value "https://api.example.com" \
  --visibility config \
  --yes

If the value is actually sensitive, remove the public prefix and keep it as Secret:

vercel env add API_KEY production \
  --value "sk_live_..." \
  --visibility secret \
  --yes

The rule is simple:

Public framework prefix → Config

Sensitive server-only value → Secret, without a public prefix

Why Vercel blocks this combination

Frameworks such as Next.js use prefixes to identify values that may be exposed to browser code.

For Next.js, that prefix is:

NEXT_PUBLIC_

A variable such as:

NEXT_PUBLIC_SUPABASE_URL=...

is meant to be available to client-side code.

That means it should not be treated as a hidden server-only secret.

Vercel's current environment-variable model reflects that distinction. Its August 2026 update introduced Config and Secret types:

• Config is for non-sensitive values you may need to inspect later, including variables with a public framework prefix.
• Secret is for passwords, API keys, tokens, and other values that should not be readable after saving.

So this is valid:

NEXT_PUBLIC_API_URL
visibility = config

This is not:

NEXT_PUBLIC_API_URL
visibility = secret

The most important security question

Do not solve this error by automatically changing every variable to Config.

First ask:

Should this value actually be public?

If the answer is yes, use the framework prefix and Config.

If the answer is no, remove the public prefix and keep it server-side as Secret.

That distinction matters much more than the error itself.

Example: Supabase on Next.js

A common case is Supabase.

Browser-side Supabase configuration may look like:

NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=sb_publishable_...

These are intended for public client configuration.

For that kind of value, Config is appropriate.

A privileged server-side key is different:

SUPABASE_SECRET_KEY=...

That should stay server-side and should not be renamed to:

NEXT_PUBLIC_SUPABASE_SECRET_KEY=...

just to satisfy a client-side integration.

That would turn a configuration error into a security problem.

Correct CLI examples

Vercel documents the --visibility flag for both adding and updating environment variables.

Public client configuration

vercel env add NEXT_PUBLIC_SITE_URL production \
  --value "https://example.com" \
  --visibility config \
  --yes

Server-side secret

vercel env add API_SECRET production \
  --value "super-secret-value" \
  --visibility secret \
  --yes

Update a public variable to Config

vercel env update NEXT_PUBLIC_SITE_URL production \
  --visibility config

Update a private variable to Secret

vercel env update API_SECRET production \
  --visibility secret

If you are using an integration or API rather than the CLI, the same principle applies: public framework-prefixed values should be created as Config rather than Secret.

Why this error may appear suddenly

This error can show up even if an older project previously worked.

Vercel changed the environment-variable model in August 2026 from the older Sensitive toggle to explicit Config and Secret types.

Existing sensitive variables continue to work, but when you create or update variables through newer dashboard, CLI, API, or integration flows, visibility is now part of the validation.

That can expose an older mismatch such as:

• a NEXT_PUBLIC_ variable being treated as secret
• an integration creating public variables with Secret visibility
• an automation copying a sensitive-variable setting onto every variable
• a migration script applying one visibility type to both public and private values

The application code may be fine.

The environment-variable metadata is what needs to change.

How to decide between Config and Secret

Use this table:

| Variable example | Browser-visible? | Recommended type | | --- | --- | --- | | NEXT_PUBLIC_SITE_URL | Yes | Config | | NEXT_PUBLIC_SUPABASE_URL | Yes | Config | | NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY | Yes | Config | | API_BASE_URL used only on server | No | Config or Secret depending on sensitivity | | DATABASE_URL | No | Secret | | API_SECRET | No | Secret | | SUPABASE_SECRET_KEY | No | Secret |

The prefix is only one clue.

The real question is whether the value is safe for client exposure.

What if Vercel says to remove the public framework prefix?

You may also see wording like:

Remove the public framework prefix to keep this value private. Public prefixes expose values to the browser. If that’s safe, change the variable to Config.

That message gives you two valid paths.

Option 1: The value is safe for the browser

Keep the public prefix and change the type to Config.

Option 2: The value is sensitive

Remove the public prefix, update your code so the value is used only on the server, and keep it as Secret.

Do not choose based on which option makes the warning disappear fastest.

Choose based on where the value should be allowed to exist.

Check your framework prefix

Vercel documents framework-specific public prefixes.

For Next.js, public client values use:

NEXT_PUBLIC_

Other frameworks use different prefixes.

If you copied an environment-variable name from another framework, verify that the prefix actually matches your project's Framework Preset.

A wrong prefix can create a different class of deployment bug even after the Config/Secret error is fixed.

If an integration created the variable

This error can come from integrations as well as manual CLI use.

If a Vercel Marketplace integration is creating the variable:

1. identify which variable triggered the error
2. check whether its name has a public framework prefix
3. decide whether the value is genuinely public
4. if public, configure it as Config
5. if private, remove the public prefix and keep it Secret
6. resync or reconnect the integration if it continues to send the wrong visibility

Do not create a second duplicate variable unless you understand which one the application actually reads.

Redeploy after fixing the variable

Changing an environment variable does not change deployments that already exist.

Vercel states that environment-variable changes apply only to new deployments.

After correcting the visibility:

1. save or update the variable
2. create a new deployment
3. confirm the new deployment completed successfully
4. test the feature that uses the variable

If you keep testing an older deployment, it may still contain the previous configuration.

A practical troubleshooting sequence

When I see this error, I would check these in order:

1. What is the exact variable name?
2. Does it use a public framework prefix such as NEXT_PUBLIC_?
3. Should that value really be visible to browser code?
4. If yes, set visibility to Config.
5. If no, remove the public prefix and keep it Secret.
6. Check whether an integration is recreating the wrong visibility.
7. Redeploy.
8. Test the new deployment.

This avoids the two most common mistakes:

• treating public client configuration like a secret
• exposing a real secret just to satisfy the framework

Official Vercel references I checked

I verified this guide against Vercel's current documentation:

• Environment variables now use Config and Secret types
• Framework environment variables
• Environment Variables
• vercel env CLI reference

The key rule from those docs is consistent:

Public framework-prefixed values belong in Config. Secret is for values that should remain private.

FAQ

Why can't I use visibility: secret with NEXT_PUBLIC_?

Because NEXT_PUBLIC_ tells Next.js that the value can be exposed to browser-side code, while Secret is intended for sensitive values that should remain private.

Should NEXT_PUBLIC_SUPABASE_URL be Config or Secret?

Config. A browser-side Supabase project URL is public client configuration.

Should a Supabase secret key use NEXT_PUBLIC_?

No. Keep a Supabase secret key server-side and do not give it a public framework prefix.

What does visibility: config mean in Vercel?

Config values remain available to deployments and can still be viewed later by authorized members with access to the project.

What does visibility: secret mean?

Secret values are available to deployments but are not retrievable after saving. They can be replaced, but not read back.

Do I need to redeploy after changing visibility?

Yes. Environment-variable changes apply to new deployments, not deployments that already exist.

Final thought

This error is not really about syntax.

It is Vercel forcing you to answer a security question:

Is this variable public client configuration, or is it a private secret?

If it is public, use the framework prefix and Config.

If it is private, remove the public prefix and keep it Secret.

That separation makes the deployment configuration clearer and safer.

If Vercel instead says “Failed to verify the project’s public environment variable prefix”, use my public framework prefix verification guide.

If the issue is broader and variables work in one environment but not another, see Vercel Preview vs Production Environment Variables.

For general troubleshooting, use Vercel Environment Variables Not Working? 7 Fixes to Try.

Practical AI. Real Experience. Built in Public.