Today’s Context

Today, I took a temporary break from scientific research to focus on the product development of the Kindergarten App. The core agenda: How to choose the right information security architecture for a kindergarten SaaS application under Germany’s strict data protection regulations. Below is a summary of today’s research and technical decisions.

---

1. Problem Context: Why Firebase / Supabase Cloud is Not Feasible

In the initial technical selection, Firebase and Supabase Cloud were top contenders—they offer extremely high development efficiency and out-of-the-box BaaS capabilities. However, after deep-diving into Germany’s DSGVO (Datenschutz-Grundverordnung, the local implementation of GDPR) and the specific data protection requirements for children across various federal states, I made the following judgments:

• Multi-tenant shared databases constitute “Joint Data Processing” (Auftragsverarbeitung) at a legal level. As the data processor, the developer must sign an AVV (Auftragsverarbeitungsvertrag) with every single kindergarten and bear full security responsibility for the entire dataset.
• The central question from a German Data Protection Officer (DPO) is: “As the developer/operator, do you technically have the capability to access children’s personal data?” If the answer is “yes,” the compliance costs grow exponentially.

Conclusion: Traditional centralized cloud architectures are not viable in the German education sector. Technical enforcement of data sovereignty through isolation must be implemented at the architectural level.

---

2. Architecture Solution: From Logical to Physical Isolation

The core design principle is “Distributed Self-Hosting + Physical Isolation”. The specific plan is as follows:

2.1 Containerized Instance Isolation

• Each kindergarten gets its own dedicated Docker container (or container group), running on nodes provided by German IaaS providers (e.g., Hetzner Cloud / netcup).
• Each instance deploys an independent database (current candidates are PocketBase or self-hosted Supabase). No shared storage layer exists between different tenants.

2.2 Separation of Control Plane and Data Plane

• Control Plane: Maintained by me, responsible for instance orchestration, version updates, and health checks.
• Data Plane: Enclosed within each kindergarten’s instance; the Control Plane has no read/write permissions for its content.

In simple terms: I maintain the “container shell,” but the “content inside the container” is a black box to me.

---

3. Application-Layer Encryption: E2EE Inspired by Signal Protocol

Physical isolation solves data boundary issues at the infrastructure level, but it cannot mathematically eliminate the risk of data access by operations personnel. Therefore, an Application-Layer End-to-End Encryption (E2EE) solution is introduced:

3.1 Encryption Strategy

Level	Implementation	Description
Client-Side Encryption	The client uses AES-256-GCM to encrypt sensitive fields (names, health records, photos, etc.) before uploading.	The server only stores ciphertext.
Key Derivation	Encryption keys are derived locally using PBKDF2 / Argon2 based on an “Institution Master Password” set by the kindergarten.	Keys never leave the client.
Key Management	The server does not store or relay any plaintext keys.	Even if the database is fully exported, an attacker only obtains indecipherable ciphertext.

3.2 Security Boundary

This means that even if I, as the system administrator, were physically forced to hand over all server access, I could only provide irreversible encrypted data. This technicality effectively “removes” the developer from the data processing chain, greatly simplifying the DSGVO compliance argument.

---

4. Automated Delivery: One-Click Private Cloud Deployment

Target users (kindergartens) generally lack IT operations capabilities, so the deployment process must have zero technical barriers:

1. Infrastructure as Code: Use Terraform to declaratively define computing resources, network policies, and storage volumes for each kindergarten instance.
2. CI/CD Pipeline: Based on GitHub Actions, when the kindergarten clicks “Activate” in the front-end dashboard, the backend automatically calls the German cloud provider’s API to complete instance initialization (including DNS, TLS certificate issuance, and database setup) within ~5 minutes.
3. Mass Operations: The control plane can push version updates to 100+ instances in parallel without ever touching the user data within those instances.

---

5. Competitive Advantage and Business Value

In the German EdTech market, functional differentiation is hard to sustain, but compliance architecture itself is a moat:

Stakeholder	Value Proposition
Kindergartens	Pass DPO audit in 5 minutes with minimal technical compliance overhead.
Parents	Top-tier security guarantee—data is technically invisible even to the developers.
Investors	Once the “Physical Isolation + E2EE” architecture is proven, it can be horizontally scaled to other high-privacy sectors like Telehealth or eGovernment.

---

Summary

In the realm of privacy protection, “Policy-based Trust” is always inferior to “Cryptographic Enforcement.” When your system is technically incapable of doing harm at both the physical and cryptographic levels, you have truly earned the deepest level of user trust.

Next Steps: Develop a PoC Demo for field-level encryption based on the Web Crypto API, focusing on the encryption/decryption latency and battery consumption of AES-256-GCM on mobile devices (iOS Safari / Android Chrome).