Forem: self-hosting the Rails platform behind dev.to

What Forem is, and who the codebase is actually for

Forem is a community platform, not a component. The README describes it as "open source software for building communities" and names dev.to as the deployment it hosts. That framing matters for anyone evaluating it: the repository is the whole product, from article editor to moderation tooling to feed generation, and adopting it means adopting a Rails application with a Preact frontend rather than dropping a library into an existing stack.

The intended audience is narrow in practice. The README's contributing section asks that all pull requests include tests, notes that the current focus is primarily on backend regression tests, and warns that frontend changes may require more extensive user review. That is the shape of a project maintained by people who run it in production, and it tells you the codebase assumes contributors who can reason about Rails internals. If your team has no Ruby experience, the cost of operating Forem is not the install, it is everything after it.

The pgvector requirement and the AI feed

The most consequential detail in the README is buried in the getting-started section. Forem "now utilizes advanced AI embeddings for feed generation," and PostgreSQL must have the pgvector extension at version 0.8.0 or higher to support HNSW indexing. The README calls this a hard requirement to migrate the database and run the app. That is not a suggestion, and it changes what a Forem deployment looks like: you cannot point it at a stock managed PostgreSQL instance unless that instance exposes pgvector.

The README gives install commands for two platforms. On macOS with Homebrew it is brew install pgvector. On Debian or Ubuntu it is sudo apt install postgresql-15-pgvector, with the README noting you should adjust 15 to match your installed PostgreSQL version, or compile from source following the pgvector installation guide.

There is a second layer that is easy to miss. Providing a Gemini API key to actually generate the embeddings is optional. The README states that if GEMINI_API_KEY is omitted, the app continues to function normally without semantic recommendations. So the database extension is mandatory and the model provider is not. That split is sensible, but it means a self-hoster who wants the semantic feed has to supply a third-party API key, and the README does not describe what happens to feed quality or latency when the key is present.

Installing Forem locally with Docker Compose

The repository ships a docker-compose.yml that defines the application stack, and the README points to fuller installation guides for macOS and Linux without containers. The Compose file builds a development target, uses the image ghcr.io/forem/forem:1.0.0-development, and wires the app to PostgreSQL and Redis with health-check dependencies.

The environment block in the Compose file sets DATABASE_URL and REDIS_URL to localhost, which is how the containers reach their sibling services:

environment:
  CHROME_URL: http://chrome:3333
  REDIS_URL: redis://localhost:6379/
  DATABASE_URL: postgres://postgres:postgres@localhost:5432
  DATABASE_URL_TEST: postgres://postgres:postgres@localhost:5432
  MALLOC_ARENA_MAX: 2
  WEB_CONCURRENCY: ${WEB_CONCURRENCY:-1}

Note the CHROME_URL pointing at a chrome service on port 3333. The stack expects a browser container for system tests, so a plain docker compose up will pull more than the web app. The Compose file also mounts named volumes for bundle, node_modules, rails_cache, assets and builds, which is what keeps rebuilds from re-resolving every gem and package.

On the frontend side, package.json pins the toolchain tightly: engines declares node >=22.23.4 <23. The build script runs node esbuild.config.mjs, and the test script runs jest over app/javascript and bin. If your local Node is on a newer major line, align it before you start, because the README does not document a fallback path for other versions. Before the app will migrate, confirm the PostgreSQL instance you are pointing at has pgvector 0.8.0 or higher installed, since that is the failure you will hit first.

Deploying with Kamal 2, and why the beta label matters

Forem ships with Kamal 2 configuration for deploying to a cloud provider or bare metal. The README labels this section Deployment with Kamal (Beta), and that word is doing real work. A beta deployment path means the project is telling you the happy path exists but has not been hardened to the same standard as the application itself.

The prerequisites are explicit: SSH access to the target servers, Docker on both your local machine and the servers, and a container registry account such as GitHub Container Registry or Docker Hub. Configuration happens in two places. First, config/deploy.yml, where you update your registry username and credentials and set your domain in the proxy section. Second, environment variables on your local machine, including KAMAL_WEB_IP, KAMAL_JOB_IP, KAMAL_DB_IP and KAMAL_REDIS_IP, which the README says default to 192.168.0.1, plus KAMAL_REGISTRY_PASSWORD, RAILS_MASTER_KEY and DATABASE_URL.

The separation between web, job, db and redis roles is the part worth understanding before you buy servers. Forem expects more than one host role, so a single small VPS is not the shape the deployment config assumes. The README points to docs/kamal-deployment.md for cloud provider setups on AWS, DigitalOcean, Hetzner and GCP, secrets management, and what it calls Forem-specific production gotchas. That file is where the real operational knowledge lives, and the README's own phrasing suggests you should read it rather than improvise.

Where Forem is the wrong choice

The clearest limitation is the deployment story. The README offers installation guides for macOS and Linux without containers, a Docker Compose development stack, and a beta Kamal configuration. What it does not offer is a production deployment path that is not labelled beta. If your organization requires a supported upgrade and rollback procedure before you can run software in production, that gap is disqualifying until you write the procedure yourself.

The second limitation is the licence. The repository is AGPL-3.0, and package.json declares AGPL-3.0-or-later. If you plan to modify Forem and offer it as a network service without publishing your changes, this licence family is the wrong fit, and that is a decision for your own counsel rather than something the README resolves.

The third is scope. Forem is a full community application with an article editor, profiles, moderation and an embedding-based feed. If you want a forum or a comment widget, you are adopting a Rails application and its PostgreSQL extension requirements to get a fraction of what it does. The README does not describe a headless or embeddable mode.

How Forem differs from forum software you may already run

The natural comparison is Discourse, another Ruby on Rails community platform with a long self-hosting history. The difference in approach is the content model. Forem is built around articles and profiles: the README describes dev.to as a community where members write articles, take part in discussions and build professional profiles, and the repository's frontend is transitioning to Preact-first. Discourse is built around threaded discussion as the primary object.

That difference shows up in the dependencies. Forem's database needs pgvector because feed generation uses embeddings with HNSW indexing, which is a recommendation-system concern rather than a forum concern. A Discourse deployment does not carry that requirement. Forem also pins its own toolchain tightly, with Node >=22.23.4 <23 in package.json.

If your community's core artifact is a long-form post that people share and comment on, Forem's model matches. If your core artifact is a question with replies, the article-first structure is friction you will spend time working around.

Maintenance, upgrades and what to check before you commit

The last push to the repository was on 2026-11-02, and the repository is not archived. That is a live codebase. The repository has no published GitHub releases, so upgrade planning has to be based on the main branch and the CHANGELOG.md file in the repository root rather than on tagged versions.

Upgrade cost is dominated by the database. Because pgvector 0.8.0 or higher is a hard requirement for migration, any environment you run must keep that extension available across PostgreSQL upgrades, and the README's Debian example ties the package name to the PostgreSQL major version (postgresql-15-pgvector). A PostgreSQL major upgrade therefore means a matching pgvector package, not just a new server.

The dependency surface is also broad. The repository root contains a Gemfile and Gemfile.lock, a Brewfile and Brewfile.lock.json, .ruby-version and .ruby-version-next, .nvmrc, and a .mise.toml, which means Ruby, Node and system packages are all pinned in more than one place. Expect to track those files rather than a single version number.

On licence: AGPL-3.0 is a copyleft licence with a network-use clause, and package.json records AGPL-3.0-or-later. The repository includes a CLA.md and a CODE_OF_CONDUCT.md, and the README directs contributors to a contributing guide. None of that substitutes for reading LICENSE.md against your own distribution plans.

Editorial conclusion

Adopt Forem if you want a working article-and-discussion community and you have Ruby and Rails capacity to run it. Do not adopt it if you need a documented stable deployment path, a non-Rails stack, or a licence that lets you close your modifications; the README labels Kamal deployment as beta and the project ships under AGPL-3.0. Before committing, verify your PostgreSQL supports the pgvector extension at version 0.8.0 or higher, confirm the Ruby and Node versions in .ruby-version and .nvmrc, and read docs/kamal-deployment.md end to end.

Frequently asked questions

Official sources

1. forem/forem on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README