Cloud and data infrastructure for geo and data platforms

A geo or data platform consists of more than the application users see. Underneath run a database (often PostgreSQL with the spatial extension PostGIS), a map or feature server, background jobs that fetch and convert data, storage for files and an environment that collects logs and alerts. Those parts decide whether a platform stays fast, secure and affordable.

TechinFlow designs and manages that lower layer, separately or together with the application on top. Think of setting up a database cluster for a data platform, the hosting of a GIS viewer for a municipality or the servers behind an open data platform.

We describe the infrastructure as code. Every server, every network and every database setting is then held in text files in a repository. That allows an environment to be rebuilt, makes every change traceable in the version history and lets another administrator see exactly what is running. It also makes test and production environments identical, which prevents surprises at go-live.

What we do not do is operate a data centre ourselves. Computing power and storage come from a hosting partner or cloud provider that you choose together with us, or that you already have.

This service suits organisations that want to run their own geo or data environment and keep control of it, with a focus on government bodies and organisations with comparable demands on security and accountability.

• A good fit if you have an application or data platform built and do not want the hosting to disappear into a black box at the builder.
• A good fit if an existing environment was set up by hand, nobody knows exactly how any more, and you want to make it reproducible.
• A good fit if you want to know what a move to another provider would take before you renew a contract.
• Not a fit if you are looking for workplace management, email or office automation. That is a different line of work.
• Not a fit if your organisation already has a central hosting facility that all applications must use. In that case we would rather deliver an installation package and documentation to that department.

If you are unsure what fits your situation, start with a conversation about what runs now and who manages it. Sometimes the answer is that nothing needs to move and only the documentation is missing.

Our starting point is that data and backups stay within the European Economic Area. That is a design choice, not a certificate. Whether a provider really complies, you check in the contract documents and not on the provider's homepage.

Look at three things. Where are the servers and backups physically located? Which sub-processors does the provider use, for example for support or monitoring, and where are they based? And which country's law governs the provider's parent company? The second point is often forgotten, even though remote support can mean access to data.

If the platform processes personal data, the actual division of roles determines who is controller and who is processor. The Dutch Data Protection Authority (Autoriteit Persoonsgegevens) explains that an organisation that processes data only on instruction is a processor, and that with a party that itself determines the purpose and the means you do not need to conclude a processor agreement. In hosting, the hosting partner is usually a processor for the municipality or organisation, and so is TechinFlow as administrator. Put that chain on paper before any data enters the environment.

If it concerns open data without personal data, the requirements are lighter. But even then you want to know where the source sits and who can reach it.

According to Digitale Overheid, the Baseline Informatiebeveiliging Overheid (BIO, the Dutch government information security baseline) is the basic framework of standards for information security across all layers of government and the basis for accountability about it. Responsibility stays with the government organisation itself. A supplier can carry out and demonstrate measures, but does not take over the accountability.

This table is a starting point. In the exploration we fill it in together for your situation, so that no task falls between two parties. ENSIA is the yearly accountability process for information security that Dutch municipalities and other bodies use.

An exit is only credible if it can be carried out without the original supplier. For infrastructure that means three things: the infrastructure code sits in a repository of the client, the data can be exported in open formats, and the applications run in containers that are not tied to one cloud.

For municipalities Haven is a useful reference point. According to its own documentation, Haven is a generic layer between applications and a municipality's IT infrastructure, so that applications can be hosted anywhere without adapting them to that specific infrastructure. Everything in Haven is open source, including tools and reference implementations. If your municipality already runs a Haven environment, we set the application up for that instead of for a cluster of its own.

In addition, the European Data Act, which applies from 12 September 2025, sets rules for switching between providers of data processing services. Article 23 states:

Providers of data processing services shall take the measures provided for in Articles 25, 26, 27, 29 and 30 to enable customers to switch to a data processing service, covering the same service type, which is provided by a different provider of data processing services, or to on-premises ICT infrastructure, or, where relevant, to use several providers of data processing services at the same time.

Source: Regulation (EU) 2023/2854 (Data Act), Article 23, EUR-Lex. That helps, but it does not replace your own preparation. Practise a move once on a test environment: rebuild the environment at a second provider from the code and restore a recent backup. Only then do you know the exit works.

The advisory side of exit requirements, for use in a tender or contract, is covered under technology and software consultancy.

1. Inventory. What runs, where, in which versions and who has access? For a new environment, the requirements of the application replace this step.
2. Design. A short architecture description with components, network, backup strategy and the division of responsibilities from the table above.
3. Build as code. The environment is built from the repository, first as a test, then as production.
4. Restore test. We restore a backup onto an empty environment and record how long it took and what went wrong.
5. Handover or management. You receive the repository, a management manual and the agreements on monitoring, patches and alerts. Management can stay with TechinFlow or go to your own team or another party.

Each step delivers something you can use even without a follow-up. An inventory is usable for a tender, a design for another builder, and a restore test for your accountability. If you want an existing environment reviewed, get in touch with a short description of what runs.

If you first doubt the architecture itself, for example between a cluster of your own and a managed cloud service, technology and software consultancy is a logical first step. The application layer on top of this infrastructure is described under web and app development.