Storm Internet — Posture-Compliant Sovereign Warehouse

A UK-headquartered, ISO 27001 managed-Postgres + managed-VM target that moves the warehouse off the operator's desktop without handing the encryption key to a US-parent backend.

UK-headquartered
ISO 27001 + ISO 9001
Managed (no contractor-DBA)
Confirm PG version first
Base44 app layer still US-parent
Fully on-prem sovereign posture — now proven end-to-end
With the local LLM benchmark passing, every high-value data asset and every inference call stays inside the operator's own estate. The only external dependencies are MapFlow orchestration and the final Salesforce load.
Source DBs (local) Local Proxy (RAM decrypt) Local Ollama LLM Local / corporate Postgres Salesforce REST API (final load)

Source databases

SQL Server / Oracle / MS Access on the council estate, reached only via the Local Proxy on the operator's Windows machine. No inbound ports, no internet-facing API.

LLM inference

Ollama (Llama-3 / Phi-3 / Mistral / Qwen) bound to 127.0.0.1:11434, reached only via the proxy's /llm-invoke route. Benchmark-verified working. Zero internet egress during inference.

Postgres warehouse

Can run locally on the operator's machine or on a VM inside the corporate network (self-hosted Postgres / standalone Postgres). Point a MapFlow DBConnection at the corporate-network host. No cloud provider in the warehouse path.

MapFlow orchestration (external)

The Base44 backend — the platform — runs in the cloud and orchestrates jobs, mappings, auth, and scheduled tasks. It holds metadata only: project config, mapping definitions, job records, audit logs. It never holds the AES key or plaintext citizen data under the default local_proxy mode.

The one accepted external egress: the final load of mapped data into Salesforce, which uses the Salesforce REST API. Salesforce is the client's contracted destination — the hand-off is the documented, accepted boundary, not a residency gap in MapFlow's processing.

Source DBs local
LLM local (proven)
Postgres local / corporate
Only orchestration external
Salesforce REST = accepted hand-off

Net: the AES-256-GCM key, the plaintext citizen data, and the LLM prompts all stay inside the operator's estate. A US CLOUD Act production order against the Base44 platform returns ciphertext and non-PII metadata only — never plaintext, never LLM transcripts. Obtaining plaintext becomes a UK lawful-access matter against the operator, not a retrieval from a US provider.

The architecture in one paragraph
Two Storm-managed UK resources; Base44 orchestration unchanged; encryption mode stays local_proxy.

Resource 1 — Managed Postgres (the warehouse). A Storm-managed PostgreSQL instance in their UK data centre, GA version (15 or 16). Holds the citizen-data tables that today live in the operator's local DB. storage_mode points a MapFlow DBConnection at this instance instead of localhost.

Resource 2 — Managed VM (the proxy host). A Storm-managed UK VM running the existingpostgres-proxy.py process. The AES-256-GCM key lives in this VM's key vault (not in DPAPI on the operator's desktop, and never on the Base44 backend). All encrypt/decrypt for warehouse reads/writes happens here.

Unchanged — Base44 backend. Still US-parent-owned, still orchestrates jobs, mappings, and syncs. Plaintext still transits backend memory transiently during a sync — same exposure as today'slocal_proxy mode. The backend never holds the key, so it cannot decrypt the warehouse at rest.

The three-way comparison
Why "Storm + local_proxy" is the recommended posture and "Storm + backend encryption" is rejected.
DimensionA. Today (local-only)B. Storm + local_proxy ✅C. Storm + backend ❌
Warehouse at restOperator's local DB (UK estate)Storm UK managed PostgresStorm UK managed Postgres
AES key locationOperator Windows Vault (DPAPI)Storm UK VM key vaultBase44 backend (US parent) ❌
US CLOUD Act reachNone on key; transient sync plaintext onlyNone on key; transient sync plaintext onlyKey + entire historical warehouse ❌
Operator PC overnightMust be on at 01:00Not required ✅Not required ✅
ThroughputOperator desktop CPU (capped)Storm VM (cloud-elastic) ✅Backend (cloud-elastic) ✅
Contractor burdenBabysit local proxy + overnight taskStorm 24/7 pod manages both ✅Minimal ✅
InfoSec verdictPass (current posture)Pass ✅Fail — key on US parent ❌

Option C's throughput and convenience wins are real, but they come at the cost of the single control that the entire posture exists to enforce: keeping the AES key off the US-parent backend. A US CLOUD Act order against Base44 in option C returns the key — which unlocks the entire Storm warehouse retroactively, not just a sync window. The at-rest residency win of Storm is cancelled the moment you hand the key to a US parent. Option B keeps the key on the UK VM and is the only scalable option that InfoSec can pass.

What moves and what stays

Moves to Storm (warehouse layer):

Citizen data tables at rest; the proxy process and its key; the overnight refresh execution location. The operator's PC is freed from both the data store and the always-on proxy duty.

Stays on Base44 (app layer — unchanged exposure):

Project config, mapping definitions, job records, audit logs, and orchestration logic. Plaintext still transits backend memory transiently during a sync — identical to today's local_proxy mode. This is not a regression; it is the accepted, documented app-layer exposure that already exists.

Stays local-first (the key):

The AES-256-GCM key never moves to the Base44 backend. It moves from the operator's Windows Vault to the Storm VM's key vault — both UK, neither US-parent. encryption_mode stays local_proxy. This is the non-negotiable control.

The one thing to confirm before committing

Ask Storm directly: "Which PostgreSQL major versions do you support on managed plans today, and is the data held in your UK data centre for the lifetime of the contract?"

You need a GA version (15 or 16) — not a beta, not a deprecating version (this is exactly what blocked Civo). And you need written confirmation the data does not get replicated or backed up outside the UK. If both answers are yes, this is your viable sovereign warehouse.

The residual exposure — stated honestly
Storm relocates the warehouse, not the whole stack. Two exposures remain and are accepted.

Base44 app layer is still US-parent-owned.

A US CLOUD Act order against Base44 still reaches app metadata, mapping configs, job records, and transient sync plaintext in backend memory. Storm does not change this — it only relocates the warehouse and the key. The app-layer exposure is the same as today's posture and is accepted because the high-value asset (the historical citizen-data warehouse) is now outside US-parent reach.

Salesforce is still the accepted final step.

Loading mapped data into Salesforce remains the one CLOUD Act exposure MapFlow does not and cannot eliminate — it is the client's contracted destination. Storm changes nothing about the Salesforce boundary; it only improves the pre-Salesforce residency. See the End-User Impact register for that accepted exposure.

Net posture: the operator's PC stops being the security perimeter and the overnight bottleneck; the warehouse and the key both live on UK-sovereign, ISO 27001 managed infrastructure; the Base44 backend keeps its current (accepted) app-layer exposure but never holds the key; the Salesforce hand-off stays the one accepted CLOUD Act surface. Single-contractor burden drops to "raise a ticket with Storm's 24/7 pod." InfoSec sees UK-at-rest + key-off-US-parent + ISO 27001 — the posture that was missing on Civo.