A practical checklist for evaluating app hosting on GDPR grounds: jurisdiction, sub-processors, retention, backups and exit.
Updated 24 September 2026
"GDPR-compliant" is not a checkbox a hosting platform can hand you; it's a set of specific, checkable facts about who processes your data, where, under whose law, and what happens when something goes wrong. This applies to every part of an app, including a static front-end sitting in a CDN cache: a cached HTML page can still carry personal data (a signed-in user's name rendered into a prerendered page, for instance), so "it's just static files" is not an automatic pass. This is the checklist to run against any platform, not a page arguing the answer is always the same vendor.
Ask for the company's registered seat and governing law, not just the region name in a dropdown. A US company processing data in an EU data center is still subject to US law reaching its parent, including the CLOUD Act; a company incorporated in the EU with no foreign parent removes that path entirely. Sarpius publishes its Chamber of Commerce number and seat (KVK 73239038, Apeldoorn, Netherlands) on its data residency page, plus the fact that it owns the hardware it runs on rather than renting capacity inside a hyperscaler's region.
Check whether "EU region" covers the whole stack or just one service: does the database live in the same region as the app? Does object storage? Does the edge/CDN layer that caches a static front-end? A platform that serves static assets through a third-party CDN (Cloudflare, in Sarpius's case, by default) is bringing that CDN operator into the picture as a sub-processor even for content that never touches a database, which is exactly why the sub-processor list matters. Is there a stated policy for where future regions will be added? A platform vague about this on its own docs page is one you have to keep re-checking.
A short, named list beats a vague "we use industry-standard providers" line. Ask what each sub-processor does, where it's based, and whether it's replaceable. Watch specifically for analytics and error-tracking tools: many platforms silently route this to a US vendor. Self-hosting your own observability stack removes it from the list entirely, a smaller attack surface for a DPO to review, not just a smaller document. Sarpius names exactly two, Cloudflare Inc. (DNS/CDN/DDoS, global network) and Mollie B.V. (payments, Netherlands), and states its error tracking (Sentry) and analytics (Matomo) are self-hosted rather than sent to a third party. If Cloudflare as a sub-processor is a hard blocker for a given domain, that's a real path to ask about, not just a checkbox: Sarpius has a paid, per-domain "Privacy route" that removes Cloudflare from the request path for that specific domain, at a premium of EUR 4.99/month on top of the EUR 1.99/month custom-domain fee. Enabling it means the domain's DNS points directly at Sarpius's own edge instead of Cloudflare, and Cloudflare's CDN, WAF and DDoS protection no longer cover that domain's traffic, it is a genuine trade of Cloudflare's protection for Cloudflare's absence from the data path.
Worth reading literally. Some DPAs state they apply "to customers on Enterprise and Pro plans" only, Vercel's is one example. A free-plan project processing personal data with no DPA coverage has no contractual GDPR backing. Ask: does the DPA apply to every plan, from free up?
Look for actual numbers: how long is data kept after account closure, and how long are security/access logs kept? Vague answers ("as needed") are a yellow flag; a stated range with named exceptions (legal or tax retention) is what a real policy looks like. Sarpius: active accounts kept as long as needed, closed accounts at least 6 months then deletable except for legal/tax retention, security logs up to 12 months.
Ask explicitly whether the platform uses third-party advertising cookies, sells or rents data, or uses profiling/data-brokerage services as sub-processors: a platform should answer this in one sentence, not a paragraph of qualifiers. Sarpius states it does not sell, rent or trade personal data, uses no third-party analytics or advertising cookies, and sets only first-party cookies for authentication, security and language.
This is the item most platforms fudge. "We take backups" usually means internal, operator-run backups for the platform's own disaster recovery, not a restore point a customer controls. Ask: can you start a restore yourself? Is there point-in-time recovery? What's covered, per resource type? A platform honest about a gap here is more useful than one implying coverage it hasn't built. Sarpius states plainly that self-service restore and point-in-time recovery don't exist yet, that a restore runs through support today, and that this is what the platform is building right now, not a someday item.
The practical test: is the source code in your own git repository, under your own account, on a host you chose? Are databases a standard engine (Postgres, MySQL/MariaDB) reachable with any standard client, so a pg_dump just works? Is object storage S3-compatible, reachable with an existing S3 client and your own keys, no proprietary export tool, including a static front-end's built assets, which live in that same object storage? If all three are yes, data can leave without the vendor's cooperation.
Beyond individual tool access, does the platform give you an automated, complete archive of everything it holds? On Sarpius, the owner can download a complete Project migration bundle directly from the Project workspace behind a console login, plus your two-factor code when 2FA is on. The bundle contains, per component, the built front-end/static output and the live container files (including uploaded media and application state); a SQL dump per database; bucket objects and bucket manifests; a manifest.json file recording the git repository URL and exact commit SHA per component, a sha256 checksum per file, and an explicit list of anything not included and why (such as an unreachable container or oversized bucket); and decrypted environment variables added as secrets.env only at the moment of download, never stored in the resting bundle artifact in storage. Download authorization runs via a short-lived, single-use token valid for 5 minutes, restricted to a console session behind 2FA. Bundles remain downloadable for 24 hours, and can be requested once every 24 hours.
No. Compliance depends on the processing agreement, sub-processors, retention and your own use of the data, not only on server location. A US company can host in an EU region and still be reachable under US law for the data it controls.
A third party a platform uses to help process data, e.g. a CDN or payment processor. A short, named list is stronger evidence than a general compliance statement.
Depends on the vendor. Check the DPA's own scope language; some explicitly exclude free/Hobby tiers.
Whether a restore can be started by the customer, whether point-in-time recovery exists, and what's covered per resource type. A vendor stating a gap plainly is safer than one implying more than it has built.
Yes: it removes those tools from the sub-processor list and the third-country transfer question, rather than arguing why sending that data to a US vendor is acceptable under EU transfer rules.
Sarpius provides two layers of exit. First, direct access: your git repository stays on your own git host, databases are standard PostgreSQL, Redis and MariaDB accessible with standard clients, and object storage is S3-compatible with your own credentials. Second, an automated Project migration bundle downloaded from the Project workspace behind a console login, plus your two-factor code when 2FA is on. It packages container files, static build outputs, database SQL dumps, bucket objects, and a manifest with git commit SHAs and sha256 checksums per file. Decrypted environment variables are supplied as secrets.env at download time via a 5-minute single-use token and are never stored in the saved archive. Bundles are kept for 24 hours, requestable once per 24 hours.
Sarpius publishes its legal seat, its two named sub-processors, its retention periods and its DPA on one page, and is explicit that it runs from a single Netherlands location today, with self-service database restore not yet available. Run the checklist above against any vendor, including this one, rather than taking a badge at face value.