Chirpy: a self-hostable Disqus alternative with anonymous sign-in

The pitch is a comment system you control instead of one you rent

Chirpy describes itself as a privacy-friendly and customizable Disqus alternative, and the site lives at chirpy.dev with a playground you can try before committing. The audience is site owners, mostly on static or Next.js blogs, who are uneasy about a third-party comment platform tracking their readers across sites and who want to change the look of the comment box without forking a theme. The feature list is what you would expect from a hosted comment product, and it is broad. There is a customizable widget, rich text formatting with markdown shortcuts, real-time comments, mobile friendly layout, email and web push notifications, comment moderation, widget analytics, and a site notification mechanism. Two features stand out as the actual differentiation from Disqus. The first is anti-toxic comment handling, which is offered as a first-class feature rather than something you bolt on with a moderation plugin. The second is sign-in: the project offers both anonymous sign-in and email or magic link sign-in, so a reader can comment without creating a password and without handing over a third-party identity. Privacy here is a design constraint on the sign-in path, not just a marketing word on the badge.

The repository is a pnpm and turbo monorepo with several applications

The top level of the tree explains the shape of the project. There is a pnpm-workspace.yaml and a pnpm-lock.yaml, a turbo.json for task orchestration, an apps directory, a packages directory, a patches directory, a .changeset directory for versioning, and the usual tooling files including .eslintrc.js, .lintstagedrc.js, .prettierignore and a .husky directory for git hooks. The package.json is marked private, which is the correct setting for a workspace root, and its scripts show how the pieces fit together.

    "bootstrap": "cd apps/bootstrapper && pnpm build && cd ../service-worker && pnpm build && cd ../../packages/trpc && pnpm generate",
    "dev": "cd apps/main && pnpm run dev",
    "build": "turbo run build --filter=@chirpy-dev/main-app...",
    "release": "turbo run build && changeset publish",
    "test": "turbo run test --filter=@chirpy-dev/main-app...",

The bootstrap script builds three things in sequence, the bootstrapper application, the service worker, and the generated client for the packages/trpc package, which tells you the tRPC type generation is a required step rather than an optional convenience. The build and test scripts filter turbo tasks to the main app and its dependents, so the monorepo is structured to let a package be tested independently while the main application remains the integration target. The service worker being a separately built artefact is worth noting for anyone reasoning about how the widget behaves in a browser.

The stack is Next.js with tRPC, Prisma, TipTap and Tinybird

The technology section lists TypeScript, Next.js, tRPC, Prisma, TailwindCSS, Jest, next-auth, tiptap and Tinybird, and each choice maps to a visible part of the product. Next.js with Tailwind is what makes the widget themable rather than fixed, since the widget theme documentation shows a theming page and the design system draws its colours from radix color with the home hero section inspired by stitches. TipTap is the rich text editor behind the formatting and markdown shortcut support, which is why the comment composer is not a plain textarea. Prisma is the data layer, and the v0.3.0 release is titled Migrate DB to postgresql, which tells you the ORM sits on PostgreSQL rather than on a hosted service with its own data model. tRPC carries typed calls between the Next.js app and the API, with the generated client in packages/trpc. Tinybird is the analytics backend behind the widget analytics feature. next-auth handles the identity side, which is where the email and magic link sign-in options come from, and Jest is the test runner wired through the turbo test task.

Deploying it means Vercel, and the repository ships the configuration

The hosting section shows a Vercel badge for the project, and the Vercel deployment badge in the README points at the production deployments for the repository, so the maintainer runs the hosted version on Vercel and the same repository is what you would fork to run your own. The repository includes a Dockerfile in the tree, alongside apps/, packages/ and the patches directory, so a container deployment is at least conceivable, though the README does not describe a container workflow and does not document environment variables, migration steps or a production configuration in any detail. That absence matters if you plan to self-host. The documentation site links in the README cover the widget theme, markdown support, analytics, notifications, anti-toxic comments, moderation, and the privacy pages for anonymous sign-in and email sign-in, so the feature behaviour is described there rather than in the repository. The honest summary is that the code is open and the deployment is straightforward on the platform the maintainer uses, while the operational details for anything else are undocumented in what is available here.

Release history is thin, and the roadmap shows payments were dropped

The release list deserves a careful reading. The most recent named releases are @chirpy-dev/[email protected] dated 2024-10-30, v0.3.0 dated 2024-04-01 with the title Migrate DB to postgresql, and v0.2.0 dated 2022-11-19. So the substantive application releases stopped in 2024, while the bootstrapper package, which the bootstrap script builds, is the most recent tagged thing and it was tagged in late 2024. The repository itself is not archived and the last push was on 2026-10-20, so work is still landing in the tree, but the version tags do not tell you which of those pushes are user visible. The roadmap section is short and unusual, since it lists more custom options as remaining work while striking through both the account plan and payment entries, which reads as those two having been dropped rather than completed. The README does say Chirpy is ready to serve you and your users, and the hosted playground supports that, but for an operator the gap between the last tagged version and the current main branch is something to plan for rather than gloss over. The changesets directory is a good sign here, because it means pending version bumps are recorded as pull requests rather than applied by hand.

AGPL-3.0 is the licence to read before you deploy

The README states the licence as AGPL 3.0, and the package.json agrees with AGPL-3.0-or-later, which is the SPDX identifier for the same grant. The AGPL is copyleft and it reaches further than the MIT or Apache licences that most web projects use, because it covers use over a network rather than only distribution of the source. In practice that means the obligations attach when you run a modified version of Chirpy as a service for other people, not simply when you download it. For a site owner who installs it, configures a theme and embeds the widget on their own blog, the copyleft question is generally not the blocker. It becomes the blocker when you fork it, change it, and offer it to others, or when you build a commercial product around it. The README also points to another product from the same author, Quotion, for turning Apple Notes into blog posts, which tells you the project sits inside a small commercial operation rather than being a community foundation project. Anyone evaluating Chirpy for a commercial site should read the LICENSE file directly rather than relying on the summary here, and the README does not describe any paid tier, since the plan and payment roadmap entries have been struck through.

Chirpy against a self-hosted comment server and against plain hosted comments

The realistic alternatives split in two directions. One is to run a self-hosted comment system on your own infrastructure and give it a shared database with your site, which removes the SaaS dependency entirely and gives you full control of the data, at the cost of running a service, a database and an upgrade path yourself. The other is to stay with a hosted comment platform and accept the tracking and the feature set you get. Chirpy sits between those two, and the difference in approach is mostly operational. Against the self-hosted option, Chirpy removes the hosting work and the database administration, and the release history above shows why that matters, since a project with a thin release stream is one you would rather not be responsible for operating. Against the hosted option, it gives you a widget theme you control, moderation and anti-toxic handling in one place, and sign-in that does not require a reader to have a Disqus identity. What it does not give you is the ecosystem. A long established comment platform has plugins, migration tooling and a large base of site owners who have already solved the edge cases, and Chirpy's feature list, while broad, is the list of one product rather than of a platform. For a blog with a modest comment volume, that trade is usually worth taking.

Editorial conclusion

Adopt Chirpy if you run a site that currently depends on Disqus or on a hosted comment service, want comment data you can hold yourself, and need anonymous or magic link sign-in so readers are not pushed into an account. Skip it if you need a mature plugin ecosystem or established moderation tooling, since the recent release history here is thin. Verify first which release you are deploying, whether the v0.3.0 database move to PostgreSQL matches your schema, and that the AGPL-3.0 terms fit your deployment model before you expose the service publicly.

Frequently asked questions

Official sources

1. devrsi0n/chirpy on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases