Consul Democracy: Rails software for civic participation

What Consul Democracy is built to support

Consul Democracy addresses a specific municipal problem: providing a public web application where residents can participate in government processes rather than relying only on meetings, documents, and physical forms. The repository describes it as the open source codebase of the eParticipation website CONSUL DEMOCRACY, originally developed for Madrid City government and maintained by the open source community with the CONSUL DEMOCRACY Foundation.

The intended users are therefore two distinct groups. Citizens are the audience for participation features, while administrators and maintainers configure the site, manage users, and operate the service. The README explicitly directs people creating their own fork to separate documentation about installation, customization, and administration. That division matters because this is a complete web application, not a small library that can simply be imported into another product.

The repository also carries an accessibility conformance badge for WAI-AA, a Crowdin localization link, an open-issues page, and a roadmap project. These details indicate that the project includes public interface, translation, and contribution concerns. They do not, by themselves, establish that every deployment will meet a particular accessibility target or that every interface is localized. Those points still need checking in the deployment being considered.

Consul Democracy's Rails application structure

The repository is a Ruby on Rails application. Its top-level structure follows the conventional separation visible in the entry list: application code lives under `app/`, database-related material under `db/`, configuration under `config/`, tests under `spec/`, and commands under `bin/`. The application also includes a `Gemfile`, `Gemfile.lock`, `package.json`, and `package-lock.json`, so the setup combines Ruby dependencies with JavaScript packages.

The frontend package list gives a partial view of the client-side architecture. It includes Leaflet and `leaflet.markercluster` for maps and marker handling, Dropzone for file uploads, Markdown It for Markdown rendering, jQuery and jQuery UI for interface behavior, Foundation Sites for styling, and Font Awesome for icons. Billboards.js is included as well. These dependencies support the visible needs of a civic web application, including geographic features, uploads, formatted content, charts, and interactive controls.

The repository contains `config.ru`, `Capfile`, a `Dockerfile`, and `docker-compose.yml`, which indicates that the same application can be run through Rails tooling, containers, or deployment automation. The Dockerfile builds a Ruby 3.4.11 Trixie image, installs PostgreSQL client libraries and Chromium, installs Node from `.node-version`, runs `bundle install`, and runs `npm install`. That is a broad application stack rather than a package designed for a small integration.

The README does not expose the complete domain model. It does not provide a route list, a detailed proposal lifecycle, or a precise account-permission matrix. It therefore supports a broad description of an eParticipation application, but it does not justify claims about every workflow or administrative permission.

Installing Consul Democracy for local development

The README gives an installation path for local development. It first requires `git`, Ruby 3.4.11, CMake, `pkg-config`, Node.js 22.23.3, ImageMagick, and PostgreSQL 13 or later. The commands below clone the repository, install the application, load development seed data, and start the Rails server.

git clone https://github.com/consuldemocracy/consuldemocracy.git
cd consuldemocracy
bin/setup
bin/rake db:dev_seed

The README warns that `bin/setup` can fail when PostgreSQL has a configured username and password. In that case, the relevant lines in `config/database.yml` must be edited before running `bin/setup` again. After setup, start the application with:

bin/rails s

The seed data provides an administrator account and a verified account. The README lists the administrator credentials as `[email protected]` with password `12345678`, and the verified account as `[email protected]` with the same password. The verified account matters because the README states that some actions, including voting, require a verified user. These credentials are documented development seed credentials and should not be treated as production defaults.

The first practical verification is to start the Rails server and exercise a development-only workflow with the verified account. The README does not document a specific route, sample proposal, or expected response for that check, so it does not support a more specific tutorial than starting the app and logging in with the seeded account. The separate documentation site is the stated source for administrator and fork-specific instructions.

Running Consul Democracy with Docker Compose

For a container-oriented local setup, the repository includes `docker-compose.yml`. The file defines a PostgreSQL 14.19 Trixie service and an application service built from the repository's `Dockerfile`. The application maps host port 3000 to container port 3000, which corresponds to the web interface documented by the Rails command.

The database container receives a `POSTGRES_PASSWORD` value from the host environment and stores its data in the `db_data` volume. The application service depends on the `database` service and receives `DB_HOST=database`, `PGUSER=postgres`, and a password resolved through the PostgreSQL environment variables in the compose file. Source code, Bundler files, and `node_modules` are mounted as volumes, so local edits are reflected in the running application.

The compose file supports a repeatable application and database arrangement, but it does not document every variable required for a production deployment. In particular, the README points production users to the separate installer repository rather than claiming that this compose file is a production deployment package. A reader following the local development commands will not necessarily reproduce the same configuration as someone using the production installer.

Testing and maintenance costs

The documented test command is straightforward:

bin/rspec

The README warns that the full test suite may take more than an hour on a local machine. It recommends running only tests related to the current task during development and notes that GitHub Actions and GitLab CI configurations already exist in `.github/workflows/tests.yml` and `.gitlab-ci.yml`. For initial configuration, it recommends running at least one test in `spec/models/` and one in `spec/system/`. Those files reflect separate model and browser-level testing concerns in the repository layout.

The project is not archived. The last push was on 2026-10-15, and the recent releases include 2.6.1 on 2026-10-08, 2.6.0 on 2026-09-02, and 2.5.1 on 2026-06-04. That release and push record indicates recent repository activity, but it does not remove the operating cost of a Rails application with PostgreSQL, Redis-like caching dependencies implied by `memcached` in the Dockerfile, browser testing, localization work, and deployment maintenance. The README also mentions continuous integration as a practical response to the long test-suite duration.

The code is published under AGPL-3.0, with the license file named `LICENSE-AGPLv3.txt`. Anyone planning to modify, deploy, or redistribute the application must account for that license's obligations. This article does not provide legal advice. The practical review boundary is the license text itself, plus the separate installer and deployment documentation.

Where Consul Democracy is the wrong choice

Consul Democracy is a wrong fit for a team that wants a narrow voting widget, a reusable civic engagement API, or a lightweight Node.js service. The repository is a Rails application with its own users, administration model, database seed process, frontend packages, and deployment files. Embedding only a small part of it would require examining and separating application code rather than installing a package with a documented integration API.

It is also a poor fit for an organization unable to operate PostgreSQL, Ruby, Node.js, and a web server, or unwilling to maintain an instance of a public-facing participation service. The local instructions already require several system dependencies. Production configuration is not covered by the README itself and is directed to a separate installer repository.

The README does not document a formal migration path, rollback procedure, data portability format, or complete API contract. That absence is not proof that none exists. It means an evaluator cannot assume those capabilities from this repository overview. Before adoption, the most important checks are the complete feature and permission documentation, the production installer, the data model, and the specific workflows required by the institution.

Editorial conclusion

Public institutions should consider Consul Democracy when they need a configurable Rails platform for citizen proposals and voting. Organizations seeking a small voting widget should avoid it, and any adopter should first verify the production installer, permission model, data workflow, and AGPL-3.0 obligations.

Frequently asked questions

Official sources

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