> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-portal/government-portal.md). # Government Portal A multi-tenant government CMS: one platform serving many agency websites, with shared security, governance and infrastructure. **When Government Websites Work for Everyone** Government websites should be simple: apply for benefits, check taxes, find services. Instead, each ministry looks different, uses different designs, has different security. Citizens never know if their data is safe. The Government Portal / CMS Building Block solves this: one platform, one governance model, many independently-run agency websites. ## Who Are You? {% tabs %} {% tab title="Citizen" %} Government websites should be simple: apply for benefits, check taxes, find services. Instead, each ministry looks different, uses different designs, has different security. You never know if your data is safe. **CMS BB value proposition for you:** One consistent experience across all government services. Same design, same security, same reliability. Patches deploy instantly everywhere. No confusion. No surprises. **In practice:** Rwanda's 200+ government sites run on one platform. Citizens see one consistent system across all ministries. **Explore further:** * See It Live — Real examples and demos of government CMS systems in action *(Watch It Work — not yet published)* {% endtab %} {% tab title="Decision Maker / Government Leader" %} You manage 50 government websites as 50 separate problems. Different vendors, different contracts, different compliance frameworks. Changing one accessibility standard takes 6 months. When security crises hit, your government looks unprepared. **CMS BB value proposition for you:** One platform. One governed system. You set standards (WCAG 2.2 AA, encryption, branding). They apply to all 200 sites instantly. You control infrastructure. Your government owns the code — no vendor lock-in. **In practice:** Germany unified its federal government on TYPO3 multitenancy. One standard everywhere. Each ministry keeps full content autonomy. **Explore further:** * [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md) — The 10 core capabilities every government CMS needs * [Choose Your CMS](/experience-digital-transformation/government-portal/from-concept-to-production-choose-your-cms.md) — Six-step selection process and evaluation framework * [Scale From 1 Portal to 100](/experience-digital-transformation/government-portal/scale-from-1-portal-to-100-multitenancy-explained.md) — Governance model and growth timeline * Watch It Work — Live demos and open-source code examples from real government implementations *(not yet published)* * Getting Unstuck — Help, expert tips, and community resources for implementation decisions *(not yet published)* {% endtab %} {% tab title="Ministry / Government Agency" %} Your ministry manages its website independently. Your colleague's ministry uses a different CMS. Citizens face different designs, workflows, and language styles across government. When government mandates new accessibility or content standards, you coordinate it yourself. **CMS BB value proposition for you:** You keep full autonomy over your content and messaging. But citizens experience one coherent government: consistent structure, consistent language, consistent design. Your editors work in one familiar system. Infrastructure burden disappears — government patches and secures everything instantly. **In practice:** Rwanda's ministries each manage their own content on one TYPO3 platform. Health ministry runs health content. Labor ministry runs labor content. They're completely independent but citizens see one coherent service. **Explore further:** * [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md) — Content management and publishing without technical barriers * [Scale From 1 Portal to 100](/experience-digital-transformation/government-portal/scale-from-1-portal-to-100-multitenancy-explained.md) — How agency autonomy works within one platform * Master the System — Training and workflow resources *(not yet published — see note at the end of this page)* * Watch It Work — Live demos showing how other ministries manage content and publish *(not yet published)* * Getting Unstuck — Help and community tips for content teams and editors *(not yet published)* {% endtab %} {% tab title="Security Officer / Compliance Lead" %} A critical vulnerability appears and you coordinate patches across 50 different CMS platforms. WordPress patches today, Drupal tomorrow, TYPO3 patches only the latest version. Some sites go down. Others stay vulnerable. Compliance audits are nightmares: 50 different systems, 50 different audit trails. **CMS BB value proposition for you:** One patch. All 200 sites secure instantly. Compliance becomes one audit framework applied automatically everywhere. No coordination. No sites left behind. Incident response becomes real response, not chaos. **In practice:** Rwanda's single platform means one security team, one patch cycle. A vulnerability discovered Monday is closed across all 200+ sites by Tuesday. **Explore further:** * [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md) — Security and compliance requirements * [Technical Deep Dive](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs/technical-deep-dive.md) — Security requirements and user permission specifications * [Choose Your CMS](/experience-digital-transformation/government-portal/from-concept-to-production-choose-your-cms.md) — Evaluating platforms for security capabilities * Learn at Your Pace — Training on compliance frameworks and security procedures *(not yet published)* {% endtab %} {% tab title="Technical Team (Lead, Architect, Developers)" %} Your team maintains five different CMS platforms on five versions. When someone leaves, critical knowledge walks out the door. Developers maintain legacy systems instead of building features. They learn five codebases instead of mastering one. Architects design for five systems. Leadership can't coordinate anything. Innovation is impossible. **CMS BB value proposition for you:** One system. One codebase. One team of experts beats five silos every time. Developers master the platform deeply. Architects design once. Leadership coordinates one platform. The entire team grows together and finds time to innovate. And you own the code — customize freely without vendor permission. **In practice:** Rwanda's TYPO3 team: architects design governance, developers own the complete codebase, leadership coordinates one platform. When customization is needed, developers modify code directly. **Explore further:** * [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md) — Core capabilities and technical requirements * [Technical Deep Dive](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs/technical-deep-dive.md) — Complete specification: architecture, APIs, data models, integration requirements * [Choose Your CMS](/experience-digital-transformation/government-portal/from-concept-to-production-choose-your-cms.md) — Six-step evaluation framework with capacity building criteria * Learn at Your Pace — Training and documentation for developers on architecture and customization *(not yet published)* * Watch It Work — Live demos of architecture, customization, and real-world technical implementations *(not yet published)* * Getting Unstuck — Expert technical tips, troubleshooting, and community support *(not yet published)* {% endtab %} {% tab title="Operations Team / DevOps" %} Your job is coordinating patches across 50 platforms. WordPress plugin update, Drupal core update, TYPO3 database migration, Joomla security incident. You fight fires constantly. You have no time to think about performance or reliability. You react, day after day. **CMS BB value proposition for you:** Operate one platform well. Patch once, deploy everywhere, verify stability. Monitor one dashboard. Respond to incidents once. You have capacity to plan improvements instead of constantly reacting. **In practice:** Rwanda's operations team manages one TYPO3 instance with 200+ sites. One team. One monitoring system. One deployment process. **Explore further:** * [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md) — Core capabilities and operational requirements * [Scale From 1 Portal to 100](/experience-digital-transformation/government-portal/scale-from-1-portal-to-100-multitenancy-explained.md) — Implementation timeline and capacity building * Master the System — Learning resources and training for operations teams *(not yet published — see note at the end of this page)* * Watch It Work — Live demos of monitoring, deployment, and operations workflows *(not yet published)* * Getting Unstuck — Expert troubleshooting tips and community support for operations *(not yet published)* {% endtab %} {% endtabs %}
:list-check:

The Playbook: What Every Government CMS Needs

The ten core capabilities every government CMS must have, based on the CMS Building Block specification.

The Playbook: What Every Government CMS Needs
:microchip:

Technical Deep Dive

Backend/frontend requirements, data structures, APIs and architecture, for architects and developers.

Technical Deep Dive
:code-compare:

From Concept to Production: Choose Your CMS

A six-step selection process and evaluation framework, with real government examples.

From Concept to Production: Choose Your CMS
:layer-group:

Scale From 1 Portal to 100: Multitenancy Explained

How multitenancy works, the governance model, and a growth timeline from pilot to 100+ sites.

Scale From 1 Portal to 100: Multitenancy Explained
{% hint style="info" %} Three further pages — **Watch It Work** (live demos and open-source code), **Learn at Your Pace** (videos, docs and training), and **Getting Unstuck** (help, expert tips and community) — are planned but do not yet have source content. They are not included below; see the note at the end of this page. {% endhint %} ## Proven by Real Government Deployments These government deployments demonstrate the approach in practice: * **Rwanda:** 200+ government sites on TYPO3 multitenancy. One team manages infrastructure. One security patch protects all 200 sites instantly. * **Germany:** TYPO3 is the federal government standard. All ministries unified. One coherent system — agencies kept their content autonomy. * **United States:** 15+ federal agencies run on shared Drupal infrastructure. One platform, one team. These aren't small deployments. They're real, complex, multi-agency systems. You're not experimenting. You're following a proven path. {% hint style="info" %} **A note on "Explore further" links above:** three planned pages — Watch It Work, Learn at Your Pace, and Getting Unstuck — don't have source content yet and aren't published. Some source text also refers to a "Master the System" page, which isn't part of the currently planned page tree; it's left unlinked here pending clarification of whether it maps to one of the three pending pages. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-portal/government-portal.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.