Why a city citizen participation platform needs a different build
A council that wants residents to propose ideas, vote on budgets and comment on plans online is not buying a survey tool. The platform has to know who is a verified resident, which census or identity system is authoritative for that answer, and which public-sector duties apply to every page residents see. Those three questions drive the architecture more than any feature list. Decide early who may vote in each process, which record proves eligibility, and who in the city owns that record. Eligibility rules, not the component menu, are the first design decision. Decidim (licensed under the AGPL-3.0, built on Ruby on Rails and PostgreSQL) is the self-hosted fit for participatory budgets, consultations, initiatives and assemblies, and it can run inside municipal or national infrastructure.
Accessibility is the second driver with a fixed date. The ADA Title II rule requires state and local government web content and mobile apps, including content provided through contracts or licenses, to meet WCAG 2.1 Level AA. The compliance date is April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. A custom theme, a third-party map embed or a plug-in form can each break conformance, so the city should test its own Decidim theme and every custom component before launch, not assume the upstream code is compliant. Confirm with the city's legal counsel which entity is the covered public entity and which date applies to it. The ADA Title II web and mobile accessibility rule is the starting text for that conversation.
The AGPL-3.0 changes the operating model in a way procurement teams often miss. If the city modifies Decidim and makes the modified version available to users over a network, the modified source must be offered to those users under the same license. Custom authorization handlers, census importers and theme changes therefore need an ownership and publication decision before the build starts, not after. Ask any implementation partner to state in writing which code will be published, where, and under which license, and who keeps the patch queue. Decidim's security policy gives implementers a grace period of 2 months for standard vulnerabilities and 4 months for critical ones, and only the 0.32.x and 0.31.x lines receive security updates, so the city must budget for regular upgrades rather than a one-off launch.
Which municipal duties shape the platform build
This table maps each municipal duty to its source, the evidence an assessor or auditor will expect, and what it changes in a self-hosted Decidim build. Read it as a list of decisions to settle before launch, not as legal advice, since local data protection and records rules vary by jurisdiction.
| Requirement | Source | Build consequence |
|---|---|---|
| Web content and mobile apps meet WCAG 2.1 Level AA | 28 CFR 35.200 (ADA Title II); compliance from 26 April 2027 for entities serving 50,000 or more people, 26 April 2028 for smaller entities and special districts | Test custom themes, proposal forms and voting screens against WCAG 2.1 AA before launch, and confirm which compliance date applies to your city |
| Contractor-delivered content is covered | 28 CFR 35.200, which extends the rule to content provided through contracts or licenses | Put accessibility acceptance criteria and test evidence into the implementation contract, including custom Decidim components built by the partner |
| Published accessibility statement and feedback route | Municipal accessibility policy and the ADA Title II rule; confirm the exact statement content with your legal and accessibility leads | Publish a statement page and a reachable feedback channel on every participation site, and log and act on reports |
| Resident data handled as personal data | Local data protection law; confirm the lawful basis and obligations with counsel | Map which fields are collected at registration, verification and voting, restrict access by role, and document where data is hosted |
| Verification of eligible residents | Municipal voting and eligibility rules; confirm the census source and proof required with the clerk's office | Choose authorization handlers or census uploads, define what verification data is kept and for how long, and avoid storing more than the rule needs |
| Retention of votes, proposals and comments | Municipal records rules and local data protection law; confirm retention periods with records management | Define retention and deletion for proposals, votes and moderation logs, and test that anonymization or export works before go-live |
| Decidim security update window | Decidim SECURITY.md: only 0.32.x and 0.31.x receive security updates until version 1.0; 0.30.x and earlier are unsupported | Deploy on a supported minor version and plan an upgrade path one minor version at a time, backing up the database before each step |
| Patch application window | Decidim SECURITY.md: 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed | Assign an owner for patch intake from security@decidim.org or GitHub Security Advisories and rehearse patching on staging |
Which open-source platforms fit a municipal participation brief
Municipal participation rarely needs one tool for everything. Decidim covers the democratic spaces, while a general CMS or learning platform can carry public web content or training, and each option brings its own licence, release cycle and verification gap to confirm before the brief is final.
Decidim as the primary fit
Decidim is the only option here built for the participation workflow itself. It ships processes, assemblies, initiatives, participatory budgets, meetings, surveys, proposals and accountability tracking in one codebase under the AGPL-3.0. decidim.org names Barcelona, Helsinki and New York City among its users, which gives a council a reference point, though not a guarantee of fit. Confirm which components your brief needs and whether each is included in the release you plan to run.
Version support window
Decidim supports only its last two minor versions with security updates until version 1.0. Plan the hosting and upgrade calendar around that rule, and confirm which branch your provider will patch when the brief is written. Upgrades must go one minor version at a time, so an old installation can take several steps to reach a supported release.
General CMS for public web content
Drupal or WordPress can host the council website, news and service pages that sit alongside participation spaces. They do not run ballots, verify eligibility or count votes, so keep them as adjacent components and link to Decidim for the process itself. Confirm the CMS release line your web team maintains, and whether its accessibility work covers the pages residents will reach first.
Moodle for staff and councillor training
Moodle is a fit only when the brief includes training for staff moderators, councillors or community facilitators. It is licensed under GPL-3.0, and version 5.3.0 is the designated next long-term support release. Training content does not change how residents vote or sign, so keep it separate from the participation platform and confirm the support window before choosing it.
Verification sits outside the CMS
No general CMS handles eligibility checks, census matching or one-person-one-vote controls on its own. Decidim relies on authorization handlers and OmniAuth login, so the council must decide how identities reach the platform. Confirm with your identity team which census or eID source is available, and whether it can be connected without copying personal data into a second system.
How identity and census verification change the architecture
The verification source has to sit inside municipal control, because the eligibility decision for a vote, signature or budget proposal is a public-body decision. Decidim's built-in social providers (Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0) prove that someone controls an account with a third party. They do not prove that the person lives in the municipality, is old enough to participate, or is a single individual. A municipal eID, a national login scheme or a census lookup answers those questions. Decidim can connect to such sources through custom OmniAuth strategies or authorization handlers, so the architecture decision is which system is the authority, where it runs, and what the platform is allowed to store from its answer. Confirm with the eID or census owner whether they offer an OpenID Connect or SAML endpoint that your Decidim version can consume, and who operates it.
Census uploads are the other route, and they change the architecture more than teams expect. A file of residents loaded into the platform becomes personal data that the platform must protect, retain and delete on a schedule agreed with the city's data protection officer. Ask the census office for the minimum fields needed to match a participant, usually a document reference and a date of birth or address check, and configure the platform to store only a match result, not the full extract. One person, one vote controls depend on a stable unique identifier for each verified participant, so decide early how duplicates are handled and whether the identifier is hashed. Test the upload and matching path with synthetic records before any real census file is loaded, and record who can access the uploaded file.
Map, geocoding and social login services also need review before launch. Decidim's production setup can call external maps and geocoding providers, and a participant's address or location input may leave the country if that provider is hosted abroad. The same applies to any third-party login button shown to residents. For each external service, list the data sent, the provider's processing location and the contract terms, and decide whether to disable it, replace it with a service hosted in your jurisdiction, or limit the fields it receives. Document these choices in the records of processing your legal team maintains, because a municipality cannot delegate the decision to the software vendor.
How a municipal rollout moves from requirements to post-launch support
The sequence turns a council's participation goals and legal duties into a self-hosted Decidim site that residents can use, that staff can run, and that receives patches on a predictable upgrade path. Each phase closes with a written output that the council and data protection officer can review before the next phase starts.
Agree requirements and legal review
The council, the data protection officer, the records and legal teams, and the DeployOpen delivery lead agree which participation types go live first, such as a participatory budget, a consultation or a petition, and which personal data each one collects. The team also confirms the lawful basis, retention periods, and whether any process requires verified eligibility. The output is a signed requirements document and a data inventory that the data protection officer has reviewed. Ask the council to confirm the governing rules for each process before design starts, since they change what the build must enforce.
Decide hosting inside municipal or national infrastructure
The council's IT and security teams choose where the Decidim application, PostgreSQL database, file storage, background jobs and mail relay will run, whether in a municipal data center, a national government cloud or a cloud account the city controls. DeployOpen documents the network zones, backup location, administrator access model and the outbound services that would receive participant data, such as maps, geocoding or social login. The output is an approved architecture and a list of external services with their data locations. Confirm with your own security team whether any hosting option requires additional authorization under local policy.
Integrate identity and census verification
The team connects Decidim to the city's identity source for residents, either through an OmniAuth strategy or an authorization handler that checks a census extract or an eID service. Decidim supports Facebook, Twitter, Google and Decidim-to-Decidim OAuth 2.0 login out of the box, and any other OmniAuth strategy can be added as a custom provider, so the council must decide which methods are acceptable for civic participation. The team tests matching rules, duplicate handling and the data retained after verification. The output is a verification design and passing test cases for eligible, ineligible and duplicate residents.
Build the custom theme and test accessibility
Designers and developers build the municipal theme, forms, voting screens and document templates on the Decidim version selected for launch. The team tests every resident-facing page, including proposal and vote forms, against WCAG 2.1 Level AA, using automated checks and manual testing with assistive technology. The ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level A and AA, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts, and the council should confirm which applies to it. The output is an accessibility test report with a remediation log that the council accepts before pilot.
Run a pilot with test residents
A small group of staff and invited test residents completes the full participant journey, from registration and verification through proposing, commenting, voting and receiving notifications. Moderators practice removing content and staff confirm that results, exports and the public audit trail look correct. The team also checks email delivery, map behavior and performance under expected load. The output is a pilot report listing defects, their severity and a fix or accepted risk for each one, signed off by the process owner. Do not open the pilot to real residents until the verification and retention controls work as documented.
Launch with an accessibility statement
Before public launch, the council publishes its accessibility statement, the feedback route for barriers, and the privacy notice that matches the approved data inventory. Operators confirm backups run, monitoring alerts reach the on-call team, and the runbook covers incidents, account recovery and moderation escalation. Staff roles are assigned with the least privileges needed for each function. The output is a go-live checklist with named owners, signed by the council and the DeployOpen delivery lead, and a documented handover to the support team.
Maintain security patches and upgrades after launch
After launch, the operator tracks Decidim's supported branches, since security updates cover only the last two minor versions until version 1.0, and applies vendor security patches within the grace periods Decidim describes for standard and critical vulnerabilities. For each upgrade, the team takes a database backup first, upgrades one minor version at a time, and follows each release's upgrade instructions, because some changes alter database structures. The output is a dated upgrade record, a restore test result and a test log for each release, shared with the council. Ask any support partner to confirm these steps in its written retainer scope.
What municipalities ask before hiring an implementation partner
What drives the cost of a self-hosted Decidim platform for a city?
The cost is driven by who carries each line: infrastructure in the city's own cloud account or data center, the one-time implementation (installation, theme, custom components, identity and census integration, data migration), and the recurring work of hosting, patching, backups and support. Decidim itself is free software under the AGPL-3.0, so there is no licence fee to pay, but the AGPL-3.0 does carry source-sharing obligations for modified versions that the city's legal team should review. Ask any partner for a quote built from a written scope that separates one-time build work from annual operations, and check which integrations and custom components are included. The Decidim home page is a useful starting point for understanding what the platform already provides out of the box.
How long does a municipal Decidim rollout take?
The duration depends on scope, not on the software alone. The main drivers are the number of participatory spaces (processes, assemblies, initiatives), the number of components, whether a custom theme is needed for accessibility, how many identity or census sources must be connected, and how much historical data must be migrated. Hosting approvals, procurement cycles and security review by the city's own teams often take longer than the technical build. Ask any partner for a timeline tied to a fixed scope with named milestones, and confirm which approvals the city must obtain and how long each typically takes in its own process. Do not accept a duration that is not linked to written deliverables.
What must city staff provide before a Decidim build starts?
City staff typically provide four inputs: a census or resident extract for verification (only where the process requires eligibility checks), a written legal sign-off on the lawful basis, retention periods and any consultation obligations, a content and communications plan with named owners for each space, and access to the systems the platform must connect to, such as SSO or eID services. Staff also need to confirm which data may leave city infrastructure, because map, geocoding and social login services can send data abroad. Ask the partner to list every staff input as a dependency in the written scope, with an owner and a date, so delays are visible early.
Can a city run Decidim internally after launch?
Yes, a city can run Decidim with its own staff, but it needs a team that can handle Ruby on Rails and PostgreSQL operations, background jobs, file storage, SMTP, backups and security patching. Upgrades are not a single step: Decidim's update guide says to move one minor version at a time, follow each release's instructions because some change database structures, and back up the database first. Many cities choose a hybrid model in which internal staff own content and configuration while an implementation partner handles upgrades, hardening and incident support under a retainer. Ask internal teams to estimate their own staffing against that upgrade model before deciding.
Who patches Decidim within the security disclosure windows?
The implementer is responsible for applying patches within the windows, because Decidim's security policy gives implementers two months to apply patches for standard vulnerabilities and four months for critical ones before details are disclosed. The city must agree in writing who monitors security reports, who tests the patch, who deploys it, and who signs off on a production change. Only the last two minor versions receive security updates before version 1.0, currently 0.32.x and 0.31.x, so a city on an older branch must plan an upgrade rather than only a patch. Ask the partner to name the monitoring source, the test environment and the escalation path. Security reports go to security@decidim.org or GitHub Security Advisories.
Does NIS2 apply to a local authority running a participation platform?
NIS2 applies to central government entities regardless of size and lists public administration as a sector of high criticality, but it lets Member States extend the rules to local public administration. It also does not apply to entities working in national security, public security, defence or law enforcement. A municipality should therefore check its national transposition law rather than assume the answer. Even where NIS2 does not apply, the same security practices (access control, patching, incident handling and supplier management) are what auditors and councils will ask about. Confirm the position with the city's legal counsel and national cybersecurity authority.
How does DeployOpen support a municipal platform after launch?
DeployOpen supports self-hosted open-source platforms inside the client's own infrastructure, which includes upgrades, hardening, backups, documentation and support. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. A municipal support agreement should cover Decidim upgrades one minor version at a time, patch application within the disclosure windows, backup restore tests, accessibility regression checks after theme changes, and the handover of runbooks to city staff. DeployOpen does not publish a price list, so ask for a quote built from the written support scope.
What should a city confirm about accessibility duties before the build?
For US state and local governments, the ADA Title II rule requires web content and mobile apps to meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. Content and tools provided through contracts are included, so the partner's custom themes and components are in scope. Confirm your entity's population category, the date that applies, and whether your city is covered by any other accessibility regime. Ask the partner which WCAG criteria the custom theme will be tested against and who signs off on the results.
Evidence a municipal auditor or accessibility reviewer will ask for
This table maps each piece of evidence a municipal auditor, accessibility reviewer or council oversight body is likely to request to the component that produces it on a self-hosted Decidim platform. DeployOpen prepares this evidence from the build and operations, but auditors, accessibility assessors and certification bodies draw the conclusions, so confirm with them early which formats and samples they accept.
| Evidence | Who asks | Component that produces it |
|---|---|---|
| WCAG 2.1 AA test results for the live site and custom themes | Accessibility reviewer, council accessibility lead | Test plan and results covering public pages, voting and proposal forms, with defects logged and retested before launch |
| Accessibility statement and feedback records | Accessibility reviewer, residents raising barriers | Published statement, contact route for barrier reports, and a log of reports with dates, responses and fixes |
| Access control and verification configuration | Municipal auditor, election or ballot oversight body | Authorization handler settings, census upload rules, and records of which identity provider or OmniAuth strategy confirmed each participant |
| One person one vote and duplicate control settings | Municipal auditor, legal team | Configuration export showing vote limits per process, plus test evidence that repeat votes are rejected |
| Backup and restore records | IT audit, city CIO, records officer | Database and file storage backup schedule, retention, and dated restore tests that show data came back intact |
| Patch logs against Decidim security windows | Security auditor, IT audit | Upgrade log per minor version, with dates compared against the two-month standard and four-month critical patch windows in Decidim's security policy |
| Version support status | Security auditor, procurement | Record showing the deployed version falls within the 0.32.x or 0.31.x branch that receives security updates |
| Role and permission matrix for staff and moderators | Municipal auditor, data protection officer | Admin and moderator role list, who approved each grant, and periodic access reviews with removals recorded |
| Retention settings for proposals, votes and personal data | Data protection officer, records officer | Documented retention periods, purge job configuration, and logs showing deletion ran as scheduled |
Questions to put to an implementation partner for a city platform
Start with the version and the upgrade plan, because they decide how long the platform stays safe. Ask which Decidim minor version the partner will deploy and whether that line is still receiving security updates, since Decidim supports only the last two minor versions until version 1.0. Ask how the partner will move the city from one minor version to the next, one at a time, with a database backup before each step, and who pays for each upgrade under the agreed scope. Ask how the partner will apply security patches inside the grace periods Decidim gives implementers (two months for standard vulnerabilities and four for critical ones), and who monitors the security channel and on what schedule. Ask for the written upgrade runbook before signing, not after launch.
Next, ask exactly which identity and census sources the platform reads, where each one sits and who operates it. A city may connect a national eID or SSO through OmniAuth, an existing resident register, or a census file uploaded for a single process. For each source, ask whether the data is copied into Decidim or only checked at the moment of verification, which fields are stored, and how long they are kept. Ask how the partner will test authorization handlers against real eligibility rules, such as one person one vote in a budget, and what the platform records when a check fails. Then ask about accessibility testing for custom themes: which standard is the test baseline (the ADA Title II rule points to WCAG 2.1 Level AA for state and local government web content, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities), which tools and manual checks are used, and whether the partner will hand over test records for every custom template, including voting and proposal forms.
Finally, put hosting, data transfers, roles and scope in writing. Ask where each server, database, backup and file store runs, and list every third-party service that receives participant data, including maps, geocoding, email relays and social login providers, with the country where each one processes it. Ask who from the city will administer the platform, how the partner will train those staff and moderators, and whether training is in the fixed scope. Require a fixed scope with written acceptance criteria for each deliverable, including the test evidence, and a defined support window after go-live covering incidents, patches and upgrades. Ask what happens to the platform and its data if the support engagement ends.
Who runs the platform inside the city after launch
Once Decidim is live, the city needs named people who own content, moderation, the server, personal data and accessibility, so that each process keeps running without relying on the launch team. This sequence sets those roles up before go-live and shows how to confirm each one is working.
Assign a named owner for each participatory space
Each department that runs a process, budget, consultation or assembly appoints a process owner who decides the questions, phases, dates and outcomes for that space. The owner signs off the setup checklist before publication and remains the accountable contact for what residents see under that department's name. Done means every space in the launch plan has one named owner recorded in the governance document, with a deputy for absences.
Set up moderators and their escalation path
Moderators review reported comments, hidden proposals and flagged content against the city's published participation rules, and they are separate from the people who decide outcomes. The city writes a short escalation path so that a moderator can refer legal threats, harassment or data exposure to the right contact the same day. Done means moderators have been trained on the rules, have tested the reporting and hiding tools in a staging copy, and know who to call outside office hours.
Hand the server and upgrades to a technical operator
A technical operator, either city IT staff or a contracted team, owns the servers, PostgreSQL database, file storage, background jobs, mail relay and backups. This role also tracks Decidim security releases, applies them within the grace periods in the project's security policy, and performs one minor-version upgrade at a time, backing up the database first. Done means the operator has a written runbook, has restored a backup in a test environment, and can name the currently supported Decidim release line.
Name a data protection contact for participant records
The data protection contact is the city's point of contact for participant requests, retention rules for proposals, votes and verification records, and the agreement with any external provider of maps, geocoding or social login. This person checks which identity data the platform keeps after verification and confirms that deletion and export requests can be carried out in the database. Done means the contact has a documented procedure, has tested an export and a deletion on a copy of the data, and has the processing records updated.
Appoint an accessibility owner for content and themes
The accessibility owner is accountable for keeping the public site, the accessibility statement and the feedback route in working order, and for checking new processes, uploaded documents and any custom theme changes before they go live. Under the ADA Title II rule, state and local government web content must meet WCAG 2.1 Level AA, with compliance dates of April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts. Done means the owner has a publishing checklist, a recurring test schedule agreed with the implementer, and a log of reported barriers and fixes.
Agree support tiers and who answers residents
The city decides which questions the front-line team answers, which go to moderators, and which go to the technical operator, and it writes the expected response routes into the support agreement. Residents then get one published contact route, and the internal routing is tested with sample tickets. Done means the routing table is published internally, every role has been told what it covers, and any paid support or retainer scope is written down with what it excludes.
Review the operating roles on a fixed cycle
After each participation cycle, the process owners, moderators, operator, data protection contact and accessibility owner meet to review incidents, open security patches, reported accessibility issues and any change in staff. Gaps, such as a role left vacant after a staff move, are assigned before the next process opens. Done means the review produces a dated record of decisions and an updated roles register, which the city keeps with its governance documents.
How DeployOpen scopes, builds and supports municipal participation platforms
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the city's own infrastructure. For a municipal Decidim deployment, that means agreeing the scope in writing first, then building, testing and handing over a platform the council's own staff can run.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the spaces, components and identity checks the council will use, such as processes, budgets and census verification.
- We confirm where the platform runs, whether in municipal, regional or national infrastructure, and which hosting and data residency rules apply.
How we build
- We install Decidim as a Rails application or with Docker, and configure background jobs, file storage, SMTP, maps and geocoding.
- We connect the council's identity and census systems for verification and configure any social login providers the council approves.
- We test accessibility of the forms, proposals and custom themes against WCAG 2.1 Level AA before launch.
How we hand over
- We deliver documentation covering installation, configuration, backups, role assignments and the upgrade procedure for each Decidim minor version.
- We train the staff who will run participatory processes, moderate content and manage verification data.
- We prepare the system, controls and evidence the council needs for its own compliance assessments, which independent auditors then review.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after go-live.
- We apply security patches within the grace periods Decidim publishes, and we plan one minor version upgrade at a time with a database backup first.
- Ask us to confirm response times, upgrade windows and out-of-hours cover in the written retainer before you commit.
