Infrastructure is not only an IT question: It's a tracking question
When a company evaluates a server-side tracking platform, most of the conversation is about data quality, connectors and consent. The layer underneath rarely comes up until legal or IT joins the call, and then it comes up all at once: which country processes the data, who has access to it, what happens during a traffic spike, and who is accountable when a node fails at two in the morning.
For a tracking platform those questions are not peripheral. Server-side collection means the vendor's infrastructure sits in the path of every event on your website. If it cannot scale, data is lost. If it processes outside the EU, the compliance argument collapses regardless of how the product behaves.
This article covers how the JENTIS platform is built underneath, drawing on the Cloud Success Story published by IONOS.
The requirement that came first: processing stays in the EU
JENTIS was founded in Vienna in 2020 by Thomas Tauchner, Klaus Müller, Christian Kletzander, Walter Parigger and Robert Nachbargauer. The premise from the beginning was that companies should be able to collect web data without giving up control of it, and that the raw data should stay with the customer rather than the vendor.
That premise sets a hard constraint on the hosting layer. A platform built to keep European companies out of third-country transfer problems cannot itself process data outside the EU. The infrastructure partner had to guarantee that data would not be passed to third countries or processed beyond EU borders, and that guarantee had to be contractual rather than a matter of configuration.
This is also why the choice was never simply about price or availability. Most of the largest cloud providers were excluded by the requirement itself.
Why not on-premise
Running its own hardware was considered and dismissed early. For a small team, on-premise infrastructure would have absorbed exactly the engineering capacity the product needed, and the economics did not work at that stage.
There was a second reason. JENTIS customers range from mid-sized firms to large enterprises across banking, automotive and e-commerce, and their resource requirements differ widely from the first day of a deployment. A fixed infrastructure sized for an average customer would have been wrong for most of them. What the platform needed was the ability to define its own server topology and change it as demand changed, not a provider template with resource allocations already decided.
Kubernetes was a requirement rather than a preference, since the product is built as a containerised microservice architecture.
What ruled providers out
Several providers were tested before the decision. The recurring problems were structural rather than incidental: no managed Kubernetes offering, no persistent volumes, and support arrangements where responsibility was unclear when something went wrong. Those partnerships ended quickly. The debugging load that comes with an infrastructure partner who cannot answer questions is a direct cost to a small engineering team.
Managed Kubernetes as the foundation
The platform runs on a managed Kubernetes cluster within the IONOS Cloud ecosystem, with the microservice architecture behind it.
Two properties matter operationally. The first is demand-based scaling: capacity follows the shape of the workload rather than a provisioned maximum, which is what allows very different customer sizes to run on the same platform. The second is self-healing. The clusters recover automatically from component failures without manual intervention, which keeps maintenance effort proportionate to the size of the team running it rather than the size of the estate.
For customers, the relevant consequence is that a traffic spike on your site is an infrastructure event handled by the platform, not an incident that requires your team to do anything.
The storage problem that decided the choice
The most technically interesting part of the story is a limitation rather than a feature.
At the start of the collaboration, only Kubernetes Persistent ReadWriteOnce volumes were available, which did not fit the JENTIS use case. ReadWriteMany was needed, and it did not exist in the offering.
Rather than treating this as a blocker, the two engineering teams wrote a custom storage class on top of S3 storage that provided ReadWriteMany and covered the requirement. JENTIS has described this as the make-or-break issue in the decision, and it was resolved by building something that was not on the product roadmap.
That is a reasonable thing for a buyer to weigh. Infrastructure partnerships are usually judged on the feature list. This one was decided by what happened when the feature list came up short.
Three databases, three jobs
The data layer uses three stores, each for a distinct purpose:
- Redis acts as a message queue, buffering data in transit. If something downstream fails, the buffer is what prevents events from being dropped.
- MongoDB serves as a key-value store for fast lookups.
- MySQL holds the larger data volumes.
Consent integration and pseudonymisation happen inside this pipeline before data reaches any destination. Customers decide whether JENTIS stores their raw data at all, and from there the data is forwarded to the tracking tools already configured on the customer side. [Confirm current architecture. Some of this reflects the 2023 setup.]
Support as a selection criterion
Technical support was named as a deciding factor rather than a supporting one. Round-the-clock access to engineers who could answer questions competently, including during the trial period before any contract existed, carried real weight. So did direct working sessions with Kubernetes specialists during the design and build phases.
This is worth stating plainly because it applies to how JENTIS works with its own customers. A platform team that needed responsive infrastructure support in order to move quickly builds a service model around the same principle.
What this means if you are evaluating JENTIS
Four things follow from the architecture described above, and they are the ones worth raising with your own IT and legal teams:
- Processing happens inside the EU, on infrastructure contracted on that basis. [Confirm current hosting regions and DPA wording]
- You keep your raw data. Whether JENTIS retains it is a customer decision, not a platform default.
- Scaling is the platform's problem. Capacity adjusts to your traffic without a sizing exercise on your side.
- The infrastructure is managed, not self-hosted. Your engineering team implements the base code and a DNS record. It does not operate servers.
