The useful part is the shared system around each prompt
prompts.chat began as a public prompt collection, but the current repository is a full Next.js application. A team can browse prompts, keep some private, track versions, discuss changes, vote, and sort material with categories and tags. The same catalog is available through a web interface, CLI, MCP server, and Claude Code plugin. That breadth is the reason to consider it. If prompts currently live in personal notes and chat histories, this gives them ownership and a place to improve.
The data itself remains easy to inspect. The repository publishes prompt material in Markdown and CSV, while its README points to a Hugging Face dataset. Prompt content is under CC0, and the source code and site-authored material use MIT terms. That split matters for a company that wants to reuse the prompts but does not need the application. You can take the data without adopting 1,536 files and roughly 115,346 lines of source.
Private hosting means running an application, not copying a list
The self-hosting pitch includes custom branding, themes, several sign-in choices, private prompts, comments, change requests, AI search, AI generation, and MCP support. A setup wizard writes much of the configuration. Docker users get a Compose file with PostgreSQL, persistent storage, a health check, and runtime branding variables. This is closer to deploying an internal product than publishing a read-only prompt page.
That distinction should drive the decision. Version history and access control can be useful when prompts affect support replies, research, or repeatable internal work. A three-person group with 20 stable prompts can get the same practical result from a reviewed Markdown directory. prompts.chat earns its operating cost when people need to discover, change, approve, and retrieve prompts through different clients.
What happened when we ran it
Our sandbox install of commit f78a1c5 failed after 157 seconds. The fresh Debian container had 3 CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. The checkout occupied 139.9 MB before installation. We did not reach a build or test run, so there is no defensible result for either step.
The final log is direct about the failure. npm ran the project's postinstall command, prisma generate, and Prisma tried to load its configuration. That configuration calls env("DATABASE_URL"); the variable was absent, so Prisma raised PrismaConfigEnvError and npm exited with code 1. The log does not show a network failure, missing compiler, or broken package. It shows a required database setting at install time.
That behavior clashes with the manual sequence in the self-hosting guide, which places npm install before copying and editing .env. A prepared operator can supply a PostgreSQL URL first. A developer expecting dependency installation to finish before infrastructure configuration cannot. Five CI workflow files and a tests directory are encouraging repository signals, but neither changes the result we measured: the default secret-free install path stopped before those checks.
PostgreSQL and identity are the first production decisions
The manual route requires Node.js 24, npm, and PostgreSQL. The README's quick start offers npx prompts.chat new, while the longer path adds migrations, optional seed data, then a production build. Authentication can use local credentials or outside providers. OAuth and SSO choices bring callback URLs and secrets, and production also needs an explicit auth secret. AI search and generation add an OpenAI-compatible key only when those features are enabled.
Docker Compose removes some assembly by pairing the app with PostgreSQL 17. It does not remove operations. The guide tells you to change the default database password, put the app behind HTTPS, restrict exposed ports, take backups, and update the image. It recommends 2 CPU cores, 2 GB of runtime memory, and 10 GB of disk for production. First builds can need more memory, with the guide suggesting around 4 GB when exit code 137 appears.
The open MCP and Docker reports deserve a trial run
Issue 1205 describes a sharp MCP failure on a self-hosted Docker instance: after Streamable HTTP requests hit /api/mcp, unrelated Next.js routes can start returning 500. The report includes a reproduction and traces the behavior to global Request and Response replacement. That is one report, not our lab result, but it concerns the exact integration that makes the project more useful than a static prompt list. Test it against the image and client you plan to use.
The issue tracker also contains a first-run Docker report where the Next.js build was killed with code 137, plus an older login report for the self-hosted image. The current Docker guide now addresses memory limits and explicit auth configuration. Still, these reports make a staged deployment sensible: bring up the database, confirm registration and sign-in, exercise MCP repeatedly, then check ordinary routes again before inviting a team.
A September push is stronger evidence than the missing release feed
GitHub showed 171,682 stars and 84 combined open issues and pull requests, with the last push dated September 9, 2026. The latest-release endpoint returned 404, so there is no tagged release record to use as an upgrade boundary. The repository is clearly active, but production operators must choose a commit or image tag and record it themselves. Stars tell you the original prompt collection reached a huge audience. They do not prove the current self-hosted application fits your environment.
The choice is fairly clean. Adopt prompts.chat when prompt sharing has become an application problem: private material, revisions, discovery, identity, and access from several AI clients. If you mainly want good examples to read or copy, use the CC0 data or a smaller guide. Our 157-second failure is a warning about setup order, and the open MCP report is a reason to test the feature that may justify running the whole stack.