Drupal for a Government Portal: Sovereign, Highly Available Hosting on PaaS in Frankfurt

Drupal runs a remarkable share of the world's government websites, because it is open source, accessible by design and has nothing to hide from an auditor. Where it runs is the harder question, and public-sector procurement rules have tightened around it: EU data, a named data centre, an exit plan. This post follows a municipality's digital-services lead answering those rules with Drupal on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The organisation is a mid-sized German municipality we will call Stadt Lindenau, replacing a portal on an ageing on-premises server with a citizen-services site: forms, appointment booking, council documents, in German and three community languages. The Drupal package installs the current Drupal release via Composer with Drush, a tuned PHP application server and a MariaDB database.

The four procurement requirements

The tender's hosting annex was short and firm. Data location: personal data processed within the EU, in a named facility. Availability: 99.9% measured monthly, with a documented failover design. Exit: the municipality must be able to leave with its data and configuration within 30 days. Open standards: no proprietary lock-in in the application or the platform layer. The lead's job was to show how a Drupal environment met each, and the answers came mostly from the platform rather than from Drupal.

Data location: a region, not a promise

The environment is created in the Frankfurt region, which is a specific data centre the provider names, operated under an ISO 9001-certified management system and a GDPR data processing agreement. The region is a property of the environment, visible in the dashboard and the API; it does not move unless someone migrates it. Backups, taken by the Database Backup/Restore add-on to a Backup Storage node, stay in the same region. The lead put a screenshot of the region field in the compliance annex, which the auditor accepted in a way a paragraph about "EU regions" would not have been.

Availability: separate hosts, live migration, a cluster when needed

The portal launched as the package's standard topology, one PHP application server and one database, and the lead's availability design rests on what the platform does under any topology. Containers in an environment are placed on different physical hosts by anti-affinity, so the database and the application server do not share a failure domain. A container whose host degrades is live-migrated to another host in about thirty seconds without a restart. The provider's SLA is 100% uptime for the platform. For the portal itself, the lead added what the 99.9% target needed: an NGINX load balancer and a second PHP node, with the Drupal files directory on shared storage mounted into both, and a MariaDB primary-secondary cluster with ProxySQL from the marketplace, so no single container's loss takes the site down.

Exit: proven, not promised

The exit requirement is where most hosting proposals wave their hands. The lead tested it before signing anything. The platform's environment export produces a portable package of the environment's topology and data; Drupal itself is a Composer project with a lock file, a database dump and a files directory, all of which restore onto any PHP host. He exported the pilot environment, imported it into a second test environment, and confirmed the portal came up. The exit plan in the annex is that procedure with timings, and it took an afternoon rather than 30 days.

Isolation and access, because it is a municipality

The portal environment sits in its own environment group with network isolation, so the municipality's other environments (an intranet wiki, a test copy of the portal) cannot reach its database over the internal network. The container firewall exposes 443 on the balancer and nothing else; Drupal's admin paths are additionally restricted to the town hall's IP range. Access to the platform account uses collaboration roles: the agency that builds the site can deploy and view logs, the municipality's IT can change topology, and the data protection officer has read-only access to see the region and backups for herself.

Accessibility and multilingual content, where Drupal does the work

Drupal's core handles what a public portal must: WCAG-conformant themes, content translation with the four languages as first-class configuration, and a forms module for citizen requests. None of that is the platform's concern, and the lead was clear in the tender response about which layer answers which requirement. What the platform contributed was that the agency could clone the environment to test each accessibility fix and each Drupal minor update against real content before it reached citizens, at a cost of cents per clone.

The cost line the council saw

Two PHP nodes, a balancer, two MariaDB nodes with ProxySQL and a storage node average about 60 cloudlets an hour (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU), roughly $145 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, plus disk, a public IP and backup storage. The hyperscaler proposal the municipality had also received was priced per instance with a separate managed-database fee, a separate load balancer fee and egress charges, and its region list did not name a facility. The council's finance committee understood one number that moved with usage; the data protection officer understood one region. That was the decision.

Frequently Asked Questions

Does the platform itself hold any citizen data outside the region?

The environment's containers, disks and backups are in the region you choose. Platform account data (your login, billing) is held by the provider under its DPA. Ask the provider for the DPA and sub-processor list; MassiveGRID publishes its GDPR compliance details.

Can Drupal multisite serve several municipal sites from one environment?

Yes. Drupal multisite works on a single application server with separate site directories and databases, and additional domains point at the same environment. For sites with different security classifications, separate environments in separate isolated groups are the cleaner answer.

How are Drupal security updates applied?

With Composer and Drush, the same as anywhere: clone the environment, run the update on the clone, test, then apply to production during a short window. Drupal's security advisories give the schedule; the clone gives the safety.