Hey all,
I’d like to connect with those of you who are actively running canisters on the European Subnet to exchange experiences and insights.
In particular, I’m interested in topics like performance characteristics (e.g. latency, update call behavior), cycles usage and cost patterns, as well as overall production experience (stability, scaling, monitoring).
Anyone here actively running canisters on the European Subnet? I’d be interested in exchanging experiences.
Let’s claim the first spot here:
Our portfolio follows the structure of our SOVERI dApps suite, SOVERI - Product Suite
No Web2 fallback - fully served from the IC
Used for real project execution, not demos
We are already running multiple real production workloads on the European Subnet - from 6 websites to a multi-canister business system (SIM).
This is not a test setup - it is operational infrastructure, although we have test setups, running in other subnets.
We do not yet but we are planning to. I will keep an eye on this thread 
@rbole Looking at this thread https://forum.dfinity.org/t/has-anyone-solved-the-phi-pii-compliance-gap-for-tees-on-icp-when-regulators-require-a-business-arrangement-agreement-or-equivalent/67463?u=nicko - I wonder how we have a GDPR compliant subnet?
The GDPR subnet resolves the issue of residency. I am curious if there is a confidentiality agreement as well.
Difficult questions that I didn’t want to raise.
The European subnet helps address data residency and jurisdiction, but that alone does not make a system GDPR compliant.
GDPR in my understanding is primarily about who acts as the data controller and how personal data is processed, not just where it is stored alone.
Regarding confidentiality: on traditional cloud platforms, this is typically covered by data processing agreements with the provider. On the Internet Computer, there is no single contractual counterparty like AWS.
Instead, confidentiality must be ensured by architecture, through encryption where needed, strict access control, and data minimization.
So the responsibility remains with the application provider as the data controller, not with the network itself.
In our case, we try to avoid or anonymize personal data wherever possible.
After a little more research (this is not legal advice and DYOR) The EU subnet is not GDPR compliant for personal data etc. But with the correct setup Cloud Engines can be (as can Utopia). With a Cloud Engine the consortium providing the Cloud Engine can sign the DPA. Not sure if @dominicwilliams agrees with that 
Thanks for the input. Could you clarify whether this is based on a specific legal interpretation or general concerns?
Our view is that the European Subnet is not “GDPR compliant by default,” but enables GDPR-aligned architectures, depending on implementation and governance. Would be great to understand your perspective in more detail.
But, from my perspective, a general statement that the European Subnet is “not GDPR compliant” for personal data is too broad.
There are multiple architectural and operational approaches to address GDPR requirements and the regulation itself defines how compliance can be achieved depending on the setup and roles involved.
In that sense, it is less about whether the infrastructure itself is compliant and more about how it is used and implemented.
The same applies to traditional Web2 providers, they are not GDPR compliant by default. You cannot simply say that a provider in Vienna is compliant out of the box.
Compliance requires a combination of technical and organizational measures, as well as application-level design decisions. This includes principles such as data minimization, purpose limitation, and enabling rights like erasure (“right to be forgotten”) if needed.
It also makes a significant difference what type of personal data is being processed, whether it is customer PII, sensitive data such as health information, or simply a name used for logging purposes.
In all cases, a case-by-case assessment is required to determine whether a system, even if operated within the EU, meets GDPR requirements.
That’s why I would be very interested in understanding the specific reasoning or sources behind your statement.
This is really just my own initial research. So its ripe for scrutiny My understanding is that for GDPR compliance any PII needs to have a DPA… which is also my understanding that the EU subnet cannot provide. But fully agree its a case by case assessment. Further to this, I think the swiss subnet can provide a DPA by the swiss consortium that “created” the swiss subnet. And I think, based on the recent interview with Pier might be the same for pakistan. (great discussion btw)
As I understand it, a Data Processing Agreement (DPA) in the context of the Internet Computer is not provided at the network level.
Instead, it would need to be established by the party controlling and operating the canister, depending on their role (e.g. controller or processor).
The Internet Computer challenges the assumption that infrastructure must always be represented by a single contractual processor. Instead, it introduces a model where responsibility shifts more strongly to the application layer, while the infrastructure behaves more like a neutral execution fabric.
From that perspective, the discussion is less about the infrastructure being compliant in isolation, and more about how responsibilities are defined and implemented at the application and organizational level.
Hello @rbole ,
Just FYI, the current ICP “European” subnet isn’t EU-only - it includes non-EU/EEA European countries (notably Switzerland). The NNS approved proposal 139950 earlier this year to convert it into a true EU subnet that runs exclusively on nodes located within the EU/EEA.
The blocker is node diversity: the network doesn’t currently have enough independent node providers, data centers, and DC owners in the EU to support a full 13-node subnet. The transition, therefore, depends on ICP’s migration to TEE-enabled subnets, which reduces the required subnet size to 7 nodes. We plan to make the switch once TEE functionality is production-ready, with a target of Q3 this year.
Once live, the subnet will be reconfigured to use only EU/EEA nodes and renamed to ‘EU/EEA’, which should provide greater clarity and simplify your GDPR Chapter V analysis prior to deployment.
Thank you for joining the discussion, this is very helpful and exactly the clarification I was looking for.