lobsters/lobsters: Running the Lobsters Rails Codebase as Your Own Site

What lobsters/lobsters solves, and for whom

The repository is the code that runs lobste.rs, a computing-focused community built around link submission and discussion. The README frames the open source release as part of a commitment to transparency: the primary audience is people who want to read and improve what happens on Lobsters itself, not people shopping for a community platform. Starting a sister site is explicitly allowed, and the README points to a sister_sites.md file listing existing ones. The licence is 3-clause BSD, which the README describes as permissive.

The README also pushes back on the assumption that the code is the interesting part. It states plainly that the hard part about starting an online community is not the codebase, and describes the chicken-and-egg problem: nobody wants to participate on a new site until other people are participating. Anyone evaluating this repository as a product should read that paragraph first, because it sets the expectation the maintainers themselves hold.

Rails conventions instead of dependencies

The design philosophy section of the README is unusually explicit about trade-offs. The project started on Rails 3.2.2 in 2012, so there are places where newer framework features were never adopted. New features lean on Rails itself rather than on gems, and the stated preference is to write a couple dozen lines of narrow code instead of adding a dependency that needs maintenance. The team is reluctant to add production services and almost entirely unwilling to depend on external services, which follows from self-hosting from the VPS up.

That shows in the stack. Production runs SQLite, and the README notes the app compiles its own SQLite with flags that change query plans, configured in .bundle/config. The consequence is concrete: you must use bin/sqlite3 rather than the system sqlite3, because the systemwide client gives wrong answers for explain query plan. Background jobs run through solid_queue, started with a process command rather than a separate queue service.

The front end follows the same logic. No JavaScript is served to logged-out visitors, JS is attached in a vanilla or jQuery style for logged-in users, and the project is slowly making JS optional even for them. There is no JavaScript in the build chain at all, on the grounds that it requires too much maintenance. CSS is restricted to a widely available baseline because a meaningful share of visitors use old, experimental, or homemade browsers.

Booting the app in Docker and running the test targets

The repository ships a docker-compose.yaml that builds from Dockerfile.dev, mounts the working directory at /lobsters, and publishes port 3000. The Makefile wraps it as docker-serve. From a clone of the repository:

docker compose up --build

The compose file sets stdin_open and tty to true, so the container stays attached and interactive. Once the build finishes, the Rails server is reachable on localhost port 3000. The README directs new contributors to CONTRIBUTING.md for the full development environment setup, which is where database preparation and any seeding steps would live; the README itself does not spell those out.

The Makefile defines the two verification targets the CI workflow runs. The test target executes RSpec and then brakeman in quiet mode, and lint runs standardrb with the --fix-unsafely flag, which rewrites files rather than only reporting.

make test
make lint

Running make test is the fastest way to confirm a local checkout behaves before you change anything. The README warns that test coverage is lighter for moderator and other non-core features, so a green suite does not mean every moderation path is exercised.

Deploying a sister site is a Hatchbox walkthrough, not a one-liner

The production section assumes you already know Rails deployment on a Linux server. The documented path uses Hatchbox, a paid service, with DigitalOcean as the hosting provider. The README says reusing that configuration is much easier than Heroku or Render, and then describes the final settings rather than tracking the wizard.

Several steps are non-obvious. The server name must match your domain name so DigitalOcean can create the reverse DNS PTR record needed for email. Before anything else, you should check whether the assigned IP address is on an email blocklist, because spammers constantly create servers and the address you receive may already have a bad reputation. The README's advice is to check as soon as the server exists, since deleting and recreating is far easier than getting off a blocklist. You also need to edit config/application.rb to set your site's name and domain.

The process list needs a solid_queue entry running bundle exec rails solid_queue:start. The README notes the project is reluctant to take on work that is not useful to lobste.rs itself, so a custom feature you want is not guaranteed to be merged. The Zulip chat room, created in February 2025, is the channel for codebase discussion and for limited support to sister site owners, including warnings about breaking changes and vulnerability announcements.

Where this codebase is the wrong choice

The README is candid that this is a volunteer project with limited development time and a long time horizon, designed to run for decades rather than to ship features quickly. The maintainers are willing to take downtime for big code changes instead of engineering around it, which is fine for a site with an established community and painful for one with users who expect continuous availability.

SQLite in production is the sharpest constraint. It removes a moving part and fits the self-hosting philosophy, but it also means the deployment model is a single server with a local database file. If you need horizontal scaling, managed failover, or a read replica, this codebase does not offer it, and the README does not document rollback or migration procedures for that scenario.

The lighter testing on moderator features is a second risk. If your site's value depends on moderation tooling behaving correctly under abuse, you are working in the part of the codebase the README describes as less covered. And the no-JavaScript stance is a deliberate constraint, not a gap: if your product plan assumes a rich client-side interface, you are fighting the project's stated direction.

How it differs from a general-purpose forum platform

The closest comparison is a general forum or community platform such as Discourse, which is also open source and self-hostable. The difference is architectural rather than cosmetic. Discourse is a product with a plugin ecosystem and a JavaScript-heavy client; lobsters/lobsters is a single Rails application with no JavaScript build chain and a stated preference for narrow in-repo code over dependencies. If you want to extend behaviour through plugins maintained by other people, this repository is the wrong shape, because the README says the team resists dependencies that require maintenance and resists adopting features that do not help lobste.rs.

The other meaningful difference is scope. Lobsters is a link aggregator with threaded discussion, not a general community suite. That narrowness is why the codebase is readable, and it is also why you should not expect features outside link submission, commenting, and moderation to exist. The README points to sister_sites.md for sites already running this code, which is the honest way to judge fit: look at what those sites are, not at what you hope to build.

Licence, maintenance, and what upgrading costs

The code is released under 3-clause BSD, which the README calls a permissive license and which permits running your own site. The repository's LICENSE file is the authoritative text; the metadata label for this repository is NOASSERTION, so read the file rather than trusting a badge. Nothing in the README describes a support contract, and the project explicitly says it is reluctant to take on work that is not useful to its own site.

Upgrade cost is the real ongoing expense. The project began on Rails 3.2.2 in 2012, and the README acknowledges dusty corners and unused newer features. Each Rails upgrade therefore touches code written under older conventions, and the documented support channel for sister site operators exists precisely because breaking changes happen. The Zulip room is where those warnings are posted. Budget for reading release notes and testing against your own deployment rather than assuming a drop-in upgrade. The last push to the repository was on 2026-09-16.

Editorial conclusion

Adopt lobsters/lobsters if you want a working Rails discussion site you can read end to end and host yourself, and if you have already worked out where your first users come from. Do not adopt it if you need a maintained product with support terms, a JavaScript build chain, or a database other than SQLite in production. Before you fork, read CONTRIBUTING.md for the dev environment, check config/application.rb for the site name and domain fields you must edit, and confirm your server IP is not on an email blocklist, because the README treats that check as something to do as soon as the server exists.

Frequently asked questions

Official sources

1. Issues
2. lobsters/lobsters on GitHub
3. Project website
4. README