Forem

Open-source community software, honestly reviewed. No marketing fluff, just what you get when you try to run it yourself.

TL;DR

• What it is: Open-source (AGPL-3.0) community and blogging platform — the same software that powers dev.to, a developer community with 3.8 million registered members [README].
• Who it’s for: Technical teams or organizations that want to build a public-facing community hub with blogging at its core — developer communities, content-first brands, or open-source projects that want a DEV.to-style home.
• Cost savings: Circle (the closest SaaS competitor) charges per member at scale. Forem self-hosted runs on your own server with no per-seat fees — but the infrastructure requirements are non-trivial and the self-hosting path assumes Ansible fluency [4].
• Key strength: Proven at scale. dev.to is a working production reference with millions of users and years of battle-testing. You’re not adopting experimental software [README].
• Key weakness: Deployment is genuinely complex — Ansible playbooks, Fedora CoreOS, cloud-specific provisioning scripts. No Docker Compose quickstart. And the AGPL-3.0 license means any derivative you distribute must also be open source, which rules out using Forem as the engine for a commercial closed product [4][1].

---

What is Forem

Forem is open-source software for building communities. Not forums in the phpBB sense, and not a generic social network — it’s specifically a blogging-forward community platform where the primary content unit is a written post, not a thread or a reaction. Members write articles, comment, follow each other, and build a feed. The README describes it as being “for empowering community” and positions it for “peers, customers, fanbases, families, friends” — which is a broad pitch, but the actual product skews heavily toward developer and technical communities [README].

The canonical proof of concept is dev.to (or just DEV), which Forem both powers and runs as its own hosted instance. As of this review, that community has 3.8 million members. Every post you see on dev.to — the MCP server builds, the #100DaysOfCode logs, the career retrospectives — is running on the same codebase you’d be self-hosting [website][README].

The technical stack is Ruby on Rails on the backend, currently transitioning to a Preact-first frontend. That’s not a knock — Rails is a fine choice for this kind of content-heavy community app — but it’s worth knowing before you commit, since your ops team will need Rails deployment experience rather than Node or Go familiarity [README].

The GitHub repository sits at 22,625 stars with a steady commit cadence. The license is AGPL-3.0, which is meaningfully more restrictive than MIT or Apache 2.0. More on that in the deployment section.

---

Why people choose it

The third-party coverage on Forem is thinner than most tools in this position, which is itself a signal. For a project with 22K GitHub stars that powers one of the largest developer communities on the internet, the self-hosting discourse is surprisingly sparse.

The most honest framing comes from a DEV community thread [1] where someone is trying to self-host Forem on a cloud provider that isn’t GCP, AWS, or DigitalOcean — the three officially supported targets. The answer from the community is essentially: it’s possible but unsupported, and the automated Ansible playbooks are the only well-trodden path. That’s a telling constraint.

What draws people to Forem despite that friction:

The dev.to reference is unusually powerful. Most self-hosted tools claim production readiness. Forem has a publicly visible 3.8-million-member production deployment you can browse right now. If your use case looks like “developer community with articles, tags, follows, and comments,” you’re looking at proven infrastructure [README][website].

Blogging-first architecture. Forem isn’t trying to be Discourse or a Slack replacement. The content model is article-centric with a lightweight social layer. If that matches how your community actually communicates — long-form posts, technical writeups, tutorials — it fits better than a thread-based forum tool [README].

No per-seat pricing when self-hosted. Community platforms that grow unexpectedly can generate punishing SaaS bills. Forem self-hosted has no per-user cost ceiling [merged profile].

Active development. The README notes that 270+ contributors have touched the project and the core team is responsive to PRs from external contributors [README]. The contributing guide [2] is detailed and welcoming, with labeled issues for external contributors and a clear PR process.

---

Features

Based on the README and DEV.to as a live reference:

Core content model:

• Article/post publishing with Markdown, tags, series support
• Reactions and comments on posts
• Follow system — users follow other users or tags
• Reading list / bookmarks
• User profiles with full post history

Community mechanics:

• Tag-based discovery and following
• Organizations (team accounts)
• Listings (job board / classifieds)
• Podcasts section
• Events support
• “Connect” (direct messaging, though limited)

Admin and moderation:

• Admin panel for managing users, posts, tags
• Content moderation queue
• Configurable community rules and conduct policies
• Custom pages and navigation
• Announcement banners

Developer and integration features:

• Full public API (the same one powering the DEV.to integrations)
• Webhooks for real-time event streams
• OAuth login via GitHub, Twitter, and others (configurable)
• Progressive Web App support
• SEO-optimized article URLs and meta tags

What it doesn’t do:

• No built-in course or paid membership support (that’s Circle’s lane)
• No native video hosting
• No built-in event ticketing
• No whiteboard / collaboration tools
• The “Connect” messaging feature is minimal — not a Slack replacement

---

Pricing: SaaS vs self-hosted math

Forem self-hosted:

• Software license: $0 (AGPL-3.0)
• Infrastructure: a cloud server that can handle Rails + PostgreSQL + Redis + Elasticsearch (more on sizing below)
• Your time: significant up-front setup investment

Forem Cloud / managed hosting:

• No public pricing page found. The website at forem.com serves what appears to be a live dev.to instance rather than a product landing page — finding pricing for managed Forem hosting is genuinely difficult. If managed hosting exists as a commercial offer, it isn’t prominently marketed.

Circle (the identified SaaS competitor):

• Pricing data not available in sources reviewed. Circle is a creator community platform — different enough in positioning (course-native, paid memberships, Notion-like spaces) that the comparison is imprecise anyway.

Discourse (closer SaaS comparison for forums):

• Managed Discourse Basic: ~$100/month for small communities
• Self-hosted Discourse: free (same pattern as Forem)

Honest take on the cost savings: The financial case for self-hosting Forem holds up if you’re running a community that would otherwise cost you $200–500+/month on a managed platform. The infrastructure to run Forem comfortably — a 2+ vCPU instance, at least 4GB RAM, persistent disk for media — costs $20–40/month on Hetzner or DigitalOcean. The non-financial cost is the setup and maintenance time, which for Forem specifically is higher than most comparable tools [4][1].

---

Deployment reality check

This is where an honest review has to slow down.

Forem’s official self-hosting path uses Ansible playbooks targeting Fedora CoreOS on AWS, GCP, or DigitalOcean [4]. That’s not a Docker Compose file. That’s a full infrastructure automation pipeline that provisions cloud resources, uploads a custom OS image, configures DNS, and then deploys the app stack. The DigitalOcean tutorial [4] walks through installing doctl, configuring Ansible collections, generating API tokens, uploading a custom Fedora CoreOS droplet image (with a note that this step can time out), and running ansible-playbook — before you’ve even seen a Forem page.

The community question in [1] — “how do I self-host on a cloud provider other than the big three?” — received no clean answer. The Ansible playbooks are cloud-provider-specific. If you’re on Vultr, Contabo, Linode, or a bare-metal VPS, you’re in undocumented territory.

What you actually need:

• A cloud VPS on AWS, GCP, or DigitalOcean (the supported targets)
• Ansible installed locally and familiarity with Ansible playbooks
• API access tokens for your cloud provider
• SSH key generation and management
• A domain name with DNS control
• SMTP credentials for transactional email
• Patience with a potentially time-consuming image upload step on DigitalOcean [4]

Minimum specs (based on deployment guide): 2 vCPU / 2GB RAM is the documented minimum for DigitalOcean (s-2vcpu-2gb). Rails apps with background jobs, Elasticsearch, Redis, and PostgreSQL will pressure 2GB — expect to upgrade to 4GB as your community grows [4].

The AGPL-3.0 license constraint. AGPL means that if you distribute or run a modified version of Forem as a network service, you must make your source code available under AGPL. For a non-technical founder running their own community — no issue. For a developer building a commercial product or a SaaS on top of Forem — this is a legal consultation trigger. MIT lets you take the code and build what you want. AGPL does not [merged profile].

Realistic time estimate for a technical user: 4–8 hours to a working instance on a supported cloud, assuming no Ansible experience gaps and no DNS propagation delays. For someone who has never run Ansible: budget a full day, or hire someone who has. For a non-technical founder with no Linux experience: this is not a self-service deployment [4][1].

One practical path that skips some of the pain: the README mentions Gitpod and “Ona” (formerly Gitpod) for launching Forem in a cloud development environment, but these appear to be development environments, not production deployments [README].

---

Pros and cons

Pros

• Production-proven at meaningful scale. dev.to has 3.8M members and runs on this exact codebase. Very few self-hosted community tools can claim a reference deployment that large [website][README].
• Blogging-native. If your community communicates through articles — not threads, not channels, not cards — Forem’s content model fits better than Discourse or a Slack alternative.
• Active contributor community. 270+ contributors, labeled issues for external contributors, detailed contributing guide, PR review within reasonable timeframes [README][2].
• Full public API. The same API powering dev.to integrations is available to you — you can build on top of Forem programmatically [README].
• No per-seat cost when self-hosted. Unlimited members, no pricing tiers based on community size [merged profile].
• Mature content features. Tags, series, organizations, reading lists, podcasts, listings — the feature set is wide because it had to serve dev.to’s actual user needs [README].

Cons

• Deployment is non-trivial. Ansible + Fedora CoreOS + cloud-specific playbooks. No Docker Compose quickstart. Not a tool you hand to a non-technical founder and say “have at it” [4][1].
• Only three officially supported cloud providers. AWS, GCP, DigitalOcean. Self-hosting on anything else means adapting unsupported playbooks [1].
• AGPL-3.0 license. More restrictive than MIT — any network-accessible modification must be open-sourced. Rules out building closed commercial products on top of Forem [merged profile].
• Confusing product presence. The website at forem.com displays what appears to be a live dev.to instance, not a product marketing page. Finding pricing, managed hosting options, or deployment documentation requires digging into developer docs or GitHub. The product’s commercial status and roadmap are unclear.
• Heavy stack. Rails + PostgreSQL + Redis + Elasticsearch on a minimum 2GB VPS is a meaningful resource footprint compared to lighter alternatives.
• No easy path for non-standard infrastructure. Bare-metal VPS, Contabo, Hetzner, Linode — these aren’t supported targets, which is exactly where cost-conscious self-hosters tend to live [1].
• Limited third-party documentation. For a project with 22K stars, the self-hosting guides and independent reviews are sparse. Most search results lead back to dev.to posts or the official docs [1][3].

---

Who should use this / who shouldn’t

Use Forem if:

• You’re building a developer or technical community where long-form articles are the primary content format.
• You have a technical team comfortable with Ansible and Rails deployment.
• You want a proven, large-scale codebase with an active contributor community rather than a smaller or newer project.
• You’re deploying on AWS, GCP, or DigitalOcean and can follow the official Ansible playbooks.
• You’re okay with AGPL-3.0 (running your community as-is, not building a proprietary product on top).

Skip it (use Discourse instead) if:

• Your community is discussion-first rather than article-first — threaded debates, Q&A, support forums.
• You want a mature, widely documented self-hosting path with Docker Compose support and a larger community of ops guides.
• You need SSO, LDAP, or enterprise authentication baked in.

Skip it (use Ghost instead) if:

• Your use case is primarily publishing, not community. Ghost has a cleaner self-hosting experience and native newsletter support if audience-building is the goal.

Skip it (use Circle or Mighty Networks) if:

• You need paid memberships, course gating, or live events without building them yourself.
• You don’t have a technical person to handle deployment and maintenance.
• You need managed hosting with SLAs and support.

Skip it (stay with managed platforms) if:

• You’ve never touched Linux or Ansible — the deployment complexity will burn your time in ways that outweigh any cost savings.
• Your community has compliance requirements that need audited, managed infrastructure.

---

Alternatives worth considering

• Discourse — the dominant open-source forum platform. More mature self-hosting ecosystem, Docker-based deployment, thread-first content model, stronger moderation tools. If you’re not specifically sold on Forem’s blogging-first approach, Discourse is the safer bet for most community use cases [3].
• Ghost — open-source publishing platform with a strong newsletter/membership layer. Better for content-creator communities than peer-to-peer discussion. Docker-based, cleaner self-hosting story.
• Circle — Forem’s identified SaaS competitor. Creator-native, paid membership support, no self-hosting option. Commercial SaaS with per-member pricing.
• Mighty Networks — another paid SaaS in the community space, focused on course creators and paid communities.
• Lemmy — if you want Reddit-style federated communities rather than article-centric communities. ActivityPub-native, genuinely simple Docker deployment.
• Mastodon — if the use case is microblogging or federated social, not article communities. Much simpler self-hosting than Forem.
• WordPress + BuddyPress — the old-school answer. More flexible, far wider hosting ecosystem, but higher ongoing maintenance burden and design debt.

For a non-technical founder, the realistic shortlist is Circle vs Discourse. Forem enters the conversation when you specifically want the DEV.to experience under your own domain and have the technical resources to deploy it.

---

Bottom line

Forem is a legitimate piece of open-source software with a genuinely impressive production reference: dev.to, 3.8 million members, years of operation. If you’re building a developer or technical community and want something with that kind of proven history, it’s worth serious consideration. The feature set is deep, the API is solid, and the contributor community is active.

But the honest assessment for most readers is: the deployment story is harder than it needs to be in 2026. Ansible playbooks targeting three specific clouds, no Docker Compose path, AGPL licensing with its commercial implications — these are real obstacles that lighter alternatives (Discourse, Ghost, Lemmy) have largely solved. If your technical team has Ansible experience and you’re on a supported cloud, the path to production is documented and achievable. If you don’t, you’re either hiring someone or accepting a steeper learning curve than the GitHub star count suggests.

For the non-technical founder profile that unsubbed.co is written for — someone escaping SaaS bills, not someone managing DevOps pipelines — Forem is probably not the right starting point. Discourse with a Docker Compose deployment is where that conversation usually lands. Forem is the right answer when the DEV.to content model specifically matches what you’re building and you have the infrastructure capability to go with it.

If the deployment is the blocker, upready.dev handles exactly this — one-time setup on infrastructure you own.

---

Sources

1. Charles Lin, DEV Community — “Self-host Forem on cloud other than GCP, AWS, DigitalOcean”. https://dev.to/charleslin/self-host-forem-on-cloud-other-than-gcpawsdigitalocean-2p6c
2. Forem Docs — “Contributing to Forem”. https://developers.forem.com/contributing-guide/forem
3. Daniel Pison, LiveAgent — “The 20 best forum software” (Jan 20, 2026). https://www.liveagent.com/blog/best-forum-software/
4. Eric Cabrel TIOGO — “Deploy Forem on Digital Ocean and build your tech community”. https://blog.tericcabrel.com/deploy-forem-on-digital-ocean/
5. DEV Community — “Self-hosting like a final boss: what I actually run on my home lab (and why)”. https://dev.to/dev_tips/self-hosting-like-a-final-boss-what-i-actually-run-on-my-home-lab-and-why-48k1

Primary sources:

• GitHub repository and README: https://github.com/forem/forem (22,625 stars, AGPL-3.0 license, 270+ contributors)
• Official website / DEV.to: https://www.forem.com
• Developer documentation: https://developers.forem.com