Cloud Infrastructure
Seal is a cloud-native SaaS platform hosted entirely on Google Cloud Platform (GCP). This page provides an overview of our tech stack, infrastructure architecture, and security controls.
Tech Stack
| Layer | Technology |
|---|
| Cloud Provider | Google Cloud Platform (GCP) |
| Compute | Cloud Run (serverless containers) |
| Database | AlloyDB (PostgreSQL-compatible) |
| File Storage | Firebase Storage (Google Cloud Storage) |
| Language | TypeScript (full stack) |
| Frontend | React |
| Backend | Node.js |
Architecture Diagram
The following diagram illustrates how data flows through the Seal platform, highlighting the security controls at each layer.
Why VPC Matters
All internal communication between Seal services occurs within a private Virtual Private Cloud (VPC). This provides critical security benefits:
| Benefit | Explanation |
|---|
| No public internet exposure | Traffic between Cloud Run, AlloyDB, and Storage never leaves Google’s private network |
| Private IP addressing | Internal services communicate via private IPs only — databases have no public IP |
| Network-level isolation | Even if credentials were compromised, attackers cannot reach services from outside the VPC |
| Defence in depth | VPC isolation + encryption + authentication |
The VPC acts as a secure perimeter around our data layer. Combined with mTLS encryption and IAM authentication, this ensures that even internal traffic is protected against interception and unauthorised access.
Security at Each Layer
1. Client to Cloud Run (Edge)
All traffic entering the Seal platform is encrypted using TLS.
| Aspect | Details |
|---|
| Protocol | HTTPS only (HTTP connections rejected) |
| TLS Version | TLS 1.2 or higher |
| Certificate Management | Automatic via GCP-managed certificates |
| Authentication | Firebase JWT (browser) or API Key (REST API) |
API keys are hashed using SHA-512 and never stored in plaintext. Keys are shown to users only once at generation time. Permissions are scoped per system and keys can only be created by admins.
2. Cloud Run to AlloyDB (Database)
Database connections are secured using the AlloyDB Auth Proxy, which provides mutual TLS (mTLS) and IAM-based authentication.
| Aspect | Details |
|---|
| Connection Method | AlloyDB Auth Proxy (sidecar container) |
| Encryption | Mutual TLS (mTLS) |
| Authentication | GCP IAM Service Account |
| Network | Private VPC, no public IP exposure |
| SSL Enforcement | AlloyDB configured to reject non-SSL connections |
3. Cloud Run to Firebase Storage (Files)
File storage connections use Google Cloud Storage APIs with IAM authentication.
| Aspect | Details |
|---|
| Protocol | HTTPS (mandatory for GCS API) |
| Authentication | GCP IAM Service Account |
| Access Control | Firebase Security Rules + application-level checks |
Encryption
Encryption in Transit
All data in transit is encrypted:
| Connection | Encryption |
|---|
| Client → Cloud Run | TLS 1.2+ |
| Cloud Run → AlloyDB | mTLS (via Auth Proxy) |
| Cloud Run → Firebase Storage | TLS (HTTPS) |
Encryption at Rest
All data at rest is encrypted using AES-256:
| Storage | Encryption | Key Management |
|---|
| AlloyDB | AES-256 | Google-managed (automatic rotation) |
| Firebase Storage | AES-256 | Google-managed (automatic rotation) |
| Backups | AES-256 | Google-managed |
For organisations requiring additional control over encryption keys, Customer-Managed Encryption Keys (CMEK) are available through Google Cloud KMS. Contact [email protected] for more information. Network Security
VPC Isolation
Seal’s infrastructure operates within a private Virtual Private Cloud (VPC):
- No public database access — AlloyDB has no public IP address
- Private egress only — Cloud Run connects to data services via private IP ranges
- VPC Connector — Dedicated connector for secure communication between services
Data Residency
| Region | Location | Availability |
|---|
| EU (Default) | europe-west1 (Belgium) | All customers |
| US | us-central1 (Iowa) | Enterprise customers |
