StrovaPI is headquartered in Singapore and operates across the Asia-Pacific region. All customer data is stored in Australia, in Google Cloud's Melbourne region, and does not leave the country during normal operation.
All database records and uploaded files are encrypted at rest using AES-256, managed by Google Cloud. No additional configuration required — it is on by default for every byte stored.
All traffic is served exclusively over HTTPS. HTTP connections are not accepted. HSTS is enforced with a one-year max-age, including subdomains, preventing any unencrypted access.
Access is enforced at the database layer — not just the UI. Every read and write is checked against the requesting user's role. The only records reachable without signing in are the site induction and gate sign-in pages a worker opens by scanning the code at the gate; they cannot be listed or discovered, only opened with that code.
Every record belongs to a project, and every read and write is checked at the database rules layer against explicit project membership — not in the application. Document files are fenced the same way: drawings, photos and signed records are reachable only by accounts that belong to that workspace. A user reaches the projects they have been added to and nothing else, so one organisation's registers, drawings and correspondence are never visible to another's staff.
All major records — defects, documents, RFIs, actions, correspondence — maintain a full audit log of every state change: who made it, when, and what changed. This log cannot be edited by users.
Removing a record takes it off the register, not out of the database. It keeps its number, records who removed it and when, and anyone who could remove it can put it back. The database rules themselves refuse to delete a record — so a mis-click on a signed inspection is a click on Restore, not a phone call to your client.
StrovaPI contains no third-party analytics, ad trackers, or behavioural profiling tools. No data is shared with advertising networks. Interest-cohort tracking (FLoC) is explicitly disabled.
StrovaPI uses three user roles per project. Permissions are enforced server-side — changing the URL or API request cannot bypass them.
StrovaPI runs entirely on Firebase and Google Cloud services. Google holds the following certifications relevant to enterprise and government customers across the Asia-Pacific region.
Google Cloud's full compliance documentation is available at cloud.google.com/compliance
Every response from app.strovapi.com includes the following HTTP security headers, applied at the hosting layer — they cannot be bypassed by application code.
| Header | Purpose |
|---|---|
| Strict-Transport-Security | Enforces HTTPS for 1 year across all subdomains. Preload-eligible — major browsers will never attempt an unencrypted connection. |
| Content-Security-Policy | Restricts which scripts, styles, and resources can load. Inline scripts from unknown sources are blocked. Framing is denied entirely. |
| X-Frame-Options | DENY — the application cannot be embedded in an iframe on any external site, preventing clickjacking attacks. |
| X-Content-Type-Options | nosniff — browsers cannot override the declared content type, preventing MIME-sniffing attacks. |
| Referrer-Policy | strict-origin-when-cross-origin — limits referrer information sent to external sites. |
| Permissions-Policy | Microphone, geolocation, and interest-cohort tracking are explicitly disabled. Camera access is restricted to the application itself. |
australia-southeast1 and australia-southeast2 — Sydney and Melbourne, Australiaaustralia-southeast2australia-southeast1australia-southeast2, with scheduled jobs in australia-southeast1Enterprise deployments, government projects, and clients with specific compliance obligations — talk to us directly.