System requirements

This page lists what the product needs to run: a PostgreSQL database, a container runtime, supported deployment targets, network egress for licensing, payload…

This page lists what the product needs to run: a PostgreSQL database, a container runtime, supported deployment targets, network egress for licensing, payload limits, and the capacity baseline. Confirm your target host qualifies before the Quickstart.

Since v1.0 the requirements below describe the General Availability product. See the v1.0 GA release notes for the full feature inventory and the intentionally out-of-scope list.

Database — PostgreSQL

PostgreSQL is the source of truth for all persistent configuration and state (services, mappings, versions, audit, aggregation tables). Application tables are prefixed s2r_.

PostgreSQL 16 is the validated baseline (the standalone stack ships postgres:16-alpine). Recent prior major versions are expected to work; 16 is what the product is tested against.
Schema migrations are managed by Flyway and run automatically on first start — no manual SQL to apply. Never hand-edit applied migrations.
UTF-8 database encoding is required (ENCODING 'UTF8') so SOAP envelopes, REST payloads, generated contracts, and Hebrew / RTL content round-trip without corruption.
The pgcrypto extension is required for backend-credential encryption. On managed Postgres where the application role is not a superuser, a privileged user must run CREATE EXTENSION pgcrypto; once on the target database (otherwise credential operations fail — see S2R-ADM-0421 in the error-codes reference).
Authentication: password auth works everywhere; on Google Cloud, IAM database authentication is supported. For production, prefer a managed Postgres (Cloud SQL or an equivalent managed service) over the bundled container.

See Installation → Configuration reference for the database environment variables (S2R_DB_HOST, S2R_DB_NAME, S2R_DB_USER, S2R_DB_SSL_MODE, …).

Container runtime

The platform ships as containers: admin-api, runtime, worker, admin-ui, plus PostgreSQL.

Docker Engine 24+ and Docker Compose v2 for the standalone stack (docker compose version).
A Kubernetes / OpenShift cluster for the Helm deployment.
Resources (evaluation, single host): ~2 GB free RAM headroom and ~2 GB free disk for images plus the data volume. Production sizing depends on estate size and traffic — see Operations.

JVM note

The SOAP↔REST conversion core (admin-api, runtime, worker) is a Java 25 + Spring Boot 3.5 stack; the Java package root is com.specaria.s2r. The JVM is bundled inside the container images — you do not install a JDK on the host to run the product. The containers set -XX:+UseContainerSupport and a container-aware heap percentage, so they respect the memory limits you assign. A host JDK 25 + Maven 3.9 is only needed if you build the images locally rather than pulling pre-built images.

Supported deployment targets

Since v1.0 the supported targets are:

| Target | Notes | |---|---| | GCP-native | Cloud Run + Cloud SQL (PostgreSQL, IAM DB auth) + Cloud Storage + Cloud IAP. | | Kubernetes / OpenShift | Helm chart; in-cluster or external PostgreSQL. | | GCP Marketplace | Listing for streamlined GCP deployment. | | Standalone Docker Compose | Control plane + runtime + worker + PostgreSQL on a single host, behind your own reverse proxy / load balancer. |

A cloud-adapter abstraction (object store / compute provisioner / relay-VM gateway / secret store) provides Google Cloud, Azure, and VMware adapters (AWS in progress), with sample Terraform environments for AWS, Azure, and a vSphere relay.

Not in v1.0 (handled as bespoke engagements; see the deprecation/lifecycle policy):

VM appliance images (OVA / Hyper-V / Nutanix) and first-class AWS / Azure / Oracle native ports — on the v1.1 roadmap; sample Terraform for AWS / Azure / vSphere exists today.
Fully air-gapped operation — v1.0 requires outbound HTTPS for licensing (a 14-day offline grace covers transient loss).

See Installation for per-target setup.

Network requirements

Internal-only by design

The product has no public endpoint. It is reached through your own network and gateway, and runs entirely inside your VPC — traffic, payloads, learned examples, archives, and the metadata database all stay in your infrastructure. See Security → Network & data residency.

Outbound egress for licensing

v1.0 requires outbound HTTPS (TLS 1.3+) to the Specaria platform for license verification and update notification. All such calls are outbound from the product — the Specaria platform never initiates a connection inward. Your firewall must permit outbound 443 to the Specaria endpoints listed in Licensing → Egress allow-list.

Licensing behavior:

The license JWT is verified on cold start and re-verified periodically.
14-day offline grace — if the platform is unreachable, the product keeps serving for the grace window, then enters degraded (read-only) mode.
Fail-open telemetry, fail-closed entitlement — a telemetry/heartbeat outage never disrupts traffic; an invalid or expired license disables licensed writes only after the grace period.
No PII egress — outbound telemetry is numeric counts, versions, a hashed host fingerprint, an installation ID, a customer label, and a contact email — never payloads or hostnames.

See Licensing → Offline grace & degraded mode.

TLS termination

The container stack speaks plain HTTP internally. Put a TLS-terminating reverse proxy or load balancer in front (your existing F5 BIG-IP, Citrix ADC, nginx, HAProxy, or cloud load balancer). Pass Host, X-Forwarded-For, and X-Forwarded-Proto: https to the admin UI. See the Docker Compose installation guide.

Payload limits & runtime defaults

Synchronous payload ceiling: 30 MB. Larger requests are rejected with S2R-RUN-0413 (HTTP 413). See Error codes.
Default per-operation timeout: 100 ms, default retries: 2 — both configurable per operation.
Default data retention: 60 days, configurable. See Security → Data retention.

Capacity baseline

The product is engineered and load-tested for a ~1M-calls/day baseline:

~12 requests/second sustained, ~100 rps short burst.
Verified with repeatable sustained / burst / slow-backend load-test scenarios.
Dashboards stay sub-second even across large estates, because all time-bucketed surfaces read pre-computed aggregation tables rather than raw logs at query time.

This is a baseline, not a hard ceiling; sizing for higher throughput is an Operations topic.

Identity & access (for operators)

To gate the admin UI and assign RBAC roles (admin / operator / reader), the product integrates with Google IAP, Azure AD, or standard SAML / OIDC. An evaluation stack can run without SSO, but any real deployment should front the UI with your identity provider. See Security → Authentication.

Next reads

Quickstart — bring up the stack and publish a service.
Installation — production deployment per target.
Licensing → Egress allow-list — exact outbound endpoints.

All Specaria SOAP to REST docs

Loading…