GDPR hosting you can drop into the questionnaire

Privacy rarely shows up in the sprint. It arrives as a customer spreadsheet. Then it matters whether repos, deployments and the contract sit in the EU — not whether someone ticked Frankfurt.

  • Platform and managed servers in Germany / the EU
  • DPA and TOMs as documents in the product, not a PDF hunt over email

A tick-box or a document

As today

  • Every vendor separately: DPA, region, subprocessors.

One setup, evidencable

  • Repos, deployments, managed servers in the EU, contract in the product.
The audit log makes changes traceable, including for audits. The audit log makes changes traceable, including for audits.
The audit log makes changes traceable, including for audits.

Privacy questions rarely appear in the sprint. They appear in the customer’s questionnaire. Then it matters whether location, contract and access live in one system — not whether an EU region is a dropdown in a US product.

Handling data protection yourself versus working with the platform

This shows how each task lands on your desk without a platform and how much of it the Application Platform covers. It is not a legal assessment of your situation.

Task With the Application Platform Set up manually
Deciding where processing happens Fully covered: Platform operated in Germany and the EU, servers freely selectable Not offered: Check every service individually, with defaults often outside the EU
Data processing agreement Fully covered: Agreement in place for platform operations, personalised documents generated in the platform Not offered: Request, review and file one for every single provider
Documenting technical and organisational measures Fully covered: A description of the measures for platform operations is available as a document Not offered: Write it yourself and revise it after every change
Running on your own servers Fully covered: Your own server over SSH or a managed server, with access staying with you either way Partly covered: Possible, but Docker, proxy, SSL, firewall and backups are on you
Managing access inside the team Fully covered: Roles, organisations and project memberships managed in one place Not offered: Separate user management per tool, with permissions drifting apart
Evidencing changes Fully covered: Audit log for relevant changes, deployments as configuration in the Git history Partly covered: Scattered logs, rarely a shared view across project and infrastructure
Storing credentials and secrets Fully covered: Credentials held centrally in the project with permissions per role Partly covered: Spread across CI variables, password managers and local files
Explaining data flows to customers Fully covered: Sub-processors and processing locations for platform operations are documented Not offered: Research and assemble the picture for each service in use
Deletion and exit Fully covered: Repositories, deployment configuration and servers belong to you, with full code ownership Partly covered: Depends on the export options each provider happens to offer
Legal assessment of your case Partly covered: Not part of the service; the platform supplies groundwork and evidence Partly covered: Also a job for your company or your legal advisers

Green means fully covered, amber partly, grey not offered. This describes the scope of the platform and does not constitute legal advice.

As of 9 September 2026. This comparison describes typical workflows and can differ from project to project. Logos are trademarks of their owners and are used only to identify the product.

What this does not replace

  • Not legal advice The platform supplies operations and documents. Judging your case stays with you and your counsel.

Pricing model

No extra fee “for GDPR”. You pay platform and servers; the contracts live in the product.

  • Anna Weber

    Organization, members & billing

    Administrator
  • Max Schneider

    Code, Git & deployments

    Developer
  • Tom Richter

    QA on dev & staging

    Tester
  • Paul Klein

    Customer app & feedback

    Customer
Access rights per person and project instead of shared logins.

How to approach this in a project

This order works well when data protection should not be an afterthought.

  1. Decide where things run

    Choose whether your application runs on a managed server or on your own machine. Both can be connected to the same project.

  2. Generate the contracts

    Download the data processing agreement and the description of technical and organisational measures from the platform and add them to your documentation.

  3. Sort out access

    Assign roles inside the organisation, keep project credentials in one place and remove personal logins from scripts and local files.

  4. Document the data flows

    Record which optional services you enable in the project, such as your own SMTP or Sentry. Those processings are yours to assess.

  5. Close the review

    Have the package checked by your data protection adviser. The platform supplies the technical and contractual basis; the judgement stays with you.

Frequently asked questions

Does running on the Application Platform make my project GDPR compliant?

No, and no provider can honestly promise that. The platform supplies the groundwork: EU operations, a data processing agreement, documented sub-processors and an audit log. Whether your processing is lawful stays your own assessment, not legal advice.

Where exactly is my data processed?

The primary processing location is Germany and the EU: control plane, GitLab, managed servers and backups. Any service with a transfer outside the EU, such as payment processing, is named in the compliance overview and covered contractually.

Do I get a data processing agreement?

Yes. Platform operations run under a DPA in line with Article 28 GDPR. Inside the platform, under compliance and contracts, you generate personalised documents, including the agreement and the measures, ready to hand to procurement or security.

Can I run the application on my own hardware?

Yes. Instead of a managed server you can attach your own machine over SSH. The platform installs Docker, reverse proxy, SSL, firewall and backups on it and wires it into the pipeline. Operating that machine remains your responsibility.

How do I show a customer what is running in production?

Environments and deployments live as configuration in the Git history, versioned and tied to a commit. The audit log additionally records changes to projects and permissions, so you can evidence rollouts and access changes.

Check the groundwork yourself

Register for free, create a project and look at the contracts, the role model and the audit log inside the platform.