IT Architecture Overview
Document Version: 1.2
Last Updated: August 2026
Audience: IT decision-makers, security officers, compliance teams
Executive Summary
ZeitMind is a Platform-as-a-Service (PaaS) data analytics solution with embedded field data engineers. We provide secure, cloud-hosted infrastructure for data transformation, AI-powered analysis, and visualization - while maintaining strict data sovereignty and security controls.
Key Infrastructure Facts:
- Hosting: Azure Cloud (Germany West Central region) - all data stays in Germany
- Data Residency: 100% Germany - Azure Germany West Central + Supabase Frankfurt; no data leaves the EU
- Architecture: Multi-tenant with project-level database isolation
- Connectivity: Outbound-only connector, or site-to-site VPN, for connected data sources
- AI Models: OpenAI, Anthropic, Mistral - any LLM configurable; EU-hosted options available
- Compliance: GDPR compliant, EU AI Act compliant, SOC 2 controls in place (audit planned)
- Deployment Options: Managed PaaS (standard) · Full on-premise on request
System Architecture
Infrastructure & Hosting
Cloud Provider
Microsoft Azure - Germany West Central region
Compute:
- Azure Virtual Machines (scalable B-series and D-series)
- Ubuntu 24.04 LTS
- HTTPS/TLS 1.3 via automated Let's Encrypt certificates
Network:
- Public endpoints with Azure firewall (ports 80, 443 only)
- Private network access via VPN for data source connectivity
Data Residency
All customer data stored within Germany:
- Application data: Supabase (Frankfurt)
- Customer data: PostgreSQL cluster (Azure Germany West Central)
Data sovereignty: No data leaves EU data centers.
Data Architecture
Two-Tier Data Storage
ZeitMind separates application data from customer data to ensure security, compliance, and scalability.
1. Application Data Store (Supabase - AWS Frankfurt)
Purpose: Platform operations, authentication, audit trails
Contains:
- User accounts and authentication tokens
- Project metadata (names, owners, permissions)
- System logs (request logs, error logs, audit logs)
- Application configuration
- Analyses, prompts, generated insights
Technology: Supabase PostgreSQL with Row-Level Security (RLS)
Access: Authenticated backend services only
2. Customer Data Store (PostgreSQL Cluster - Azure)
Purpose: Actual customer business data
Architecture:
- Each project gets a dedicated database with unique auto-generated credentials
- No shared connections between projects
Contains:
- User-uploaded tables (CSV, Excel imports)
- Transformed/derived tables
- Query results and cached analyses
- Data synced from connected source systems via remote tables
Technology: PostgreSQL 17 with encrypted connections
Access: Backend services with project-scoped credentials
Data Flows
1. User Upload Flow
Security notes:
- Files processed in-memory (no persistent storage of raw uploads)
- TLS 1.3 for all frontend-backend communication
- Project-scoped database credentials enforce isolation
2. AI-Powered Query Flow
Key points:
- AI models (OpenAI, Anthropic, Mistral) never receive full customer datasets
- Only schema metadata and minimal data previews sent to LLM (never full datasets)
- Query execution isolated to customer's project database
3. Connected Data Source Flow
For customers connecting on-premise or cloud data sources to their project:
Remote Tables:
Each connected source is synced into the project database by a dedicated driver: the driver reads from the source and writes the rows into PostgreSQL in Germany. User queries then run against that copy, so analysis does not depend on source-system load or availability. Tables refresh on a schedule or on demand, with incremental sync for large or continuously updated sources.
Supported Sources:
- SAP (see Connecting SAP), Oracle, Microsoft SQL Server (ODBC/JDBC)
- PostgreSQL, MySQL, MongoDB, IBM Db2 for i (AS/400), Firebird
- REST APIs and cloud storage (Shopify, S3, Azure Blob, Snowflake, etc.)
Connectivity Options
Sources that are publicly reachable are connected directly, restricted by the customer's firewall rules. For sources inside a customer network, there are two options.
Option 1: Connector (recommended)
A single Docker container the customer's IT runs anywhere in their network. It purely forwards connections - no ZeitMind driver code runs on it. Drivers run in ZeitMind's own infrastructure, each sync in its own sandboxed container bound to a single project: a driver can reach only its own project's connector, never another customer's, and its only route back into ZeitMind is the write path to that project's database.
- Outbound only. The connector opens no listening ports. It dials out to ZeitMind over WSS on port 443 and holds that connection open. Syncs are executed over the already-established tunnel.
- Encrypted in transit. WSS is WebSocket over TLS 1.3 on a certificate for our domain. Where the database protocol has its own TLS, traffic is encrypted twice.
- The customer controls reach. Reachability is enforced by the customer's own firewall around the container: a control they already operate, can audit, and can change or revoke without involving ZeitMind. The connector forwards only what a sync requests. If a route was not opened, the sync fails with a connection error.
- Built on chisel, an established open-source tunnel, distributed as a pinned, versioned image.
Option 2: Site-to-Site VPN
The alternative, for customers whose IT policy mandates a network-level tunnel:
- IPsec site-to-site tunnel, typically IKEv2 with PSK
- Requires coordination with the customer's network team (firewall changes, key exchange)
- Grants a network-to-network route rather than a per-source path. The connector is the narrower option where policy allows
Driver Isolation (both options):
Every sync runs in its own sandboxed container, and its sole route back into ZeitMind is the write path to the warehouse database. With a connector, all of the driver's outbound traffic is forced through that project's tunnel, so it reaches only what the customer's firewall permits and never another customer's tunnel. Without a connector, the driver is blocked from ZeitMind's own Azure VNet and VPN gateway subnet.
Security & Compliance
For the full security controls documentation — including GDPR, EU AI Act, penetration testing, and organizational measures — see Technical and Organizational Measures.
Authentication & Authorization
User Authentication:
- Supabase Auth with bcrypt password hashing
- JWT tokens (short-lived, auto-refreshed)
- Multi-factor authentication (MFA) available
- SAML 2.0 Single Sign-On (SSO) for enterprise customers — supports Google Workspace, Microsoft Entra ID, Okta, and other SAML-compliant identity providers
Project-Level Access Control:
- Roles (Viewer, Proposer, Editor, Manager) granted to members and groups on the project, folders or single resources, inherited down the folder tree
- Enforced in the database as well as the application: every member queries with their own PostgreSQL role
- Row-level security (RLS) filters which rows a member sees, driven by member attributes and groups
- Database-level isolation (separate credentials per project)
For the full role and permission model, see Roles and Permissions.
Network Security
Public Interface:
- HTTPS enforced (TLS 1.3)
- Let's Encrypt certificates (auto-renewed)
- Azure firewall: only ports 80, 443 exposed
- No public SSH or database ports; administration and deployments run over the private Tailscale network
Backend Communication:
- Encrypted PostgreSQL connections (SSL required)
- Supabase API keys rotated regularly
- VPN tunnels for source system connectivity
Data Encryption
At Rest:
- Azure disk encryption (AES-256)
- PostgreSQL tablespace encryption available
- Secrets managed via 1Password CLI (no hardcoded credentials)
In Transit:
- TLS 1.3 for all web traffic
- SSL for database connections
- VPN encryption for live data sources
Secrets Management
Production Environment:
- All API keys, database passwords stored in 1Password
- Environment variables loaded at runtime via
op run - No plaintext secrets in code or configuration files
Audit & Compliance
Logging:
- All API requests logged (Supabase request logs)
- Database query logs (PostgreSQL audit extension)
- User actions tracked (audit trail in application data)
- Error logs and system events
Data Retention:
- Configurable per project
- GDPR-compliant data deletion on request
Data Protection Agreement:
- All customers receive a Data Protection Agreement (DPA) that guarantees:
- GDPR compliance (data residency, encryption, access controls, right to deletion)
- EU AI Act compliance (transparency, risk management, human oversight of AI systems)
- Processor-controller relationship clearly defined
- Sub-processor disclosure and approval process
Compliance Readiness:
- GDPR (data residency, right to deletion, data portability)
- EU AI Act (transparency, human oversight, audit logging; controls aligned with high-risk system requirements)
- SOC 2 Type II (controls in place, audit planned)
- ISO 27001 preparation (information security management)
Monitoring & Operations
Infrastructure Monitoring
Service Availability:
- Uptime Robot monitors all public endpoints (mind.zeit-ai.com) as well as PostgreSQL replication, WAL archiving, and backups
- Per-service uptime is published on the public status page
- Alerts on downtime, slow response times, SSL expiry
Database Health:
- PostgreSQL logs (slow queries, errors, connections)
- Supabase logs (audit logs, error logs, request logs)
Application Monitoring:
- Frontend event logs (user interactions, errors)
- Backend API logs (request/response times, failures)
- Prompt logs (AI query history, token usage)
Log Aggregation
All logs funneled into internal ZeitMind instance for centralized analysis:
- Structured logging (JSON format)
- Full-text search for debugging
- Anomaly detection (unusual query patterns)
Incident Response
Alerting:
- Uptime Robot → Pro-active Slack + email on service outage
- Critical errors → On-call engineer paged
- Security events → Immediate escalation
Response Time:
| Priority | Response time | Example scenario |
|---|---|---|
| P0 (critical) — critical malfunction | < 30 minutes | Errors that preclude or make it impossible to use the platform. E.g, unreachable, security breach |
| P1 (high) — serious malfunction | < 2 hours | Errors that significantly impede or severely restrict the use of the software in essential parts. E.g., major feature broken, severe performance degradation |
| P2 (medium) — moderate malfunction | < 4 hours | Errors that restrict the functionality of the platform only in partial areas so that use is still possible E.g, real-time functions do not ensure real-time transmission |
Backup & Recovery:
- Daily automated backups of all databases
- Point-in-time recovery (PITR) for PostgreSQL
- Recovery Time Objective (RTO): 2 hours
- Recovery Point Objective (RPO): 24 hours
Integration Points
AI Model Providers
ZeitMind is model-agnostic — the LLM provider can be configured per deployment. For customers who require AI model calls to stay within the EU, EU-hosted options are available.
Supported Models:
- OpenAI (GPT models)
- Anthropic (Claude models, via the Anthropic API or EU-hosted on Google Vertex AI)
- Mistral AI (EU-headquartered, EU-hosted)
- Custom or self-hosted model endpoints on request
EU-Hosted Options: For customers requiring that AI model calls do not leave the EU, ZeitMind can serve Claude models from Google Vertex AI's EU multi-region endpoint. Further options are Mistral AI, Azure OpenAI EU regions, or self-hosted models within the Azure Germany region.
Data Handling:
- Only schema metadata and minimal data previews sent to AI models (never full datasets)
- AI models do not have access to your complete data
- Query results processed exclusively within Zeit AI infrastructure in Germany
Model Training Policies: All supported AI providers are configured to prevent customer data from being used for model training. For a detailed assessment of each provider's contractual basis and configuration, see LLM Training Policies.
Email Notifications
Provider: Resend (GDPR-compliant)
Use Cases:
- Job completion alerts
- Error notifications
- Weekly reports (optional)
Data Source Connectivity
Supported Protocols:
- ODBC/JDBC for legacy systems
- Native PostgreSQL, MSSQL, Db2 and Firebird clients
- REST APIs (OAuth 2.0, API keys)
- Flat file import (CSV, Excel, JSON)
Network Options:
- Connector (outbound-only Docker container in the customer network)
- Site-to-Site VPN (IPsec) for on-premise systems
- Direct connection (if source system has public endpoint + firewall rules)
System Requirements (Customer Side)
For Web Access
End Users:
- Modern web browser (Chrome, Firefox, Safari, Edge)
- No client-side installation required
- JavaScript enabled
For Connected Data Sources
If connecting on-premise systems:
Option 1: Connector (recommended)
- Any host in the customer network that can run Docker
- Outbound HTTPS (TCP 443) to ZeitMind — no inbound rules, no public IP
- Firewall rule permitting the container to reach the source systems
Option 2: Site-to-Site VPN
- VPN-capable firewall or router (Cisco, Fortinet, pfSense, etc.)
- Static public IP or dynamic DNS
- Port forwarding: UDP 500, 4500 (IPsec)
Option 3: Direct Database Access
- Firewall rule to allow Zeit AI backend IPs
- Database user with read-only permissions recommended
- SSL/TLS connection required
Performance & Scalability
Current Capacity
- Concurrent Users: 100+
- Data Processing: Up to 1M rows per table (larger datasets supported via partitioning)
- API Response Time: < 200ms (P95)
- AI Query Latency: 5-10s (depends on LLM provider)
Scalability Path
As your team grows, Zeit AI infrastructure scales:
50-500 users:
- Add application servers (load-balanced)
- PostgreSQL read replicas for query offloading
500+ users (Enterprise):
- Kubernetes cluster for auto-scaling
- High-availability PostgreSQL (primary + replicas)
- Redis caching layer
- Dedicated infrastructure available
FAQ for IT Teams
Q: Where is our data stored?
A: All customer data resides in Azure Germany West Central (application metadata in Supabase Frankfurt). Data does not leave the EU.
Q: Can we use our own database?
A: Yes. Zeit AI can connect to your existing PostgreSQL, MySQL, SQL Server, or Oracle databases via VPN.
Q: How do you handle secrets (API keys, passwords)?
A: All secrets stored in 1Password (encrypted vault). Production environment uses op run to load secrets at runtime. No plaintext credentials in code.
Q: What happens if Zeit AI goes down?
A: We have daily backups (24-hour RPO) and can restore service within 2 hours (RTO). Uptime Robot monitors all endpoints 24/7 with alerting.
Q: Can we audit access logs?
A: Yes. All API requests, database queries, and user actions logged. Logs available via internal Zeit AI dashboard or exported for compliance audits.
Q: Is Zeit AI SOC 2 compliant?
A: We are SOC 2 ready with controls in place. Formal audit planned.
Q: Can we keep our data in our own infrastructure?
A: Yes, via full on-premise deployment — ZeitMind can be deployed entirely within your own infrastructure. Available for enterprise clients on request; requires an Enterprise license. Contact us to discuss your requirements.
In the standard managed setup, data from connected sources is synced into the PostgreSQL cluster in Azure Germany West Central and queried there. The connector and VPN options govern how we reach your systems, not where the data is stored.
Q: Do you support Single Sign-On (SSO)?
A: Yes. ZeitMind supports SAML 2.0 Single Sign-On for enterprise customers. You can integrate with Google Workspace, Microsoft Entra ID (formerly Azure AD), Okta, OneLogin, or any SAML 2.0-compliant identity provider. This enables centralized user management, simplified onboarding/offboarding, and enforcement of your organization's authentication policies. Contact support@zeit-ai.com to set up SSO for your organization.
Contact & Support
For technical inquiries, security questions, or partnership opportunities:
This document is maintained by the Zeit AI engineering team and updated quarterly. For the latest version, visit our documentation portal or contact your account manager.
For our formal security controls documentation (suitable for vendor security reviews), see Technical and Organizational Measures.