Loomio: self-hosted collaborative decision making for co-ops and member organisations

What Loomio records that a chat thread cannot

The README describes Loomio as "a decision-making tool for collaborative organizations", and that phrasing is doing real work. The unit of content is not the message but the proposal: a question put to a group, with positions attached to it and an outcome that closes it. That matters for co-operatives, boards, tenant unions, worker councils and any group whose decisions have to survive the meeting they were made in. A chat log preserves who talked. Loomio is built to preserve who decided, when, and on what terms.

The intended audience is narrow on purpose. Groups that run on consensus or consent, where a decision is only legitimate if dissent is visible, get the most out of it. So do organisations with a membership list, because decisions need to be tied to people rather than to whoever happened to be in the room. If your group makes decisions informally and nobody ever needs to point at a record later, Loomio adds ceremony you will resent.

The Rails monolith and the Vue and hocuspocus split

Loomio is a Ruby on Rails application. The repository layout confirms the shape: app/, config/, db/, lib/ and spec/ are the Rails tree, vue/ holds the front end, and hocuspocus/ is a separate Node package. The Dockerfile builds those two Node pieces in distinct stages. The first stage copies vue/package.json and vue/package-lock.json, runs npm ci, copies the Vue source, copies config/ because Vite depends on the Rails locale files, and runs npm run build. The second Node stage installs the hocuspocus dependencies on their own.

The runtime image is ruby:4.0.5-slim and sets BUNDLE_WITHOUT=development, RAILS_ENV=production, RAILS_SERVE_STATIC_FILES=1 and MALLOC_ARENA_MAX=2. System packages installed at build time include libpq-dev for PostgreSQL, libvips and imagemagick for attachments, ffmpeg, poppler-utils, and libyaml-dev. That list tells you what a real deployment has to carry: a PostgreSQL server, a queue and background worker setup, and enough memory for the Vite build, which the Dockerfile caps at 2048 MB via NODE_OPTIONS.

The presence of push-relay/, haraka/ and ios/ at the top level is worth noting. Loomio is not a single deployable; it is a set of services, and self-hosting means deciding which of them you actually need.

Installing Loomio with Docker and getting to a first decision

The README does not contain install steps. It points at two documents instead: deploy/README.md for "self-hosting deployment guide" and DEVSETUP.md for a development environment. Those are the authoritative sources, and the build arguments below are the ones visible in the repository Dockerfile, not a substitute for reading them.

The Dockerfile declares NODE_VERSION with an ARG and requires NPM_VERSION, which it checks with the :? operator inside the npm install line, so the build fails fast if that argument is missing:

ARG NODE_VERSION
FROM node:${NODE_VERSION}-slim AS nodebuild
ARG NPM_VERSION

RUN npm install --global "npm@${NPM_VERSION:?NPM_VERSION build argument is required}" --no-audit --no-fund

After the npm install, the build sets its working directory to /build/vue, copies vue/package.json and vue/package-lock.json, and runs a deterministic npm ci before copying the Vue source:

WORKDIR /build/vue

# Copy only package metadata first for deterministic caching
COPY vue/package.json vue/package-lock.json ./

# Deterministic install
RUN npm ci --no-audit --no-fund

Later in the same stage it copies config/ because Vite depends on the Rails locale files, then builds the front end with a capped heap:

WORKDIR /build/
COPY config ./config
WORKDIR /build/vue

# Build Vite assets
RUN NODE_OPTIONS=--max-old-space-size=2048 npm run build

The runtime stage is based on ruby:4.0.5-slim and sets the production environment, so container logs go to stdout rather than to files inside the image:

FROM ruby:4.0.5-slim

ENV MALLOC_ARENA_MAX=2 \
    RAILS_LOG_TO_STDOUT=1 \
    RAILS_SERVE_STATIC_FILES=1 \
    RAILS_ENV=production \
    BUNDLE_WITHOUT=development \
    TZ=UTC

For contributing rather than deploying, DEVSETUP.md is the entry point, and the repository carries .env.development and .env.test alongside .ruby-version and .node-version, which pin the toolchain versions the project expects. mise.toml at the top level suggests mise is the supported way to install those pinned versions. Procfile.dev and Procfile.devclient describe the processes a development run starts.

What you should see after a successful deploy is a login screen and, once you create a group, the ability to open a discussion and raise a proposal inside it. If the asset pipeline failed, you will get an unstyled page instead, which almost always means the Vue build stage did not run or the config/ locale copy was skipped.

Where Loomio is the wrong tool

The licence is the first constraint. Loomio is released under the GNU Affero General Public License, and the README states that plainly. AGPL-3.0 section 13 reaches network use: if you modify Loomio and let users interact with it over a network, you are expected to offer those users the corresponding source. That is a different obligation from a permissive licence, and it is a real consideration for anyone planning a modified hosted product on top of it. This is not legal advice; if the boundary matters to your business, get proper advice.

The second constraint is operational weight. A Rails monolith with a separate Node front end, a background worker, PostgreSQL, and optional push-relay and haraka services is not a weekend deployment. The Dockerfile's Ruby 4.0.5 base and the Node build stage both move independently, so an upgrade means tracking two toolchains plus the gem and npm dependency trees. Small groups without anyone who reads release notes will drift.

The third is scope. Loomio is not a chat replacement, not a project tracker with Gantt charts, and not a document wiki. If your group's problem is that conversations are scattered, a chat tool with search solves it more cheaply. Loomio earns its complexity only when the decision itself, and the record of it, is the thing you keep losing.

Loomio alternatives and the difference in approach

People searching for Loomio alternatives usually mean one of two things: a hosted service that costs nothing, or a tool that lives where the conversation already is.

On the first, the honest comparison is Loomio's own hosted service at loomio.com, which the README points to for trying the product. The difference is not features but responsibility. Self-hosting gives you control of the data and the upgrade schedule; the hosted route gives you neither, and the repository does not document pricing, so anyone comparing cost has to check loomio.com directly rather than the code.

On the second, the real alternative is a general-purpose chat platform with threads and polls. The architectural difference is where state lives. In a chat tool, a decision is a message that scrolls away and a poll is an attachment to it; nothing in the data model knows the decision closed. In Loomio, the proposal is a first-class record with an outcome, and the surrounding discussion is subordinate to it. If your group needs to answer "what did we agree in March" without scrolling, that difference is the whole point. If it does not, chat wins on familiarity every time.

Licence, upgrade cost and what maintenance looks like

The licence is AGPL-3.0, stated in the README and shipped as LICENSE.txt. For internal use inside an organisation that does not modify the code, the practical effect is close to any other copyleft licence: you can run it, you must keep the notices, and you take on no distribution obligation. The moment you modify it and expose it to users over a network, the source-offer obligation comes into play. Teams that fork Loomio for a client-facing product should treat that as a design constraint from day one, not an afterthought.

Upgrade cost is driven by the dependency surface rather than by Loomio's own release cadence. Three releases landed in the last week of August 2026 (v3.4.0, v3.4.1, v3.4.2), and the last push to master was on 2026-08-28, so the project is moving. That cuts both ways: security fixes arrive, and so does churn. A self-hoster needs a repeatable rebuild of the Docker image, a database migration step, and a rollback plan. The README does not document rollback, and neither does the truncated Dockerfile; that is a gap you have to close yourself before you upgrade a live instance.

The repository also carries .github/, SECURITY.md and CONTRIBUTING.md, which is where the project states how it wants bugs and vulnerabilities reported. Use those channels rather than a public issue for anything security-related.

Editorial conclusion

Adopt Loomio if your group already makes binding decisions in meetings or threads and needs a durable record of who agreed to what, and you are willing to run Rails, PostgreSQL and the Docker build yourself. Do not adopt it if you only need chat, or if nobody on the team will own upgrades of a Rails 4.0.5 base image and a Node asset pipeline. Verify first that deploy/README.md matches your infrastructure and that your organisation accepts the AGPL-3.0 network-copyleft terms before you expose an instance to members.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes