Best Boilerplates for Community and Forum Apps in 2026

TL;DR

Forem (AGPL) is the best open source community platform for developer-focused communities — powers dev.to at scale and includes moderation, notifications, and organizations out of the box
Discourse self-hosted is the best option for forum-style communities that need a proven moderation system, plugin ecosystem, and trust levels
Custom Next.js community builds are justified only when deep integration with a SaaS product is required or white-labeling is the product itself
Real-time features for custom communities are best handled with Pusher or Ably for simple pub/sub; Liveblocks for more structured presence
Community success is a product problem more than a technical problem — the features that drive retention are moderation quality, email digests, and reputation systems, not the tech stack

Community Product Types

"Community" is an overloaded term that describes products with radically different technical requirements. Getting clarity on which type you're building determines almost every architectural choice.

Creator communities (Patreon-style) are organized around a single creator or brand. Members pay a subscription to access exclusive content, direct interaction with the creator, and early access to products. The community aspect is secondary to the creator relationship — members are primarily there because of the creator, not each other. Technical requirements: subscription billing, gated content by tier, direct message or AMA features, content scheduling. Tools like Circle.so and Memberful handle this use case with minimal custom development. Custom builds make sense when the community is deeply integrated with a product (a SaaS tool whose paying customers form the community).

Developer communities (forum-style) are peer-to-peer knowledge networks. Members help each other, share projects, discuss technical topics. The value is bidirectional — anyone can be both a question-asker and an answer-giver. Technical requirements: threaded discussions, markdown formatting, code syntax highlighting, reputation/upvote systems, search across all content, tagging and categories. Discourse and Forem are purpose-built for this pattern and handle the edge cases (spam, moderation, notification fatigue) that custom builds underestimate.

Team communities (Slack-like) are real-time, channel-based communication for a specific group. These are closer to chat products than forums. The defining characteristic is ephemeral, real-time messages — not the threaded, searchable, permanent discussion style of forums. Technical requirements: WebSocket connections, typing indicators, message history, file sharing, channel permissions. Building a real-time chat product from scratch is a significant undertaking; most teams use Slack, Discord, or deploy an open source option like Rocket.Chat or Mattermost.

Course communities (learning platforms) are attached to educational products and serve a specific cohort — people who purchased a course or enrolled in a program. The community is a retention mechanism for the learning product, not the product itself. Technical requirements: integration with course progress (badge a user who completes module 3), cohort-based access control, assignment submission, peer review. This specialization makes course communities poor fits for general-purpose forum software.

Understanding which type you're building prevents the expensive mistake of over-engineering (building a real-time Slack-like system when users actually want a forum) or under-engineering (choosing Discourse for a creator community that needs Stripe billing and tiered access control).

Build vs Platform Decision

Like course platforms, evaluate building vs existing solutions:

Platform	Cost	Customization	Best For
Slack	Free-$8/user	Low	Team communities
Discord	Free	Medium	Gaming, developer communities
Circle.so	$89-$399/mo	Medium	Creator communities
Discourse	$100-$300/mo	High	Forum-style communities
Custom	Dev cost	Complete	White-label, niche requirements

Build custom when: white-labeling is the product, deep integration with your SaaS is required, or Discourse/Circle pricing doesn't work at your scale.

Quick Comparison

Starter	Price	Real-time	Moderation	Payments	Best For
Forem	Free	✅ Notifications	✅	❌	Dev.to-style community
Discourse	Free (self-host)	✅ WebSocket	✅	✅ Plugin	Forum communities
Liveblocks starter	Free	✅ Real-time	Manual	Manual	Real-time community
T3 + custom	Free	✅ Pusher/Ably	Manual	Stripe	Fully custom

Forem — Best Open Source Community Platform

Price: Free (AGPL) | Creator: Forem team (dev.to creators)

Powers dev.to — 2M+ users. Full-featured community platform: posts, comments, reactions, tags, series, notifications, organizations, badges, and moderation tools.

Built on: Ruby on Rails + React. Strong community, active development, and deployment guides for self-hosting on Heroku, Railway, or AWS.

Choose if: You want a proven, full-featured community platform that's been tested at scale.

Forem's Docker Compose setup is the fastest path to a running instance. The official Forem documentation covers the self-hosting steps, but the practical path in 2026 is: clone the repository, copy .env.example to .env, configure your database (PostgreSQL) and object storage (AWS S3 or compatible), and run docker-compose up. First-time setup including DNS configuration and SSL typically takes 2-4 hours. For production deployments, the Forem team recommends a minimum of 2GB RAM — the Rails + React stack is not lightweight.

Customization in Forem is primarily through the admin panel, not code changes. The brand color, logo, tagline, community description, and email templates are all configurable without touching the codebase. For deeper customization (custom pages, modified layouts, additional features), you'll fork the repository and maintain a diff against upstream. The AGPL license means any modifications you make to Forem's code and deploy as a service must be released as open source — a constraint that makes Forem appropriate for communities where the platform itself is not your business moat, but less appropriate for building a differentiated commercial community product.

The architecture lessons from dev.to are embedded in Forem's design. Caching at multiple layers (Russian doll caching in Rails for feeds, Redis for sessions and real-time), background jobs for notifications and email sends (Sidekiq), and a read-optimized feed generation algorithm handle the "celebrity post" problem where a single popular post from a high-follower user needs to be delivered to hundreds of thousands of subscribers without blocking the application. These architectural choices come for free when you adopt Forem.

Discourse — Best Forum Platform

Price: Free (self-host) / $100-$300/month (Discourse Hosted) | Creator: Discourse team

Discourse is a Ruby on Rails forum application that has been the gold standard for developer and open source community forums since 2013. Its trust level system, plugin ecosystem, and moderation tools are more mature than any other open source alternative.

The self-hosting setup has been streamlined considerably since Discourse's early days. The official Docker-based install script handles the full setup — PostgreSQL, Redis, Nginx with SSL via Let's Encrypt, and Sidekiq background workers — in a single-server Docker Compose deployment. The recommended minimum server size is 2GB RAM, $12-20/month on Hetzner or DigitalOcean. For communities under 10,000 active users, a single server handles all the load comfortably.

Discourse's plugin system is one of its strongest differentiators. The plugin registry includes integrations for Stripe (for paid community access), GitHub (for SSO with GitHub accounts), Slack (cross-posting), and dozens of community-contributed plugins. The Discourse API is well-documented and stable — you can programmatically create topics, manage users, and query statistics from external applications. This API integration pattern is common for SaaS products that want to provide a community forum without building one: provision a Discourse category for each customer organization via API, use SSO to log customers into Discourse with their SaaS credentials, and embed Discourse in an iframe within your product.

Discourse as an API is an underutilized pattern. Instead of treating Discourse as a standalone forum, use it as a headless community backend: your SaaS frontend handles authentication and layout, Discourse handles the forum data model and notification engine, and you render Discourse content in your UI via the Discourse API. This gives you the maturity of Discourse's forum engine with a fully branded frontend. The tradeoff is the overhead of running a separate Discourse instance alongside your SaaS application.

Building a Custom Community with Next.js

For a community tightly integrated with a SaaS product:

// Real-time community with Pusher
import Pusher from 'pusher';

const pusher = new Pusher({
  appId: process.env.PUSHER_APP_ID!,
  key: process.env.NEXT_PUBLIC_PUSHER_KEY!,
  secret: process.env.PUSHER_SECRET!,
  cluster: 'us2',
});

// When user posts to community
export async function POST(req: Request) {
  const { content, channelId } = await req.json();
  const session = await getServerSession();

  const post = await db.post.create({
    data: { content, channelId, authorId: session.user.id },
    include: { author: { select: { name: true, avatar: true } } },
  });

  // Broadcast to all subscribers in real-time
  await pusher.trigger(`channel-${channelId}`, 'new-post', post);

  return Response.json(post);
}

// Client: subscribe to real-time updates
import { useChannel, useEvent } from '@harelpls/use-pusher';

function CommunityFeed({ channelId }) {
  const channel = useChannel(`channel-${channelId}`);
  const [posts, setPosts] = useState([]);

  useEvent(channel, 'new-post', (post) => {
    setPosts(prev => [post, ...prev]);
  });

  return posts.map(post => <PostCard key={post.id} post={post} />);
}

Paid Membership Tiers

Community monetization through paid tiers is one of the features where custom builds earn their complexity cost. Discourse handles paid access through plugins, but gating specific channels or content types with different pricing tiers is awkward to implement cleanly in any off-the-shelf platform.

The Stripe subscription integration for community access follows the same pattern as any SaaS product: a subscription tier in your Stripe products, a webhook handler that updates the user's tier field in your database on customer.subscription.updated, and middleware that checks tier before serving gated content or channels. The community-specific nuance is that you're often gating access to specific channels rather than the entire product — a free tier can view public discussion channels, but a paid tier unlocks a private channel for premium members or direct message access to experts.

Memberstack and Memberful are third-party alternatives worth evaluating for custom builds. Both provide a managed subscription and user management layer that integrates with HTML-based sites via JavaScript. The advantage over raw Stripe integration is faster implementation (they handle the checkout flow, billing management portal, and access control middleware). The disadvantage is an additional third-party dependency and a per-member pricing model that gets expensive at scale. For early-stage community products, a Memberstack integration can be the right move to ship paid tiers quickly before the community is large enough to make the per-member cost sting.

Moderation System

Moderation is the highest-leverage investment for community health, and it's systematically underestimated in custom community builds. A community with weak moderation spirals quickly: low-quality posts drive away high-quality contributors, spam accumulates, and the signal-to-noise ratio degrades until active users leave.

Discourse's trust level system is the gold standard. New users (trust level 0) are limited in what they can do — they can't post links, can't upload images, have rate limits on replies. As users engage positively (posts get liked, replies are helpful), they advance through trust levels that grant more permissions. Trust level 2 users can post links; trust level 3 users can edit wiki posts; trust level 4 is moderator status. The system is self-enforcing: the community rewards good behavior with higher trust, high-trust users have more autonomy, and the feedback loop sustains community quality without constant moderator intervention.

Shadow banning is a moderation technique where a flagged user sees their own posts normally but their posts are invisible to everyone else. It's more effective than hard banning for spam and bad actors because it prevents the banned user from immediately creating a new account — they don't know they've been banned. The tradeoff is ethical: shadow banning is deceptive by design, and transparent moderation (a clear ban with a reason) is more appropriate for good-faith users who violated a rule without malicious intent.

Rate limiting should be applied at multiple levels for community features. Post creation rate limits (max 5 posts per hour for new users) prevent flooding. Reply rate limits prevent arguments from escalating into rapid-fire exchanges. Image upload limits prevent storage abuse. These limits should be configurable per trust level — established high-trust users should have much higher limits than new accounts.

Report queues are the interface between community reports and moderator action. When a post is flagged, it enters a queue with the flagging reason and the flagging user's trust level (a flag from a trust level 4 user carries more weight than a flag from a brand-new account). The queue should surface the most urgent flags first — multiple independent flags on the same post, flags from high-trust users, posts that match spam patterns. Auto-hiding posts that receive N flags before a moderator reviews them is a useful safety valve for obvious spam.

Community Engagement Features

The technical features that most reliably drive community retention are reputation systems, digest emails, and notification design — not real-time features or flashy UI.

Reputation and points systems create the gamification layer that keeps engaged users coming back. Points for creating posts that get upvoted, points for accepted answers, points for consistency (daily contribution streaks), and points for helping new users. The leaderboard is the surface where reputation becomes social — seeing your name in the top 10 contributors for a week is motivating in a way that a private engagement metric is not. The design tradeoff: aggressive gamification attracts quantity over quality. Low-quality posts that game the upvote system are a known failure mode (see: Reddit). Design your point values to reward helpfulness (accepted answers, constructive replies) more than popularity (votes on opinion posts).

Badges and achievements are a lighter-weight reputation signal than a numeric score. Discourse's badge system is well-designed: "First Like Given" teaches new users about the upvote mechanic, "Enthusiast" rewards a 10-day consecutive login streak, "Great Post" signals exceptional quality. Badges tell a story about how a user participates in the community, which is more informative than a raw number.

Weekly digest emails are consistently the highest-engagement trigger for dormant community members. A digest showing the top 3 posts from the past week, plus a prompt to see what's trending, brings back users who haven't visited recently. The implementation requires tracking post engagement over the past 7 days, ranking posts by a composite score (views, replies, reactions), and rendering a personalized email (showing content from categories the user is interested in, not just platform-wide top posts). For newsletters integrated into community products, see Best Boilerplates for Newsletter & Email Products 2026 for the sending infrastructure patterns.

Community Search and Discovery

Search is one of the most underinvested features in community products, and one of the most impactful for retention. If users can't find answers to their questions, they ask again (creating duplicate posts) or leave to search Stack Overflow. A community where search works well is a community where knowledge compounds — old discussions remain valuable indefinitely.

Full-text search with PostgreSQL handles communities up to ~100k posts adequately. PostgreSQL's tsvector and tsquery types support full-text search with ranking, stemming, and stop word filtering. The implementation is simple: a generated column on the posts table with a tsvector of the post content, a GIN index on that column, and a query using to_tsquery. For most community products that don't need fuzzy search, autocomplete, or faceted search, this is sufficient and adds no additional infrastructure.

Meilisearch is the right choice when you need fast, typo-tolerant search with filtering and facets. Meilisearch is an open source search engine that's trivially self-hostable (single binary, Docker image) and has an excellent developer experience — push documents, configure synonyms and stop words, and get instant results. It handles the "search for 'authentciation'" problem (typo tolerance) that PostgreSQL full-text search doesn't. For developer communities where search is a primary use case, Meilisearch meaningfully improves the user experience.

Trending content — posts gaining significant engagement in the past 24-48 hours — needs a different algorithm than search. An engagement velocity score (rate of new reactions/replies over the past N hours, not total engagement) surfaces content while it's actively being discussed. Display trending topics on the home feed to expose engaged users to popular discussions they might have missed.

Notification Architecture

Notification systems are notoriously difficult to get right. Over-notify and users disable all notifications and miss important updates. Under-notify and users disengage because they don't know when their posts get responses.

In-app notifications are the foundation. Every direct reply, mention, reaction, and moderation action should generate an in-app notification. The UX requirements: a clear notification center (not buried in settings), mark-all-as-read, actionable notifications (reply directly from the notification), and accurate unread counts that stay in sync across sessions. In-app notifications require a notifications table with a read boolean, a background job to fan out notifications to relevant users when an event occurs, and real-time delivery via WebSocket or SSE so the notification count updates without a page refresh.

Email digest batching is the alternative to per-event email notifications. Sending an email for every reply to a popular thread floods the inbox and trains users to ignore your emails. Batching strategies: immediate digest (one email per notification, sent immediately) for @mentions in quiet communities, hourly digest for active threads, daily digest as a default for most notification types. The digest construction logic needs to deduplicate notifications from the same thread (one digest email for "5 new replies to your post" rather than 5 separate emails) and suppress digest emails for users who have been active in the last N hours (they've already seen the notifications in-app).

Push notifications for mobile community apps (if you have a mobile companion app) require the same batching logic plus consideration of per-device quiet hours, platform-specific payload limits (APNs and FCM have different size constraints), and delivery priority (FCM's high-priority messages bypass Doze mode on Android for time-sensitive notifications).

Community Features Checklist

Core (must-have):

Post/topic creation with rich text
Threaded comments/replies
Like/upvote reactions
User profiles with activity history
Notification system (new replies, mentions)
Basic moderation (pin, lock, delete, ban)

Growth (phase 2):

Methodology

Community platform comparison based on direct evaluation of Forem, Discourse 3.x, and custom Next.js community implementations as of Q1 2026. Moderation system design based on Discourse's trust level model and community management literature. Pricing from official sources as of Q1 2026.

For open source SaaS foundations to build a custom community on, see Best Open Source SaaS Boilerplates 2026. For authentication setup in custom community builds, see Authentication Setup for Next.js Boilerplates. If your community product includes a newsletter component, see Best Boilerplates for Newsletter & Email Products 2026. Browse all boilerplates in the StarterPick directory.

The SaaS Boilerplate Matrix (Free PDF)