Building a shared open source publishing platform for local government - LocalGov Drupal FAQs

We aim to update this regularly. Last updated 20/08/2026

Something missing? If you have a question for us, please email Tim.

How LocalGov Drupal started

LocalGov Drupal started with a simple problem.

Councils were building and rebuilding similar websites, solving similar problems, often with limited budgets and small digital teams. Every organisation needed service pages, news, directories, alerts, accessible templates and a reliable way for content teams to publish information.

The question was: could councils share more of that work?

LocalGov Drupal is one answer to that question. It is an open source publishing platform, built and maintained by councils and suppliers working together. It gives councils a common starting point, while still allowing each organisation to meet local needs.

Discover more about our story >

Why do local authorities choose LocalGov Drupal, and what are the main benefits they typically realise?

Councils choose LocalGov Drupal because it is built around common local government needs, rather than requiring each organisation to start from scratch. It provides a strong foundation for accessible publishing, service information, directories, alerts, news and more.

The code is open source, so councils are not tied to one software supplier or annual licence fees. They can choose who builds, hosts and supports their site, while benefiting from improvements funded and tested by other councils.

The benefits vary by project, but often include a quicker route to launch, lower long-term costs, more control over the platform and less duplicated development. More than 75 live council CMS sites now exist, giving new users a substantial pool of real-world experience to draw on.

Could you provide examples of councils using LocalGov Drupal and demonstrate how it has delivered measurable benefits?

Councils of different sizes and operating models across the UK and Ireland use LocalGov Drupal.

Waltham Forest reported savings of £90,000 in development costs and three to six months of development time. It also reported a 25% improvement in resident satisfaction, 10% to 15% fewer calls to its resolution centre, a 96/100 Siteimprove accessibility score and pages loading 40% faster than on its previous site. Read the Waltham Forest case study.

Essex County Council’s SEND Local Offer was built in four months. The council reported that its in-house team could add directory listings 40% faster, alongside improved accessibility and easier access to information for families. Read the Essex case study.

Milton Keynes reported annual hosting, penetration testing and technical support costs of £21,800, while also highlighting the value of owning and continuously improving its platform. Read the Milton Keynes case study.

About the distribution

How is LocalGov Drupal structured technically?

LocalGov Drupal is a Drupal distribution and installation profile.

In practical terms, that means it is a pre-configured version of Drupal for council websites. It brings together Drupal core, contributed Drupal modules, LocalGov Drupal modules, themes and default configuration.

The product includes common publishing tools that many councils need, including:

• Service landing pages and service pages
• News
• Directories
• Alert banners
• Step-by-step content
• Guides
• Subsites
• Editorial workflows
• Search
• A base theme that councils can customise

There is also a separate LocalGov Drupal Microsites product. This lets a council run many smaller websites from one Drupal installation. Each microsite can have its own content, users, files, domain and visual identity.

The important point is not just the code. It is the pattern. Start with what almost every council needs, then make it reusable, documented, and easy to improve.

How do you manage configuration?

LocalGov Drupal uses Drupal’s configuration management system.

When a new site is installed, the LocalGov Drupal installation profile enables default modules and themes, and sets up the starting configuration. Individual council sites then manage their own configuration as part of their normal deployment workflow.

A common approach is to:

• Install the site locally using Composer and a local development tool such as DDEV or Lando
• Export Drupal configuration into a config sync directory
• Commit that configuration to a Git repository
• Deploy code and configuration through development, test and production environments
• Run database updates, import configuration and clear caches as part of deployment

LocalGov Drupal is careful about changing configuration on existing sites. Once a council has launched, its configuration may have changed from the original defaults. The project therefore avoids pushing configuration changes that might overwrite local decisions. When a shared change is needed, update hooks and release notes can be used to explain and apply the change.

Some individual councils may use tools such as config split or config ignore for environment-specific configuration, but the main principle is simpler: shared defaults come from the distribution, and local configuration belongs to the individual site.

What is included in the core distribution, and what do councils build themselves?

The core distribution includes the common building blocks that most council publishing teams need.

That includes content types, editorial tools, default workflows, reusable page patterns, common modules, documentation and a base theme. The aim is to give councils a strong starting point, not a finished website that removes all local decision-making.

Councils are still expected to make decisions about:

• Branding and visual design
• Content strategy and information architecture
• Hosting and infrastructure
• Local integrations
• Migration from legacy systems
• Any highly specific service journeys or local requirements
• Training and internal publishing processes

Most councils use a large part of what comes out of the box. Some use it with relatively light changes. Others extend it with custom modules, integrations or more substantial front-end work.

The shared platform works best when councils ask: “Is this only for us, or could other councils use it too?” If the answer is “others could use this” and it usually is, it is a candidate for contribution back to the project.

How do you handle versioning and releases?

LocalGov Drupal uses Drupal.org, Composer and tagged releases.

We release the product and its modules as Drupal projects. Sites use Composer to manage Drupal core, contributed modules, themes and LocalGov Drupal packages. 

The composer.lock file records the exact versions used by a site, so deployments can be repeated reliably.

Releases can include alpha, beta, release candidate and stable versions. Stable releases are intended to be safe for councils to use, with the usual expectations around security, performance, testing and documentation.

Release notes are important. They help councils and suppliers understand what has changed, what needs testing, and whether any manual steps are needed during an update.

What options are available for integrating Drupal with external systems such as forms, payments, CRM and back-office applications?

LocalGov Drupal is designed to be extended. Drupal includes standards-based REST and JSON:API tools, and has a large ecosystem of modules and experienced suppliers. This means it can connect with forms platforms, payment services, CRM and case-management systems, identity providers, mapping, directories and other back-office applications.

The right approach depends on the system, data sensitivity and the user journey. Some integrations are available through established modules; others need a small piece of custom work. For example, Croydon developed an integration that lets staff build forms in LocalGov Drupal while sending submissions into Netcall’s Liberty Create case-management system. Read the Croydon example.

Any integration should be assessed for security, accessibility, data protection, support arrangements and what happens when either system changes.

Content Management

What does a typical implementation and migration approach look like for a council replacing an existing CMS?

A successful implementation normally starts with discovery. The council audits its current site, understands user needs, agrees priorities and decides what should be removed, rewritten, migrated automatically or moved manually. This is an opportunity to improve content, not simply copy an old site into a new system.

The team then configures LocalGov Drupal, develops the local design and any integrations, and tests the site with users. Content migration is usually iterative, with editors trained before launch. The final stages include accessibility and security testing, redirects, search, analytics, publishing processes and a clear support plan.

The balance between automated and manual migration depends on the quality and complexity of the existing content. Milton Keynes and Waltham Forest both chose substantial content review rather than treating migration as a purely technical exercise.

How does the platform support content management, publishing workflows and governance for large organisations?

LocalGov Drupal gives teams structured content types and reusable page components, so content can be created consistently without needing technical support for every change. This makes it easier to maintain clear information architecture, service content and consistent user journeys across a large site.

Its optional workflow tools support roles, permissions, content moderation, approval dashboards, preview links, scheduled publishing and review dates. Content can move through draft, review, published and archived stages, with a record of revisions. Councils can adapt this to suit centralised or devolved publishing models, while retaining appropriate oversight. See the LocalGov Drupal workflow guidance.

How well does Drupal support multiple websites, microsites and shared content across services?

Drupal is well suited to organisations that need to manage a wider digital estate. Alongside the main CMS, LocalGov Drupal Microsites lets a council run many distinct websites from one platform. Each site can have its own domain, users, content and files, while the central team maintains shared code and core functionality.

This gives services and campaign teams the independence they need without leaving the web team responsible for many disconnected systems. It is particularly useful for programme sites, community organisations, legacy council sites and local government reorganisation. More than 50 LocalGov Drupal microsites are now live. Find out how Microsites works.

Shared content should be planned carefully. Councils can reuse components, design patterns and structured information, or use integrations where information needs to be maintained in one system. Keeping some content separate can also be the right choice, particularly where services need local control.

Development and operations

What does the workflow look like from idea to release?

Ideas can come from many places: a council product owner, a content designer, an in-house developer, a supplier or the LocalGov Drupal core team.

A typical route looks like this:

• Someone identifies a need that may be shared by more than one council
• The idea is discussed with the community, product leads and technical contributors
• The team checks whether the need is genuinely common, whether it fits the roadmap, and whether it should be part of the core distribution or an optional module
• The work is scoped in the open, ideally through Drupal.org issues or another public issue queue
• A council, supplier, the core team or a group of councils funds or carries out the work, sometimes through our Community Fund.
• Developers build the feature, add tests, write documentation and open it for review
• The work is reviewed, tested and merged
• It is included in a release and communicated to the community

This does not mean every idea needs a large process. Small fixes can move quickly. Larger features need more care, especially if they affect existing sites or create long-term maintenance responsibilities.

The Community Fund is one way LocalGov Drupal supports shared development. If several councils need something, they can contribute to a shared pot rather than each paying separately for similar work.

How does the LocalGov Drupal community operate, and how can councils influence future development and the product roadmap?

LocalGov Drupal is run by councils, for councils, with support from suppliers and the Open Digital Co-operative. Councils share experience through Slack, meet-ups, working groups, events and the project’s open documentation and code repositories.

The Product Group helps set the roadmap, releases and quality standards. The Technical Group leads on architecture, development practices, security and maintenance. The core team coordinates day-to-day work and helps turn shared priorities into deliverable projects. 

Councils can influence the roadmap by sharing user research, raising issues, joining working groups, testing new features and contributing funding or staff time. The current roadmap is shaped by council, supplier and core-team feedback.

Do you use shared test or staging environments?

Individual councils usually have their own development, staging and production environments. These are managed by the council, their hosting provider or their supplier.

For the shared platform, contributors can use local development environments and preview builds to test changes before they are merged. Pull requests and merge requests are tested as part of the contribution process.

The important distinction is this: LocalGov Drupal maintains the shared codebase, but each council remains responsible for testing updates against its own content, integrations, hosting and local configuration.

Two councils may use the same distribution, but they may have different content models, custom modules, hosting setups and publishing workflows.

How do you ensure quality and backwards compatibility?

Quality comes from a mix of technical standards and community habits.

LocalGov Drupal uses automated tests, code review, documentation and release notes. New functionality should have test coverage. Existing tests need to keep passing. The project also has quality standards for areas such as accessibility, documentation and testing.

Backwards compatibility is handled carefully because councils run real public services on these sites. The project avoids making unnecessary changes to active configuration on existing sites. When changes are needed, they should be documented clearly and handled through Drupal update processes.

There is also a human layer to quality. Councils and suppliers talk to each other. They test things in real-world conditions. They share problems before they become larger failures. This is one of the quiet benefits of the collaboration.

How do you manage Drupal core and contributed module updates?

Drupal core and contributed modules are managed through Composer.

In a council project, Composer is used to update Drupal core, contributed modules, LocalGov Drupal packages and themes. Teams then run database updates, import configuration where needed, clear caches and test the site.

In practice, this work may be carried out by an in-house team, a supplier or a hosting partner. The shared project can provide guidance, patches and release notes, but each live site still needs its own update and testing process.

A shared distribution reduces duplication, but it does not remove the need for good operational discipline. Someone still needs to own security updates, monitoring, backups, deployments and testing.

How are security, patching, resilience and disaster recovery managed within a typical LocalGov Drupal deployment?

Security is a shared responsibility between the council, its hosting or support provider, and the open-source communities that maintain Drupal and LocalGov Drupal. Drupal security advisories and LocalGov Drupal releases provide the basis for keeping software up to date, while the council or supplier applies updates through an agreed maintenance process.

A typical production arrangement includes secure configuration, least-privilege access, regular patching, monitoring, backups, tested restoration procedures and separate development, test and live environments. Resilience and disaster recovery are mainly determined by the chosen hosting architecture and support contract, not by the CMS alone.

LocalGov Drupal provides security guidance and has commissioned security testing, but each council should agree clear responsibilities, update timescales, backup retention and recovery objectives with its provider.

What hosting and support models are available, and what level of in-house capability would a council typically require?

Councils can host LocalGov Drupal with a specialist supplier, through their own cloud arrangements, or through a hybrid model. The open-source model means they can change provider if needed, rather than being locked into a single platform vendor. Councils use a range of hosting solutions, including Azure and AWS, depending on their wider technology strategy.

A council does not need an in-house Drupal development team to use LocalGov Drupal. Many rely on a supplier for hosting, technical support, upgrades and new development. However, councils get the best results when they retain ownership of content, user needs, information architecture, accessibility and product decisions.

The community provides documentation, technical drop-ins and peer support. Councils can also use the certified supplier directory to identify experienced partners.

How does LocalGov Drupal support accessibility requirements and compliance with public sector standards?

Accessibility is built into LocalGov Drupal’s approach. Its public-facing components are designed to meet or exceed WCAG 2.2 AA, with accessibility testing guidance that includes automated checks, manual testing, basic screen-reader testing and user testing where possible. The platform also includes accessible design patterns based on established public-sector practice.

However, no CMS can make a website compliant on its own. Councils remain responsible for the content they publish, their local design and custom development, third-party tools and their accessibility statement. This matters because public sector bodies must meet WCAG 2.2 AA where required and publish an accessibility statement. Government guidance explains these responsibilities.

Per-organisation customisation

How do you support local needs without fragmenting the platform?

The answer is to make sharing the default, not an afterthought.

Councils can build what they need locally, but they are encouraged to do it in the open and with reuse in mind. That means discussing needs early, checking whether other councils have the same problem, and designing features so they are not tied too tightly to one organisation.

LocalGov Drupal also separates different types of need.

Some needs belong in the core distribution because many councils have them.

Some needs are better as optional modules because they are useful to several councils, but not everyone.

Some needs should remain local because they are specific to one council, one integration or one service.

That distinction helps avoid a bloated core product. It also protects local flexibility.

Do organisations use the distribution as-is, or extend it?

Most councils use a lot of the standard product. That is where the value comes from.

But councils also adapt it. They may create a custom theme, add local integrations, enable optional modules, add their own configuration or build custom features.

Forking is possible because the code is open source, but it is not the preferred route for most councils and us. A long-term fork can become expensive to maintain. The healthier pattern is to extend the platform, contribute reusable work back where possible, and only diverge when there is a strong reason.

Open source gives councils that freedom. The collaboration gives them a reason not to use it unnecessarily.

How do you balance flexibility and standardisation?

The platform works because it does not try to make every council identical.

Standardisation is strongest where councils have common needs: publishing service information, managing alerts, listing locations, creating directories, handling news, applying editorial workflows and meeting accessibility expectations.

Flexibility is strongest where councils need local control: branding, content strategy, integrations, hosting, governance and internal processes.

A useful rule is this: standardise the foundations, localise the experience.

That lets councils share the cost of common infrastructure while still serving their own residents, languages, policies and organisational structures.

Lessons learned

What have been the main technical challenges?

The first challenge was turning something built from one council website into a generic distribution that could work for many councils.

Code that works for one organisation is not always ready to become shared infrastructure. It needs clearer assumptions, better documentation, stronger tests and more careful decisions about what belongs in core.

Another lesson was to work in the open as early as possible. LocalGov Drupal spent time working on GitHub before moving more of the work to Drupal.org. That move made the project more visible to the wider Drupal community and made it easier for others to contribute.

A third challenge is configuration. A distribution can provide defaults, but existing sites change over time. You cannot assume every live site still matches the original install. That is why configuration updates need care.

How did you grow from a small number of councils to the current scale?

LocalGov Drupal started with a small group of councils and support from central government funding. That funding required collaboration and open source working.

The early group did not start with a perfect governance model. They started with a shared problem, some funding, a practical technical base and a willingness to work together.

As the project grew, it needed more structure. Councils and suppliers needed a way to contribute, make decisions and fund shared work. The project eventually moved into Open Digital Cooperative, a not-for-profit multi-stakeholder co-operative that supports the financial sustainability of LocalGov Drupal.

The growth came from a mix of things:

• Councils could see other councils using it
• Suppliers could build expertise around a shared platform
• The product solved recognisable problems
• The community created trust
• The open source model reduced lock-in
• Shared funding made larger improvements possible

There was no single magic moment. It was more like laying paving stones across a muddy field. Each council, supplier, release and event made the next step easier.

What were the key turning points?

Several things helped LocalGov Drupal grow.

• Central government funding gave the project a start and required councils to collaborate
• The existing Drupal community gave the project technical foundations, contribution habits and experienced developers
• Working in the open, especially through Drupal.org, makes it easier for people outside the original group to see what was happening and get involved
• Having subscribers and certified suppliers and creating Open Digital Cooperative gave the project a legal and financial home after the original funding ended
• The Community Fund gave councils a practical way to fund shared improvements without needing every council to contribute to every feature.
   

How did governance and decision-making evolve?

At the start, the project was relatively informal. A small group of councils, suppliers and core contributors made most decisions through regular collaboration.

As more organisations joined, the project needed clearer governance.

LocalGov Drupal is now supported by Open Digital Cooperative. The co-operative includes councils and certified suppliers. Strategic decisions sit with the board and the wider governance structure. Day-to-day work is supported by the core team.

There are also groups focused on product and technical direction. These groups help shape the roadmap, review technical decisions, maintain standards and support contributors.

The lesson for international partners is to avoid building too much bureaucracy too early. You need enough structure to make decisions and handle money, but not so much that the work stops moving.

What made it attractive for others to join rather than build their own solution?

LocalGov Drupal helps councils avoid solving the same problems alone.

A council joining the project gets a tested starting point, a community of peers, access to suppliers who understand the platform, and a way to influence future development.

The open source model also changes the risk profile. Councils are not locked into a single vendor or closed product. They can inspect the code, contribute to it, adapt it and move between suppliers.

For smaller councils, the shared model can amplify their voice. They may not have the budget to fund a large feature alone, but they can help shape and fund it with others.

For larger councils, the benefit is different. They can invest in improvements that also strengthen the wider ecosystem they depend on.

Were there challenges in scaling the collaboration?

Yes.

Scaling a collaboration is not just a technical problem. It is also a trust problem, a funding problem and a capacity problem.

Challenges included:

• Some organisations benefit more than they contribute
• Councils have different budgets and procurement rules
• Suppliers may have different commercial interests
• Product priorities do not always align
• Councils need local control as well as shared standards
• A small core team can become a bottleneck
• Too much governance can slow things down

LocalGov Drupal has addressed these issues in practical ways. 

• Council subscriptions help fund the core work. 
• Supplier subscriptions recognise that suppliers benefit commercially from the shared platform. 
• The Community Fund supports larger pieces of shared development. 
• Open working makes decisions more visible. 
• The co-operative structure gives the project a long-term home.
• It is not perfect. No collaboration is. The aim is to make contribution easier, make decisions visible and keep the benefits of sharing greater than the effort required.

Additional lessons learned

Several lessons travel well:

• Public bodies often have more in common than they think.
• Shared code works best when it is supported by shared governance.
• Open source needs funding, not just goodwill.
• A small core team can help many organisations move in the same direction.
• Suppliers can strengthen the ecosystem when incentives are clear.
• The most valuable work is often the least glamorous: documentation, testing, maintenance, facilitation and release management.
• Local flexibility matters. Shared platforms fail when they try to remove all local judgement.
• LocalGov Drupal is not just a website platform. It is a way for councils to share the cost and effort of building public digital infrastructure.

For international partners, the starting point is simple: find the shared problem, bring the right people together, and build something useful enough that others want to improve it with you.