egghead-next: the Next.js front end behind egghead.io

The front end cannot run without the Rails backend next door

egghead-next is the front end for egghead.io, and the first thing the README establishes is that it is half of a pair. To run the app locally you need a working installation of egghead-rails, which provides the back-end functionality, and the README walks through its own setup instructions. That backend is started from the project root with a foreman invocation.

foreman start -f Procfile.dev

Once that is running, the front end starts with the standard pnpm pair.

pnpm install && pnpm dev

The ordering matters and is stated clearly. This is a real production application rather than a standalone library or starter, and the consequence for an outside developer is that the first hour of setup is spent on credentials and a second repository rather than on the code. The upside is that everything you read in src/ is what serves a live commercial site.

Environment variables are pulled from Vercel rather than typed into a file

The second setup step is the Vercel dance, and it is the part that surprises people who expect a .env file to be committed. You run vercel login, which prompts you to log in and verify, then vercel link, which asks you to pick the eggheadio organisation and the egghead-io-nextjs project, and then vercel env pull, which brings in the development environment variables you need. The repository does hold .env.development and .env.production files, but the documented path for a new developer is to pull the real values from Vercel, which also means you need access to that organisation before you can do anything. For anyone who wants to fork or run this outside the egghead organisation, that is the first obstacle.

A script checks the base toolchain for you

The system-level setup is delegated to a script rather than a list. For the base requirements such as Homebrew, Node and pnpm, the README says to run bin/validate, which checks that you have what is needed and helps install anything missing. That is a nicer pattern than a wall of install instructions, and it fits a project that has more moving parts than a typical Next.js app. The package.json also pins the runtime, with engines requiring Node 22.x, and the repository carries .node-version and .nvmrc files so that the expected version is written down in three places. There is a preinstall hook that runs npx only-allow pnpm, so an npm install is refused rather than silently producing a broken lockfile.

The script surface tells you what the app is made of

The package.json scripts section is a good map of the stack. The core is next dev and next build with next start for production, and there is a separate dev-build path that sets NODE_ENV=production for the build step. A prebuild step runs make-tags-sitemap, which invokes a node script called tags-sitemap.js, and a postbuild runs next-sitemap, so there are two sitemap generators in the chain, one for tags and one general. A concurrent dev script exists to run several dev processes at once, including an inngest dev server pointed at a local API route, which tells you the app runs background jobs through Inngest. Styling is Tailwind with a build:style script compiling src/styles/index.css to an output file, and PostCSS sits alongside it.

The test layer runs Jest, Cypress and Storybook, with a 100 percent statement bar

Testing is unusually thorough for a front end, and the configuration shows the intent. The test script is jest --watch for local work, while test:ci runs Jest in CI mode with a custom JSON reporter, and there is a separate check-coverage-limits script that runs nyc report with --check-coverage and a statements threshold of 100, which means the build fails if statement coverage drops below complete. End to end tests use Cypress, with cy:open to open the interactive runner and an e2e script that starts the app on port 3000 and launches it, and a pree2e hook that clears the coverage and .next directories. Storybook is set up too, on port 6006, with separate dev and build commands, so individual components can be reviewed in isolation. The repository carries jest.config.js, cypress.json, a cypress/ directory, a jest/ directory and setupTests.ts.

Prisma, MDX, Sanity and a content toolchain for a course site

The dependencies describe an editorial site rather than a generic app. Prisma is present with a prisma/ directory at the root and a postinstall script that runs prisma generate, so the data layer is generated from a schema as part of install. The topics list MDX alongside React, Next.js and Tailwind, and the format script covers .md and .mdx files, so lessons are authored as MDX content. There is a next-sitemap.js and a tags-sitemap.js for search engine coverage, an rtl.setup.js suggesting right to left support is handled at the top level, and eslint-plugin-groq in the dependency list points to a structured content backend with a Groq query layer. The .storybook/ directory, a .hive/ directory, a .cursor/ directory and an ai/ directory round out a repository that has accumulated tooling alongside the app itself.

Stripe testing needs three separate secrets, which is where new developers get stuck

The README has a dedicated section for the case where you need to test something that requires Stripe webhooks, and the instruction is to use the stripe listen command, with the details in a webhook document in the egghead-rails repository. The section then lists the three values that have to be correct, and it is worth following exactly. STRIPE_WEBHOOK_SECRET is provided by the stripe listen command in egghead-rails, which displays a 90-day secret that it generates automatically for connecting webhooks. NEXT_PUBLIC_STRIPE_PUBLIC_KEY and STRIPE_SECRET_KEY come from the Stripe Development API Keys page. And the webhook_signing_secret has to be updated in the egghead-rails config/credentials.yml.enc file, with the editing instructions in a credentials document in that repository. Four values, two repositories, one encrypted credentials file, and a 90-day secret that expires.

Editorial conclusion

egghead-next fits a developer who wants to work on a real commercial Next.js codebase or needs a reference for a content-heavy storefront with MDX lessons and a Rails API, since the setup path is documented step by step and the tooling is current. It is a poor fit for a standalone project because the front end cannot run without egghead-rails, and a poor fit if you need to self-host, since the environment variables are pulled from Vercel. Verify first that you have access to the eggheadio Vercel organisation and to the egghead-rails credentials, since vercel link and vercel env pull are both required before the app will start, and check the Stripe webhook secret values if you are testing purchase flows.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. skillrecordings/egghead-next on GitHub