What a Decidim implementation involves
Decidim is free to license. It is a participatory democracy framework released under the AGPL-3.0 and built on Ruby on Rails and PostgreSQL, so the license line in your plan is zero. The budget goes to what surrounds the software: hosting, configuration of participatory spaces and components, integrations with your identity and email systems, content, translations, and support during the first live process. Plan those lines separately from the code, because they are where most of the money and time go.
Organizations usually start this planning for one of three reasons. A city, region or agency may be launching its first participation platform. Another may be consolidating several consultation tools into one place. A third may be replacing an engagement SaaS whose contract, data location or customization limits no longer fit. Each trigger changes the plan. A first launch needs a clear set of processes, components and roles. A consolidation needs a decision on which existing tools retire and when. A replacement needs a view of how existing participants, proposals and records will move, which is covered on the migration page.
Many organizations keep part of the work in-house and hand technical setup, hosting and integration to a partner. Content, process design, moderation rules and communication with participants usually stay with the public body, because they depend on local政策 knowledge and institutional trust. Hosting, deployment, identity integration, verification rules and launch support are the parts that most often move to a partner. The split is driven by two things: how many people your team can release for the project, and whether you have staff who can run a Rails and PostgreSQL service after launch.
Upgrades, security hardening, single sign-on and identity verification, and cost of ownership are covered on their own pages, so this section does not go into them. Before you ask for a quote, confirm which components and spaces you need in the first release, who owns moderation and content, which languages are required, and which identity provider or eID must be connected. Those answers determine the scope that a fixed-price quote is built on.
What the implementation includes
The implementation is split into workstreams that each end in a named deliverable. Use this list to compare our scope with what your own team would have to build, and to see which items drive the quote.
Hosting and environments
We set up production, staging and backup environments in the cloud accounts, data centers or air-gapped network you control. Staging should mirror production closely enough to rehearse upgrades and restores. The handover is a configured environment set with a documented backup schedule and a tested restore procedure.
Rails application installation
We install Decidim as a Rails application, either manually or with Docker, and pin the Ruby, Node and PostgreSQL versions that the chosen release requires. Confirm which release branch you want before work starts, because the supported branches change over time. The handover is a versioned installation record and the deployment configuration.
Background jobs, file storage and email
We configure ActiveJob workers, ActiveStorage file storage for uploads and attachments, and SMTP for account and notification mail. Each depends on capacity and on whether your mail and storage services are already approved internally. Check delivery testing and upload limits early, since they affect how proposals and documents behave under load. The handover is a service configuration record.
Maps and geocoding
We configure the map provider and geocoding service used by meetings and location fields. Confirm which provider your data policy allows, because some options send address data to external services. Plan the API keys, usage limits and fallback behavior before launch. The handover is a documented map and geocoding configuration.
Organization and branding setup
We create the organization, set its public name, domains, default locale, logos, colors and legal pages. Decide early whether one instance will host several organizations, since that changes access and moderation design. The handover is an approved branding and organization configuration record.
Participatory spaces and components
We build the processes, assemblies and initiatives your program needs, then enable components such as meetings, surveys, proposals, participatory budgets and accountability. Each space is mapped to a component set and a stated purpose. The handover is an approved component map showing which spaces use which components.
Verification and authorization rules
We implement the verification and authorization rules set out in the design, so that actions such as voting or signing require the right level of verified identity. These rules often need legal and policy sign-off, and they are hard to change after participants have started using the platform. The handover is an authorization rule record and test results for each rule.
Translations and locales
We set up the languages your audience needs, load translation files and review interface text, including any custom wording for your program. Ask who approves translated text and how new strings will be handled after launch. The handover is a locale configuration and a translation review log.
Launch of the first process
We help you publish the first participatory process with its content and assign moderation and content roles to named people. Test the moderation workflow with real staff before public access opens. The handover is a launch checklist, a role assignment record and a runbook for daily operations.
What drives the cost and duration
Each driver shows why it changes implementation effort and how to keep it contained, and because no price list is published, a quote follows from a written scope.
| Driver | Why it changes effort | How to keep it contained |
|---|---|---|
| Organizations or sub-sites on one instance | Each organization adds branding, languages, verification settings, social logins and moderation staff to configure and test. | Start with one organization and write a per-organization configuration template before adding sites. |
| Languages and locale-prefixed URLs | Each language needs translation, review and routing tests. Locale-prefixed URLs arrived in v0.32.0, so confirm the target release first. | Limit languages to those with a named reviewer, and confirm URL behavior in the chosen release before design starts. |
| Spaces and components | Each process, assembly, initiative and component adds content types, settings, permissions and test time. | Launch with the components the first process needs, and add others through later change requests. |
| Verification rules | Each action restricted to verified participants adds an authorization handler, test cases and user-facing help text. | Restrict only sensitive actions such as voting or signing. Identity provider detail is covered on the SSO page. |
| Branding, theme and accessibility | Templates, styles and accessibility testing grow with each design change and each organization's identity. | Reuse the default theme with configured colors, logos and content, and test accessibility on shared templates once. |
| Custom modules or processors beyond configuration | Custom code must be built, tested and carried through every minor upgrade, and Decidim upgrades one minor version at a time. | Confirm each need against existing settings and components first, and document custom code for the upgrade plan. |
| Hosting, environments and availability | Manual Rails or Docker installs, PostgreSQL, background jobs, file storage, SMTP and higher availability targets each add setup and testing. | Use one standard reference setup, one staging environment and written availability targets confirmed before quoting. |
| Data import volume | Imported participants, proposals and process history need mapping, cleaning, duplicate checks and trial loads. | Import only records that must stay public, and run at least one trial load before setting a launch date. |
| Approval and moderation roles | Each moderator, administrator and approval step adds permissions to define, train on and audit. | Define roles and an approval policy before the build, and keep the number of roles to what the process needs. |
Project phases and what each produces
The sequence moves a Decidim platform from agreed goals to a staged, reviewed instance and then to a launched first process with support in place.
Agree scope and participation goals
The client and DeployOpen review participation goals, the organizations and spaces involved, required languages, identity verification rules and privacy obligations. DeployOpen records the answers and turns them into a written scope. The step closes when the client signs the scope and the list of open decisions.
Design architecture and hosting
DeployOpen documents the target hosting environment, the pinned Decidim release line, the Ruby and Node runtimes, the PostgreSQL version, file storage and the backup plan. The release line is confirmed at kickoff, because both the 0.32 and 0.31 branches receive security updates and releases move. The step closes with a signed architecture record.
Build and configure the staging instance
DeployOpen installs Decidim in the client's environment and configures background jobs, file storage, SMTP, maps and geocoding, and any agreed social login providers. Identity and authorization settings are wired to the agreed verification rules. The step closes with a working staging instance that the client can log into and test.
Apply branding and translations
The organization's branding, logos, themes and email templates are applied to the staging instance. Agreed languages are configured and the translation work is tracked against a list of required strings and pages. The step closes when the client approves the look, language coverage and copy on staging.
Set up content and components
DeployOpen creates the participatory spaces, such as processes, assemblies or initiatives, and enables the components the client has chosen, such as meetings, proposals, surveys or accountability tracking. Permissions, moderation roles and initial content are configured and checked with the client's staff. The step closes with a signed configuration checklist.
Complete security and accessibility review
Before public access, the staging instance is reviewed for supported version status, server and Rails configuration, admin access, upload handling, backup restores and accessibility against the agreed criteria. Findings are logged, fixed or accepted in writing by the client. The step closes with a review report and a list of accepted risks.
Launch the first process with hypercare
DeployOpen runs the go-live against a launch checklist, opens the first participatory process and hands over an operations pack with runbooks, backup and restore steps and contacts. The hypercare window is agreed in writing before launch and covers the period after go-live. The step closes with a signed handover pack and the end of hypercare.
What usually goes wrong and how to prevent it
These six risks come up most often in Decidim plans. Each one has a decision or check you can write into the quote and the launch plan.
Scope drift after the quote
Spaces, processes and components added after the quote change the build, the test effort and the hosting load. Decidim offers processes, assemblies, initiatives and components such as meetings, proposals and participatory budgets, and each addition needs its own configuration, moderation roles and translations. Freeze the list of spaces and components in writing, and route every change through a dated change request.
Languages added late
Each language adds interface strings, process descriptions, component texts and email templates. Adding a locale after content exists means translating and re-checking pages that are already published, and template changes can break layouts. Decide the full locale list before content entry starts, and confirm how URLs are structured by locale in the release you install, since v0.32 introduced locale-prefixed URLs.
Verification rules set after launch
Authorization handlers decide who can vote, support or sign. If rules change after participants have already acted, you must explain which votes qualify and which do not. Agree the verification method, the data it stores and the actions it gates before the first process opens, and confirm with the owner of your identity provider or eID that the handler works in production.
Hosting sized for a pilot
A pilot with a small group says little about launch week, when many participants register, comment and vote at once. Size the application servers, PostgreSQL, background job workers and file storage for the expected peak, then load test a representative scenario in staging. Ask the hosting team which tiers scale horizontally and which need a larger single machine.
Untested production dependencies
Background jobs (ActiveJob), file storage (ActiveStorage) and outgoing email over SMTP must work in the production configuration before go-live. Stopped job workers halt notifications and processing, and a misconfigured SMTP relay can block account confirmation, which blocks registration. Test each path end to end, and restore a database backup into a separate environment at least once before launch.
Installation on an unsupported release
Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x. Version 0.32 requires Ruby 3.4.7 and Node 22.14.x, while 0.31 uses Ruby 3.3.4 and Node 22.14.x, so a server built for other runtimes will fail or drift. Name the release line in the quote, confirm runtime versions in the install guide for that release, and plan upgrades one minor version at a time.
What your team keeps and what a partner takes
This table shows which Decidim implementation work teams usually keep and which they usually hand to a partner, and a team with Linux, Ruby on Rails and PostgreSQL experience can keep more in-house, but the right split depends on who will run the platform after launch.
| Work area | Usually kept in-house | Usually outsourced | Skills needed |
|---|---|---|---|
| Governance and process design | Deciding who runs participatory processes, approval rules and public commitments | Facilitating design workshops and drafting process templates for each space | Public participation practice, legal and policy review, facilitation |
| Content and moderation | Publishing content, moderating proposals and comments, answering participants | Moderation playbooks, training for moderators, edge-case reviews | Civic communication, moderation policy, Decidim admin roles |
| Languages and translation review | Approving final wording, checking local terms and tone | Setting up locales, translation workflows and bulk translation tooling | Target-language fluency, local civic vocabulary, Decidim translation tools |
| Hosting, email and background jobs | Owning the cloud or data center account, DNS, backups and mail relay contracts | Configuring the production stack, SMTP, ActiveJob workers and file storage | Linux administration, Docker or manual installs, SMTP and queue operations |
| Rails and PostgreSQL operations | Routine monitoring, backup checks and applying minor updates | Major upgrades, database tuning, migrations and recovery drills | Ruby on Rails, PostgreSQL administration, upgrade and rollback practice |
| Branding and theme work | Supplying brand guidelines, logos, color choices and approving the final look | Theme customization, layout changes and cross-browser checks | Rails views, CSS and Decidim theming conventions |
| Integration with identity or CRM systems | Providing identity provider details, verification rules and data protection decisions | OmniAuth configuration, authorization handlers and CRM sync design | OAuth and OIDC, Ruby development, identity administration |
| Testing and accessibility checks | User acceptance testing of processes and sign-off on accessibility goals | Automated test runs, accessibility audits and fixes for findings | Rails testing, WCAG-oriented auditing, assistive technology use |
| Launch support | Staffing the first process, communications and participant support | Go-live checklist, cutover rehearsal, on-call support and handover documents | Release management, incident response, runbook writing |
How the work differs by starting point
A new deployment starts with no legacy content or users, so the early weeks go to decisions rather than data work. Discovery centers on which participatory spaces and components the first processes need, who moderates them, and how public launch will be staged.
- Discovery: agree the first spaces (processes, assemblies or initiatives) and components, and name the staff who will moderate and publish.
- Hosting: choose between a manual Rails installation and Docker, and confirm where background jobs, file storage, SMTP, maps and geocoding will run.
- Verification: decide which actions (voting, signing, proposing) require an authorization handler and what evidence the authority accepts.
- Launch: plan a soft launch with a limited audience, then a public announcement once moderation and branding are checked.
- Confirm: the target Decidim minor version, the hosting region and the translation languages needed on day one.
Moving from a commercial engagement platform adds a data and trust workstream that a new deployment does not have. The work is shaped by what must survive the move, such as public proposals, votes and process history, and by how the old platform will be retired.
- Discovery: inventory the spaces, components and public records in the current platform, and decide which history must be visible after cutover.
- Hosting: provision the new environment before data work begins so that test loads can run in the organization's own infrastructure.
- Verification: confirm how existing participant identities map to the new accounts and how verification status is carried over or re-collected.
- Launch: plan a redirect and announcement period so that links to old processes do not break during the switch.
- Confirm: which data the current vendor will export, in what format, and whether any content is licensed in a way that restricts reuse.
Data mapping and cutover steps are covered on the migration page.
When an instance already runs, the main risks are changes to live users and existing customizations. Discovery focuses on the current version, installed modules and the spaces that must keep working during the extension.
- Discovery: record the current Decidim version, Ruby and Node versions, and every custom module or theme in use.
- Hosting: confirm whether the new spaces need additional capacity, background job workers or storage.
- Verification: check that any new space uses the same authorization rules as existing ones, and test those rules against real account types.
- Launch: release new spaces behind a staging review, and avoid bundling them with a version upgrade in the same release window.
- Confirm: whether the instance is on a supported minor version, since upgrades must go one minor version at a time with a database backup first.
A container-based deployment changes how the application is built, configured and recovered, but not what Decidim needs from its services. The team must decide how the container images, database and storage are managed in their cluster.
- Discovery: confirm the cluster platform, the team that owns it, and whether Decidim will share it with other workloads.
- Hosting: define how PostgreSQL, file storage and background job processes are deployed, and whether they run inside or outside the cluster.
- Verification: test image builds, configuration secrets and rolling restarts in a non-production cluster before the first public release.
- Launch: agree how a version upgrade is rolled out as a new image and how a failed rollout is reverted.
- Confirm: the Docker and Kubernetes versions your platform team supports, and who holds responsibility for backups and restore tests.
Deployment inside a government data center or an air-gapped network changes how software, dependencies and updates reach the system. Discovery must account for the transfer process before any build work starts.
- Discovery: map the approved route for bringing software packages, language dependencies and container images into the network, and who approves each transfer.
- Hosting: confirm that email, maps, geocoding and social login providers can be reached, or replace them with internal services.
- Verification: plan how security patches reach a network with no direct internet access, and how the grace periods for patches fit that transfer cycle.
- Launch: schedule the first release around the authority's change approval process, which often has fixed windows.
- Confirm: which external services are blocked, and whether the authority must approve each component before it is installed.
Running several organizations or languages on one instance adds configuration and governance work that a single-site launch does not. Each organization needs its own branding, moderators and login settings, and each language needs reviewed content.
- Discovery: list the organizations, their shared and separate spaces, and the languages each must support at launch.
- Hosting: decide whether all organizations share one instance and database, and confirm the capacity needed for peak use across them.
- Verification: configure social login and authorization per organization, and test that one organization's rules do not affect another.
- Launch: stagger the launches so that each organization's moderators and translators can review their content before going live.
- Confirm: who approves translations, how long review takes for each language, and who owns content in each organization.
What you need to provide before the work starts
Most of the Decidim plan depends on decisions that only your organization can make. Before the work starts, name an executive sponsor who can settle scope disputes, and a platform owner who will approve configuration, speak for the project to other departments, and hold the admin accounts after launch. Confirm the hosting location and the cloud account, data center or air-gapped network where Decidim will run, including who holds the billing and root access. These choices set the infrastructure the quote covers, so they should be made first.
Next, gather the technical inputs the installation depends on. Decidim runs on Ruby on Rails and PostgreSQL, and production setups configure background jobs, file storage, SMTP, and maps and geocoding. Provide DNS control for the domain and any subdomains, a decision on URL structure for each language, working SMTP credentials for sending notifications, and a choice of map and geocoding provider with its terms of use. Also confirm which social login providers you want, if any, because each one needs its own registration and credentials.
Content and governance inputs are just as important. List every language the platform must support and name a translator or review partner for each, since translation effort grows with the number of locales and the amount of custom text. Supply branding assets and a style guide. Ask legal to approve the identity verification and privacy requirements in writing, including which actions require verified participants and what personal data may be stored. Assign a moderation and content owner for each space, and set a launch date tied to the first process, because missing items in this list are the most common cause of schedule change.
Frequently asked questions
Does Decidim have a license fee?
No. Decidim is free, open-source software licensed under the AGPL-3.0, so there is no license fee to pay. Cost sits in hosting, configuration, content, translations, moderation and support. Ask any partner to split the quote into one-time implementation work and recurring operations, and to state who pays for hosting. The AGPL-3.0 also has obligations for modified versions, including some that apply when a modified version is offered over a network, so ask your legal team to confirm what applies to any custom modules you plan.
How long does a first Decidim process take to launch?
The first process launches when the written plan says it can, and the date depends on scope and on your decisions. Drivers include the participatory spaces and components you choose, verification rules, branding, languages, data import and the number of approval rounds. Delays usually come from decisions that remain open at the start. Ask for a plan with dated milestones, a named owner for each decision, and a list of client inputs such as content, legal text and identity provider access.
Can our own team implement Decidim without a partner?
Yes, if your team already has working skills in Ruby on Rails, PostgreSQL and Linux operations. Decidim runs as a Rails application on PostgreSQL, and production setups also configure background jobs, file storage, SMTP, maps, geocoding and social login. Your team would own installation, upgrades, security patching and backups from the start. The trade-offs are covered in the in-house section of this page. If those skills are missing, compare a fixed-scope partner plan with hiring before you commit.
What changes a Decidim implementation quote the most?
Scope changes the quote most. The number and type of participatory spaces and components, custom modules, integrations with your identity provider or verification service, data migration from another platform, branding depth and the number of languages each add work. Hosting location also matters, since a platform in your cloud, a data center or an air-gapped network needs different setup and operations. Ask for each quote to list these as separate line items with stated assumptions, so you can see which decision moves the price.
Can we start a Decidim project on an older release?
No. Plan on a supported release line. Until version 1.0, Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x, and 0.30.x and earlier are not supported. Starting on an older line means upgrading first, one minor version at a time, following each release's upgrade instructions and taking a database backup before each step. Ask the partner which release line the plan targets and how the upgrade path would be scheduled.
What does a client receive at Decidim handover?
The handover package depends on the written scope, so ask for it to be listed before work starts. Expect to confirm access to the deployed environment, source and configuration in your control, documentation of hosting and installed components, the backup and restore procedure, an upgrade plan for the supported release lines, admin training and a list of open decisions. Confirm whether ongoing support or upgrades are included or run as a separate retainer, since DeployOpen offers these as retainers.
How DeployOpen scopes, delivers and hands over Decidim
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and Decidim is delivered the same way. The plan for a Decidim platform is agreed in writing before build work starts, so hosting, spaces, components and launch decisions are visible to the organization first.
How we scope
- Engagements are fixed-scope, with the Decidim deliverables, timelines and exclusions agreed in writing before work starts.
- The written scope lists the participatory spaces and components to be enabled, such as processes, assemblies, proposals or participatory budgets.
- Scope records hosting location, verification rules, branding, languages and the first process to launch, which set the basis for a quote.
How we build
- Installation runs in infrastructure you control, configured for background jobs, file storage, SMTP, maps and geocoding.
- Branding, translations and per-organization social login settings are configured and reviewed with your communications and legal staff.
- Authorization rules for voting or signing are tested with sample verified and unverified accounts before any public process opens.
How we hand over
- Handover documents the deployed version, configuration decisions, backup procedure and the database backup taken before any update.
- Your administrators receive a walkthrough of moderation, process setup and the update steps for one minor version at a time.
- Confirm with DeployOpen which Decidim branch is supported at handover, since only the last two minor versions receive security updates.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Upgrade work follows each release's instructions and the security patch grace periods published by the Decidim project.
- Security reports for Decidim go to the project's own channels, and DeployOpen can plan how your team receives and applies advisories.
