Cloud-nativeDutch cloudPortability

Cloud-native development for a Dutch cloud

Cloud-native applications are built to run in the cloud: in containers, with automated deployments and infrastructure defined as code. Appfront applies those principles on Dutch and European infrastructure. We build with open standards rather than proprietary hyperscaler services, so your application remains portable between Dutch providers. We build the software; the hosting runs with specialist Dutch infrastructure partners.

What is cloud-native development for a Dutch cloud?

Cloud-native development means an application is built for the cloud from the first design: split into services, packaged in containers, with configuration separate from the code and fully automated deployments. With the large American hyperscalers, cloud-native quickly becomes intertwined with proprietary services in practice: managed databases, queues, functions and identity services that exist only on that one platform. Anyone building on those is tied to a provider subject to the US CLOUD Act and FISA, even when the servers are located in the EU.

We turn that around. We build cloud-native on open standards: Kubernetes for orchestration, PostgreSQL as the database, S3-compatible object storage and open source components for caching, queues and monitoring. As a result, the same application runs on any Dutch or European provider that offers these building blocks, and moving between providers remains a manageable operation. Cloud-native and sovereignty thus go hand in hand: the portability that cloud-native promises only becomes reality if the application is not tied to hyperscaler services.

This approach matches the direction of the revised Dutch government cloud policy of 3 July 2026, which requires storage and processing within the EEA and asks government organisations for an annual exit plan. An application built to be portable from the start effectively has that exit plan built in. If you want to bring an existing environment under EU jurisdiction, also look at building a sovereign cloud.

How we approach this

1
Architecture and provider selection
We design the application architecture based on your requirements for data, integrations and compliance, and select a Dutch infrastructure partner together with you that suits it.
2
Building to the 12-factor methodology
We build stateless services with configuration held in the environment, explicit dependencies and logs as an event stream, so the application behaves the same wherever it runs.
3
CI/CD and infrastructure as code
Every change goes to production through an automated pipeline with tests and reviews. The entire infrastructure is held in code and is reproducible with any provider.
4
Go-live and continuous development
After go-live, we provide monitoring, security updates and ongoing development, and we keep portability intact with every change.

What we build and manage

Cloud-native applications
New web applications, portals and APIs, built from the first line of code for Dutch and European infrastructure.
Containers and Kubernetes
Applications packaged in containers and deployed on Kubernetes, the open standard for orchestration at virtually every European provider.
Open data layer
PostgreSQL, S3-compatible object storage and open source components for caching and queues, rather than proprietary hyperscaler services.
CI/CD pipelines
Automated building, testing and deployment, so releases are predictable and repeatable.
Infrastructure as code
The entire environment documented in code, so it is reproducible and an exit or migration does not become guesswork.
Management and monitoring
Ongoing maintenance, observability and security updates for the environment, handled with your infrastructure partner.

For whom

Government and public sector

Organisations subject to the government cloud policy and the BIO that want to set up new applications directly within the EEA and with a workable exit plan.

Healthcare

Institutions processing medical data under NEN 7510 and the GDPR, and that do not want to entangle new systems with non-EU services.

Financial sector

Parties falling under DORA that need control over outsourcing risks and the exit strategy of their ICT supply chain.

SaaS and product companies

Software builders for clients who require data residency in the Netherlands or the EU, or who must account for their supply chain under NIS2 and the forthcoming Cybersecurity Act.

Technology and approach

We deliberately choose technology available from multiple providers. No functions, queues or databases that exist only with a single hyperscaler, but open components that run on any Kubernetes environment. This keeps the application portable and leaves you free to choose between Dutch providers, now and later.

Kubernetes and containers
PostgreSQL
S3-compatible object storage
Terraform / OpenTofu
CI/CD pipelines
Open source components
Encryption in transit and at rest
Monitoring and logging

Why Appfront

Appfront is a software and app development agency. We build the applications and set up the deployment; the infrastructure runs with Dutch partners who specialise in it. Because we don't sell hosting ourselves, our advice on providers and architecture is independent. What this gives you: an application that is portable between providers, an exit plan that holds up on paper and in practice, and no forced migration or rebuild when regulations or your choice of provider change. If existing software needs to be addressed, sovereign software rebuilding is often the better route.

  • Cloud-native from the start, not as a retrofit
  • Open standards so the application remains portable between providers
  • Independent advice, we do not sell hosting ourselves
  • Knowledge of GDPR, NIS2, DORA, NEN 7510 and BIO built into the architecture

Frequently Asked Questions

What does cloud-native development mean for a Dutch cloud?
Cloud-native means an application is designed from the outset to run in the cloud: in containers, with loosely coupled services, automated deployments and configuration kept separate from the code. We apply these principles to Dutch and European infrastructure, using open components rather than services that exist only with a US hyperscaler.
Does Appfront host the applications itself?
No. Appfront is a software and app development agency; we build the applications and set up the deployment. Hosting runs with specialist Dutch infrastructure partners, selected according to your requirements for location, certification and management.
Will I miss functionality if we don't use hyperscaler services?
Almost all the building blocks of the large hyperscalers have mature open alternatives: PostgreSQL for managed databases, S3-compatible object storage, Kubernetes for orchestration, and open source solutions for queues, caching and monitoring. The difference lies mainly in convenience at the start, not in what is ultimately possible.
Can we switch Dutch providers later?
Yes, that is precisely the aim of this approach. Because the application runs on containers, Kubernetes and open standards, and the infrastructure is defined as code, moving to another Dutch or European provider is a manageable operation rather than a rebuild project.
Does this align with the Dutch government cloud policy and NIS2?
The revised Rijkscloudbeleid of 3 July 2026 calls for storage and processing within the EEA, a risk assessment per workload, and an annual exit plan. Building cloud-native on Dutch infrastructure makes that exit plan concrete and executable. For NIS2, DORA, NEN 7510 and BIO too, it helps that you can demonstrably maintain control over where data resides and what the chain looks like.
We already run on a US hyperscaler, what now?
Then we first look at how deeply the application is entangled with proprietary services. Sometimes it is enough to containerise the application and replace a few services; sometimes partial rebuilding is wiser. We map this out and draw up a realistic step-by-step plan.

Getting started with cloud-native development

Would you like to build a new application from the start for Dutch infrastructure, portable and without entanglement with hyperscaler services? We are happy to think along with you on architecture and choice of provider.

Edit content