Stacker News pays bitcoin for contributions and runs its whole stack in Docker

The premise: pay for the work, not just for the code

The project summarises itself in a list of short claims, and the first one is the thesis: Stacker News moderates forums with money. The second is a joke that turns out to be a working principle, What You See is What We Ship, described as look ma, I invented an initialism. The third is 100% FOSS. The fourth states the mechanism plainly: they pay bitcoin for pull requests, issues, documentation, code reviews and more.

That reframes what a forum project normally is. Most open source projects pay for code, sometimes, and treat documentation, issue triage and review as unpaid labour that happens anyway. Stacker News names all five activities as things it pays for, which means the work that keeps a busy forum healthy is the work the project is actively buying.

The stack is listed in the same breath: Next.js, postgres, graphql, and lnd. That last one is the interesting dependency. lnd is a Lightning Network daemon, and combined with the repository topics, which include bitcoin, lightning, lightning-network, lnd, micropayments and next, the picture is a forum where money moves over the Lightning Network rather than through a traditional payment processor. There is a wallets/ directory at the top level and a lightning/ group of commands in the development tool for funding and withdrawal.

The topics also list plpgsql and postgresql, which tells you the database does more than store posts. The docker-compose file shows a db service built from ./docker/db with seed files mounted into the postgres entrypoint directory, and a healthcheck that runs a pg_isready probe and then a real query, SELECT 1 FROM users LIMIT 1, which is a nice touch: the health check verifies the schema is present rather than only that the port is open.

The homepage is stacker.news, the default branch is master, the licence is MIT, and the last push was on 2026-10-16 with no GitHub releases.

One command to a full development environment

The developer experience claim is that you launch a fully featured development environment in a single command:

$ ./sndev start

Then you go to localhost:3000. Behind that one command is a docker-compose stack with healthcheck-gated dependencies, and the compose file shows the pattern. There are YAML anchors for a shared healthcheck definition with a 10 second interval, 10 second timeout, 10 retries and a one minute start period, and anchors for depends_on relationships against the db, the app and the bitcoin service, each requiring the dependency to be healthy before starting. The db service is exposed on 5432 internally and published on host port 5431, with a label of CONNECT: "localhost:5431" so tooling can find it.

The service list is bigger than a typical app. There is a tor service, built from ./docker/tor, which belongs to the tor and wallets profiles, with a healthcheck that runs a shell script called /tor.sh check. Tor in the stack is not a development convenience, it is the onion service path, and there is a matching sndev command for a service onion address, plus commands for a service TLS cert and a service GUI in the browser.

The install path is documented with the practical details included. You clone the repository over ssh or https, install Docker, and the readme recommends OrbStack rather than Docker Desktop if you are on macOS or Windows. It also asks that at least 10 GB of free space be available, otherwise you may encounter issues while setting up the development environment. That is a large figure and it tells you the stack is heavy: Postgres, Bitcoin node, Lightning node, Tor, OpenSearch, a mail service and a capture service are all in there.

A Codespaces path exists too, with a badge and a step by step setup, and one instruction that is easy to miss: you must set forwarded ports to Public in the Ports tab, because internal services and external access both depend on it.

Compose profiles, because not every contributor needs a Lightning node

The most useful piece of design here is the service profile system, because a full stack for everyone is a full stack nobody will start. By default all services run, but you can set COMPOSE_PROFILES in a .env.local file to one or more of minimal, images, search, payments, wallets, email, capture, domains, domains-caddy. To run only what is minimally necessary, without payments for instance:

COMPOSE_PROFILES=minimal

And to include the image and payment services:

COMPOSE_PROFILES=images,payments

This is a normal Docker Compose mechanism, and using it here is a design decision rather than a Docker one. A contributor fixing a React component does not need a Bitcoin node, a Lightning node, a Tor onion service, an OpenSearch cluster and a mail server, and making the default everything means the first run of the environment is slow and fragile for everyone.

The compose file is also designed for merging. By default sndev start merges docker-compose.yml with docker-compose.override.yml, and the readme shows the pattern for replacing the database seed with a custom one:

services:
  db:
    volumes:
      - ./docker/db/another.sql:/docker-entrypoint-initdb.d/seed.sql

Two other subsystems are worth knowing about because they are self-configuring rather than manual. Semantic search is enabled automatically in development when the search profile is active, and on first boot OpenSearch downloads and deploys the embedding model and creates a neural-ready index, which takes a couple of minutes; no manual script run or container restart is needed. If the resources need to be repaired, you restart from a fresh dev volume with ./sndev delete and then ./sndev start. And the domains profile enables dnsmasq for local DNS, with DNS records managed through ./sndev domains dns, and a separate domains-caddy profile for the bundled Caddy HTTPS proxy, so you can keep local domain verification while omitting Caddy if an external load balancer handles TLS.

The sndev command surface, and the Lightning primitives

The help output of the development tool is worth reading as an API description, because it groups what the project can do by concern. The env group has start, stop, restart, status, logs and delete. The sn group has login as a nym and set_balance, which is the development-side of the wallet system, so you can impersonate a user with a balance for testing. The lightning group has fund, which pays a bolt11 for funding, and withdraw, which creates a bolt11 for withdrawal. The db group opens psql on the database and runs prisma commands, and the dev group has pr for fetching and checking out a pull request, lint and test.

The remaining commands are the ones that make the environment feel like a product. There is a service CLI passthrough, an open command to launch a service's GUI in the browser, an onion command for a service's onion address, a cert command for a service's TLS certificate, and a compose passthrough for raw docker compose. The last one is a small design decision with real value: the tool does not hide Docker, it gives you an escape hatch.

Lightning is the part that is genuinely unusual, and the two commands are the minimum viable path to money movement. fund pays a bolt11 invoice, and withdraw creates one. Those are the two directions, and everything else in the wallet stack is built on them. The wallet layer in the repository is a wallets/ directory, and the dependency list includes @cashu/cashu-ts for Cashu, the ecash protocol built on the same blind signature cryptography as Lightning, plus @lightninglabs/lnc-web, which is the browser-side Lightning Connection library.

The contributor side of the project is where the payment story closes. The repository carries awards.csv and an extend-awards.py script at the top level, alongside a contributors.txt, which tells you the awards are data rather than code, so a payment amount can be recorded and then processed. The readme's table of contents names the sections for contributing, paying bitcoin for contributions, pull request awards and code review awards.

How the application is actually built

The package.json at the repository root describes a Next.js application with a separate worker process, and the script names tell you how the pieces are meant to be used. The dev script runs next dev with webpack and with source maps and warning tracing enabled. The build script runs next build with webpack. The migrate script runs prisma migrate deploy, and the start script runs next start with a port from the environment and a two minute keep-alive timeout, along with a raised heap and semi-space size.

The worker scripts are separate. A worker entry point is run with tsx and a jsconfig, in watch mode for the dev variant, and there is a separate test script for a live Spark end to end run. The lint script runs standard, the test script runs jest with experimental vm modules enabled, and there is an audit script that runs node scripts/audit-blast-radius.js. That last one is an interesting artefact to find in a repository: a script whose name says it measures how far a change reaches.

The dependency list is where the architecture shows itself. There are two Apollo packages, the client and the server, and a Next.js Apollo integration, so GraphQL is the API contract for the frontend rather than a REST layer. Prisma is the ORM, and @auth/prisma-adapter ties authentication to the database. A Prisma adapter for Cashu, @cashu/cashu-ts, and @noble/curves for elliptic curve cryptography are both present, which matches the topic list mentioning Cashu. The editor is Lexical, with a dozen @lexical packages covering clipboard, code, Shiki syntax highlighting, headless, history, html, react, rich-text, selection and utils, so the post composer is a real rich text editor rather than a textarea.

AWS is in there too, with clients for ACM, S3, S3 presigned post and elastic load balancing, which points to file uploads and certificate management on AWS in production. The remaining dependencies include Graphile depth limit for query depth protection, the Nivo charting library, and a Spark SDK for streaming.

The Dockerfile is short and its decisions are informative. It is based on node:22.21.1-bullseye, sets NODE_ENV to development, takes UID and GID as build arguments, creates a group and a user named apprunner, switches to it, exposes port 3000, copies package.json and package-lock.json and runs npm ci with the legacy peer deps flag. It then runs npm ci a second time in the CMD, with a comment explaining why: node_modules is mounted in local development, so the install has to happen at container start as well. The CMD also runs npx prisma migrate dev before npm run dev, so the database is migrated on every start.

Where Stacker News is the wrong choice

The first limitation is the weight of the environment. Ten gigabytes of free space, a Bitcoin node, a Lightning node, Tor, OpenSearch, Postgres, a mail service and a capture service is not a stack you point at a small server. The profile system mitigates this rather than solving it, and even the minimal profile is a compose stack with healthcheck ordering. A team that wants a forum with a payment button is looking at a different project entirely.

The second limitation is the dependency on Lightning infrastructure for anything that moves money. lnd needs its own node, its own state and its own care, and the wallet layer depends on Cashu and a Lightning connection. A fork that wants to change how payments work is changing the part of the system that is hardest to substitute. The project has solved this for the case it was built for, and the fit is tight.

The third limitation is the incentive model itself, which is a genuine design trade rather than a defect. Paying for issue triage and code review removes a bottleneck that plagues most open source projects, and it also changes who shows up. People who are paid to do a job are doing a job, which is different from people who want the job, and the community effects of that are not settled. For a project that wants paid contributors, that is the point.

The realistic alternative is a forum platform with a conventional donation or subscription model, run on something with a larger ecosystem and a mature plugin system, where the incentive layer is a separate concern you can design rather than one baked into the stack. The difference in approach is that Stacker News treats the payment rail as part of the product's reason to exist and wires it through the domain model, with a nym balance in the database and bolt11 creation in the development tools, while a conventional platform treats money as a subscription record. If your goal is to run a community forum and you like the incentives that come with paying for contributions, Stacker News is unusual in a good way. If you want a forum that works, most of the alternatives will get you running sooner.

Editorial conclusion

Adopt Stacker News if you want to work on an open source project where contributions are paid in bitcoin, or if you are running a forum and want that incentive model. Do not adopt it as a general purpose forum deployment without reading the lightning and wallet services, because the payment rails are built into the stack rather than bolted on, and expect a heavier setup than a typical app. Before you start, read the contribution and awards documentation and check the awards script in the repository, and remember the development environment needs at least 10 GB of free space and Docker, with OrbStack recommended on macOS and Windows.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. stackernews/stacker.news on GitHub