Loading…
Loading…
This page covers where the product runs, what it can reach, and — most importantly — what leaves your network.
This page covers where the product runs, what it can reach, and — most importantly — what leaves your network. The short version: the product runs entirely inside your own infrastructure, exposes no public endpoint, talks to its database over a private path, and the only outbound traffic is a minimal, metadata-only signal to the Specaria platform.
The control-plane API, the admin UI, the conversion runtime, the background worker, and the PostgreSQL database all run inside your own network. There is no Specaria-hosted data plane: your SOAP traffic, request/response payloads, archived logs, learned examples, and the entire metadata database stay in your infrastructure.
This means data residency follows your deployment. If you deploy in a particular region, your data lives in that region. Specaria never receives, stores, or proxies your traffic.
Both the runtime and the admin services run with internal-only ingress by default. On the GCP-native deployment this is Cloud Run ingress set to internal-and-cloud-load-balancing — the raw service URL is unreachable from the public internet, and the only entry point is your network's internal load balancer.
Because ingress is internal, the trusted identity headers the proxy injects
(X-Goog-Authenticated-User-*) cannot be spoofed from outside — there is no public path that
could set them. See Authentication.
The metadata database is reached over a private path, not a public IP:
On the GCP-native deployment, services authenticate to the database using IAM database authentication rather than a stored database password. Each service uses its own service-account identity to obtain a short-lived database auth token, which is refreshed before expiry while the service runs. This removes a long-lived static database password from the runtime credential set on that deployment.
A password-auth path also exists (bound from your secret store via
S2R_DB_PASSWORD) for environments where IAM database authentication is not available. The deployment runbook documents which path applies to your installation.
The product's only outbound communication is to the Specaria platform, over HTTPS, and it is strictly metadata. It never sends your SOAP payloads, backend hostnames, internal IPs, consumer identifiers, or any PII.
Your VPC firewall must permit outbound TCP 443 from the product subnet to the Specaria endpoints
listed in the egress allow-list. The product backend itself
only calls api.specaria.io; the other Specaria domains (portal, docs, status, marketing) are
operator-browser-only and are not called by the product backend.
The Specaria-platform integration — JWKS-verified licensing, heartbeat telemetry, update notifications, and feedback — communicates outbound only and sends metadata only. The network properties on this page (in-VPC, no public endpoint, private database connectivity) hold regardless. See Licensing for the details.
| Property | Behaviour | |---|---| | Where it runs | Entirely inside your VPC | | Data residency | Follows your deployment region; data never leaves your network | | Public endpoint | None — internal-only ingress by default | | Operator access | Internal load balancer + identity-aware proxy | | Database path | Private (private-IP Cloud SQL; IAM DB auth on GCP) | | Outbound traffic | HTTPS to the Specaria platform only; metadata-only, no payloads/PII |