EU data residency

Every container, every deploy

The compute a deployed server runs on, the proxy that routes to it, and the storage that holds its logs are all EU-based. There isn't a separate "EU tier" a workspace opts into - it's the same per-project container and network every deploy gets, run this way by default, on every plan.

Named plainly: the platform - API, database, job queue, identity service, and reverse proxy - and every container it deploys run on infrastructure operated by OVH Groupe SAS, a company incorporated and headquartered in France. PostgreSQL and Redis run self-hosted on that same infrastructure rather than as separate managed databases from a third vendor, which is one fewer party in the chain, not one more. Persisted logs, nightly database backups, and uploaded project archives sit in OVH Object Storage, also in France.

Controller for the account, processor for what you deploy

foro.sh is operated by DJH Tech, a sole proprietorship registered in the Netherlands - not a subsidiary of a larger group, and not a US company anywhere in its structure. That matters for more than the provider table below: it is also the entity whose GDPR role changes depending on which data you mean.

For account data - your identity, email, encrypted repository tokens, and billing records, where they exist - foro.sh is the controller, processing it under performance of the contract with you (Art. 6(1)(b) GDPR) and a legitimate interest in keeping accounts secure (Art. 6(1)(f)). For the content you deploy and whatever your own MCP server does with data at runtime - including the logs and metrics that server produces - foro.sh acts as processor, and you, or your organisation, remain the controller. A data processing agreement covering that relationship is available on request for paid plans. The full breakdown, category by category, is the privacy policy's job; this page states the split, not the whole document.

The non-EU touchpoints, named

"Fully European" describes the request path and the storage layer, not a claim that literally nothing ever crosses a border. It doesn't, for the paths that matter most - but a short list of narrower, named paths can, and hiding that list would make the rest of this page less credible, not more.

Every other subprocessor in the platform - Codeberg (Germany), WeSender (Netherlands) for account email, Mollie (Netherlands) for billing, UptimeRobot (Czech Republic) and Healthchecks.io (Latvia) for external monitoring - is itself EU-based. The complete, currently-maintained list lives on the privacy policy, which is the page we update first if any of this changes.

How this compares to a typical setup

"EU-hosted" means different things depending on what it's actually describing. Picking an EU region from a US-parented cloud provider satisfies a residency checkbox; it doesn't change which legal system can compel that provider to produce data. The distinction that actually matters for a security review is jurisdiction over the company, not just geography of the disk.

Why it matters for a team

For a server that touches real customer or company data, where the platform actually runs is usually one of the first questions a security review asks. Here that question has a short answer: nothing between a caller and the container leaves the EU, so the third-country transfer rules in Chapter V of the GDPR never come into play for the request path. What your own server chooses to call is still yours to account for, and the table above is the starting point for scoping that. Jurisdiction is one half of a security review; the other is what's enforced on the container itself, covered on the security specifications page.

None of this is a substitute for reading the actual policy. It's the pillar page for the topic - the privacy policy is the binding document, with the full subprocessor list and retention ladder; this page exists so the shape of the answer doesn't require reading it first.