Clerk fails to get the publishable key from the environment variables in Next.js 13

[Tsabary]

I have a site I've built with Next 13 (experimental app directory) and have integrated authentication in my site with Clerk.

Everything works well on my local environment. When deployed to Netlify, it builds just fine, but if I try to visit the site it doesn't load, and in the console I see the following error:

@clerk/nextjs: Missing publishableKey. You can get your key at https://dashboard.clerk.com/last-active?path=api-keys.
    at Object.throwMissingPublishableKeyError

I do have my publishable key in my environment variables in Netlify under NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY. I've also placed it under CLERK_PUBLISHABLE_KEY just in case.

Also, does it supposed to get scoped automatically by some clerk code? Because in my code I don't really use that variable anywhere and don't see the documentation telling me I need to.

This is my publishable key environment variable:
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_ZXZvbHZpbmctY29sdC01Ni5jbGVyay5hY2NvdW50cy5kZXYk

I'm building a Next app using the experimental app directory.

This is my package.json

{
    "name": "open-cards",
    "version": "0.1.0",
    "private": true,
    "scripts": {
        "dev": "next dev -p 3005",
        "build": "next build",
        "start": "next start",
        "lint": "next lint"
    },
    "dependencies": {
        "@clerk/nextjs": "^4.16.4",
        "@types/node": "18.15.13",
        "@types/react": "18.0.37",
        "@types/react-dom": "18.0.11",
        "autoprefixer": "10.4.14",
        "eslint": "8.38.0",
        "eslint-config-next": "13.3.0",
        "flowbite": "^1.6.5",
        "flowbite-react": "^0.4.4",
        "mongodb": "^5.3.0",
        "mongoose": "^7.0.4",
        "next": "^13.3.1-canary.4",
        "postcss": "8.4.23",
        "react": "18.2.0",
        "react-confetti": "^6.1.0",
        "react-dom": "18.2.0",
        "react-use": "^17.4.0",
        "socket.io-client": "^4.6.1",
        "tailwindcss": "3.3.1",
        "typescript": "5.0.4",
        "uuid": "^9.0.0",
        "webpack-node-externals": "^3.0.0"
    },
    "devDependencies": {
        "@types/uuid": "^9.0.1"
    }
}

Using windows and trying to run the site using Chrome/Brave

[bradhaydon]

Try updating your @clerk/nextjs gem to ^4.18.1.

[dimkl]

@Tsabary have you tried upgrading to latest nextjs and @clerk/nextjs ?

[tchanxx]

+1 having this issue. I have my keys set in GitHub for using it in GitHub actions and it fails with the same error when building in the GH Action environment, but not locally when the environment variables are in my .env.

Using "@clerk/nextjs": "^4.19.1" and "next": "13.4.4"

[dimkl]

@tchanxx could you share a repo that reproduces the issue?

[JayFranco]

Hi @dimkl, I'm having the same issue. I'm not used to contribute but if it helps I've made my repository public and shared it here: https://github.com/JayFranco/clerk-issue

[mpassad]

i had that same problem and fixed it that way

https://stackoverflow.com/a/76482787/3246566

[dimkl]

This resolves some issues with Netlify deployments I had trying to reproduce the issue:
https://answers.netlify.com/t/next-js-app-directory-some-pages-are-500-internal-server-error-on-deployment/93203/6

Setting the NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY in Environment Variables for All Scopes and using the following snippet works for me: https://clerk.com/docs/nextjs/get-started-with-nextjs#mount-clerk-provider

Could you take a look at the above (especially the scopes of environment variables and the import of ClerkProvider from @clerk/nextjs) and let me know if the issue is resolved.

Testing application: https://lambent-crostata-7a1f0c.netlify.app/

[clerk-cookie]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[clerk-cookie]

This issue was closed because it has been stalled for 10 days with no activity.

[clerk-cookie]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.