code100x cms: the Next.js and Prisma backend behind 100xDevs

A community CMS, not a general-purpose one

This repository is the source behind a specific site rather than a reusable content system. The README calls it the open source repo for app.100xdevs.com, and the presence of a `prisma/` directory with a seed file, a Discord bot token, a guild id, cohort-specific Discord credentials and a job board auth secret in the environment template makes the shape of the product clear: it is a community platform with video, Discord integration and a job board, not a generic headless CMS. The primary language is TypeScript, the licence is MIT, the package is marked private at version 0.1.0, and the project is not archived with the last push on 2026-07-24. The repository has no GitHub releases, so there is no versioned history to track and the deployed site runs from the main branch.

Next.js with Prisma over PostgreSQL

The stack is visible in the package manifest. The framework is Next.js with `next dev`, `next build` and `next start` as the three core scripts, and the data layer is Prisma with `@prisma/client` at version 5. The schema and migrations live in the `prisma/` directory, and the seed is a TypeScript file run with `ts-node` under a CommonJS compiler option, which is why the seed script in the manifest carries that explicit override. The UI is Radix UI primitives for accordion, avatar, dialog, dropdown menu, label, navigation menu, popover, radio group, scroll area, separator, slot, switch and tooltip, with `@tabler/icons-react`, `@uiw/react-markdown`, Tailwind and a `components.json` that points at the shadcn-style component setup. Form handling uses `@hookform/resolvers`. The interesting part for anyone reading the code is the data model: the schema in `prisma/` is the real spec of what this CMS stores, and the seed script shows what a populated instance looks like.

Sign-in through Discord, GitHub and NextAuth

Authentication is multi-provider and the environment file shows the whole surface. NextAuth is configured with `NEXTAUTH_URL` and `NEXTAUTH_SECRET`, Discord sign-in uses `DISCORD_ACCESS_KEY`, `DISCORD_ACCESS_SECRET` and `DISCORD_REDIRECT_URL` pointing at the app's own redirect path, and GitHub sign-in uses `GITHUB_ID` and `GITHUB_SECRET`. There is a `LOCAL_CMS_PROVIDER` switch and a `LOCAL_CMS_PROVIDER = true` value in the template, alongside `APPX_AUTH_KEY`, `APPX_CLIENT_SERVICE` and `APPX_BASE_API` for another service integration. The Discord side is not just an OAuth provider: `BOT_TOKEN` and `GUILD_ID` suggest the app acts as a bot inside a server, and there is a separate set of cohort-specific Discord credentials for a later cohort. `ADMINS` holds a comma separated list of admin addresses, and `ADMIN_SECRET` is a separate secret from the session secret.

The environment file is the real configuration surface

The `.env.example` file lists about thirty variables, and reading it tells you what the application actually depends on. Besides the auth secrets there are `NEXT_PUBLIC_BASE_URL_LOCAL`, `SUBTITLE_SECRET`, `CACHE_EXPIRE_S = 10`, `REDIS_URL`, `NEXT_PUBLIC_DISCORD_WEBHOOK_URL` and `NEXT_PUBLIC_DISABLE_FEATURES` which takes a comma separated list of feature names. The `NEXT_PUBLIC_` prefix is the tell: those values are compiled into the client bundle, so `NEXT_PUBLIC_BASE_URL_LOCAL`, `NEXT_PUBLIC_DISCORD_WEBHOOK_URL` and `NEXT_PUBLIC_DISABLE_FEATURES` are visible to the browser and must not hold secrets, while `JWT_SECRET`, `NEXTAUTH_SECRET` and the provider keys are server-only. One line is a warning in disguise: the comment above `DATABASE_URL` says not to change it for running with Docker, because the compose file injects its own value.

Two ways to get it running locally

The README documents an instant Docker path and a traditional one. The instant path runs a setup script, and the script needs to be executable first:

chmod +x setup.sh
./setup.sh

The note is that your Docker daemon has to be online. The traditional path starts a PostgreSQL container, which is optional but convenient:

docker run -d \
--name cms-db \
-e POSTGRES_USER=myuser \
-e POSTGRES_PASSWORD=mypassword \
-e POSTGRES_DB=mydatabase \
-p 5432:5432 \
postgres

That matches the `DATABASE_URL` template value exactly, which is the point of the sample credentials. From there the sequence is copy `.env.example` to `.env`, install, migrate, generate, seed and start:

pnpm install
pnpm prisma:migrate
pnpm prisma generate
pnpm db:seed
pnpm dev

The app then serves at http://localhost:3000. The package manager is pnpm only, and that is enforced rather than merely recommended, because the `preinstall` script runs `npx only-allow pnpm` and fails the install otherwise.

The compose file shows how the two services talk

The `docker-compose.yml` in the repository is a compact description of the deployment topology. There are two services, `app` and `db`. The app is built from `Dockerfile.dev` with a build argument for `DATABASE_URL` set to `postgresql://postgres:postgres@db:5432/cms?schema=public`, and the same value is set in the runtime environment alongside `NEXT_WEBPACK_USEPOLLING=1`, which is the flag that makes the dev server notice file changes on a mounted filesystem. Two ports are published, `3000:3000` for the app and `5555:5555`. The app depends on the database with `condition: service_healthy`, and the healthcheck is `pg_isready` against the configured database and user every ten seconds with a five second timeout and five retries. The database service is `postgres:alpine` with a named volume for its data directory, so the data survives a container rebuild.

Production image and the script surface

The production Dockerfile is separate from the development one, and the difference is instructive. It starts from `node:20-alpine`, installs pnpm globally with `npm install -g pnpm`, copies the source in, runs `pnpm install`, then runs `prisma generate` and `pnpm run build` with `DATABASE_URL` supplied as a build argument each time. Exposing the database URL at build time is a consequence of the way the Prisma client is generated, and it means the value baked into the build has to match the one the container runs with. The command is `pnpm run start`. The package manifest also carries a set of developer scripts that describe the intended workflow: `lint:check` and `lint:fix` run ESLint with `--max-warnings 0` against the `.eslintrc` config, `format:fix` and `format:check` run Prettier over TypeScript, TSX and JSON, `db:reset` runs `prisma migrate reset`, `studio` opens Prisma Studio, and `dev:docker` chains the migrate, seed and studio commands in the background with `next dev`.

Editorial conclusion

Adopt code100x/cms if you want a working reference for a Next.js App Router CMS with Prisma migrations, seed data, NextAuth sign-in and Radix UI, or you intend to self-host app.100xdevs.com. Skip it if you need a general-purpose headless CMS, since the model, routes and Discord integration are all specific to this community site. Before running it, copy .env.example to .env and fill in at least DATABASE_URL, NEXTAUTH_SECRET, JWT_SECRET and ADMIN_SECRET, note that the pnpm-only policy is enforced by a preinstall hook, and remember the shipped test accounts exist only because the seed script creates them.

Frequently asked questions

Official sources

1. code100x/cms on GitHub
2. Issues
3. License: MIT
4. Project website
5. README