The infrastructure choices in a Pwas project.

All components run on European cloud, with a managed database and backups under agreed policies. It's the configuration that costs least to run and doesn't tie up your infrastructure team.

It suits most projects, including many applications handling ordinary personal data. It becomes unsuitable where contractual data residency constraints exist, where integrations concern systems that never leave the corporate network, or where your organisation has an explicit policy against it.

What to verify first: who operates it and under which service levels, how you access logs and metrics, and how restore works.

The same components run in your infrastructure: a virtual machine with container execution is enough to start, an orchestrator becomes the natural choice when high availability and zero-downtime updates are needed.

It's the frequent configuration in healthcare, public sector, finance and utilities, for three recurring reasons: regulatory or contractual constraints on data, integrations with systems that live only inside the corporate network, and infrastructure teams that prefer to keep everything in-house.

What to verify first: who operates the environment and with what skills, how monitoring and backups integrate with the tools you already use, and how component updates get applied.

The outward-facing part — customer portal, citizen area, public interfaces — sits on cloud; the application core and sensitive data stay on site, with a controlled channel between them.

It's often the right configuration when you must expose something to external users but can't or won't move everything. It carries a cost in operational complexity — two environments instead of one, a channel to watch — that should be weighed deliberately.

What to verify first: which data crosses the channel and how often, what happens when the channel is unavailable, and who is responsible for which half.

A serious project has at least a production environment and one where changes are verified before being applied. Because every project is an isolated environment with its own network, volumes and ports, creating a second environment is an ordinary operation rather than a parallel infrastructure to design.

The configuration describing the domain is versioned like any document, so promoting a change from the verification environment to production is a controlled, reconstructable step rather than a manual intervention.

Where data separation is a requirement, the verification environment works on anonymised or synthetic data. That's a choice to make at the start: building a realistic test dataset afterwards is far harder than it sounds, and in practice it's why so many projects end up verifying changes in production.