Infrastructure & Hosting
ProSurvey Apps Limited (company no. 17118570) · Trust & Security Handbook
Audience: IT managers, cloud/security reviewers, procurement. Describes where and how HousingSurvey Pro runs. Items not yet in production are marked planned / in progress; this page does not describe infrastructure the platform does not have. Tracked on our internal roadmap.
Cloud platform & region
- Provider: Google Cloud Platform / Firebase.
- Primary region: europe-west2 (London, UK) — Firestore, Cloud Functions and Cloud Storage are provisioned in-region for UK data residency.
- CDN/edge: static app + website assets served via the platform's global CDN; data operations execute in-region.
Components
| Layer | Technology | Notes |
|---|---|---|
| Management dashboard (web) | React + Vite SPA | Served as static assets |
| Mobile capture app | React + Vite via Capacitor (iOS/Android) | Offline-first; WKWebView |
| Marketing website | Astro static site | Public content |
| Database | Cloud Firestore | Multi-tenant; access governed by security rules |
| Serverless backend | Cloud Functions (Node 22) | Callable + trigger functions; no long-running servers |
| File storage | Cloud Storage | Photos + report/evidence bundles; in-region |
| Authentication | Firebase Auth / Identity Platform | Email, SSO (Entra ID), tenant username-alias logins |
| Client attestation | App Check | reCAPTCHA (web), App Attest (iOS), Play Integrity (Android) |
| Secrets | Cloud Secret Manager | Server-side only |
Architecture principles
- Serverless, no managed VMs to patch — reduces attack surface and operational burden; scaling is handled by the platform.
- Multi-tenant with database-enforced isolation — every record is organisation-scoped; Firestore security rules deny cross-tenant access independently of the UI. Covered by emulator rules tests in CI.
- Offline-first capture — the mobile app records surveys without connectivity and syncs sealed, hash-chained evidence when back online.
- Evidence at rest is immutable — finalised records are append-only and chained; see Security & data architecture.
Environments & delivery
- Environments: production; a non-production/staging project is provisioned separately (secrets injected per-environment; no shared credentials). (Full non-prod parity: in progress.)
- CI/CD: every change runs lint, unit tests with coverage floors, Firestore rules tests on the emulator, hash-canonicaliser parity checks and builds for all apps. Production deployment depends on CI plus the protected production environment. Hosting bundle-identity assertions and predeploy hooks block prod/nonprod asset mix-ups.
- Configuration: client build-time config uses per-environment values; real secrets are never shipped to clients and are injected server-side.
Resilience & recovery
- Managed durability: Firestore and Cloud Storage provide replicated, encrypted-at-rest storage within the region.
- Firestore point-in-time recovery (PITR): production has seven-day PITR plus daily 98-day backups. A limited nonprod point-in-time-read recovery drill succeeded; the production-equivalent bulk and backup restore paths remain untested.
- Cloud Storage versioning / disaster recovery: both evidence buckets have versioning, 14-day soft delete and a 30-day noncurrent-version lifecycle. Production mirrors nightly to a separate versioned Archive bucket in London. This protects object/bucket loss while preserving UK residency, but the same- region design does not cover a whole-London-region outage.
- Availability monitoring & SLOs: platform monitoring is in place; a published SLO/uptime commitment is planned.
Networking & access
- All client↔backend traffic is over TLS.
- No inbound network access to a database or server is exposed; clients reach data only through authenticated, rules-checked SDK calls and callable functions.
- Administrative access to the cloud project is restricted to the operating team under least-privilege IAM. (Access review cadence: planned.)
Sub-processors
The cloud platform (Google Cloud/Firebase) is the primary subprocessor. Any email or AI providers are enabled by the customer with their own keys, so that processing occurs under the customer's own agreements. The maintained Subprocessor Register documents each provider, purpose and transfer/residency position.
Status: living document, updated as environments, monitoring and recovery drills are formalised. Where this page says planned, it means not yet in production — not a claim.