Loading…
Loading…
Lists the required PostgreSQL database, container runtime, network access, and resource baselines for deploying the SOAP-2-REST platform.
This document specifies the system requirements for deploying and operating the SOAP-2-REST platform as of version 1.0. It details the necessary database, container runtime, supported deployment targets, network configuration, and operational limits. An engineer planning a deployment must confirm that the target environment meets these requirements before proceeding with installation.
The platform is delivered as a set of container images that run within your infrastructure. It relies on a PostgreSQL database as its source of truth and requires outbound network access for license validation. All application data, including configuration and traffic metadata, resides within your network.
The platform uses a PostgreSQL database as the source of truth for all persistent configuration and state, including services, mappings, versions, audit logs, and pre-computed aggregation tables. All application tables are prefixed with s2r_.
Version: PostgreSQL 16 is the validated baseline. While recent prior major versions are expected to work, all product testing is performed against version 16. The standalone Docker Compose stack includes a postgres:16-alpine container.
Schema Migrations: Database schema migrations are managed by Flyway and are applied automatically when the application starts for the first time. Manual SQL application is not required. Do not manually edit applied migration records in the database.
Encoding: The database encoding must be set to UTF-8 (e.g., ENCODING 'UTF8'). This is critical to prevent data corruption and ensure that SOAP envelopes, REST payloads, generated contracts, and content in languages such as Hebrew (including right-to-left text) are handled correctly.
pgcrypto Extension: The pgcrypto extension is required for encrypting backend service credentials stored in the database. If this extension is not enabled, credential management operations will fail. On managed PostgreSQL services where the application's database role lacks superuser privileges, a privileged user must execute the following command once on the target database:
CREATE EXTENSION pgcrypto;
Authentication: Standard password-based authentication is supported in all environments. For deployments on Google Cloud, IAM database authentication is also supported. For production environments, a managed PostgreSQL service (such as Google Cloud SQL or an equivalent) is recommended over the bundled container.
For a complete list of database configuration environment variables (S2R_DB_HOST, S2R_DB_NAME, etc.), see the Installation Configuration reference.
The platform is distributed as a set of OCI-compliant container images: admin-api, runtime, worker, admin-ui, and an optional PostgreSQL container for standalone deployments.
Production resource requirements depend on the number of services and traffic volume. See the Operations documentation for sizing guidance.
The core application components (admin-api, runtime, worker) are built on a Java 25 and Spring Boot 3.5 stack. The Java Virtual Machine (JVM) is bundled inside the container images.
-XX:+UseContainerSupport and a container-aware heap percentage, allowing the JVM to respect memory limits assigned by the container runtime (e.g., Docker or Kubernetes).As of v1.0, the following deployment targets are officially supported.
| Target | Notes |
|---|---|
| GCP-native | Cloud Run + Cloud SQL (PostgreSQL, IAM DB auth) + Cloud Storage + Cloud IAP. |
| Kubernetes / OpenShift | Helm chart; supports in-cluster or external PostgreSQL. |
| GCP Marketplace | A marketplace listing is available for streamlined deployment on Google Cloud. |
| Standalone Docker Compose | Deploys the control plane, runtime, worker, and PostgreSQL on a single host. Requires a separate, user-provided reverse proxy or load balancer. |
The product includes a cloud-adapter abstraction layer for object storage, compute provisioning, and secret management, with existing adapters for Google Cloud, Azure, and VMware. Sample Terraform environments are available for AWS, Azure, and a vSphere relay.
The following are not supported as standard deployments in v1.0 and are handled as bespoke engagements:
The platform is designed to operate entirely within your private network (e.g., VPC). It has no public-facing endpoints. All traffic, payloads, and metadata remain in your infrastructure.
The product requires outbound HTTPS (TLS 1.3+) connectivity to the Specaria platform for license verification and to check for updates.
The application containers communicate internally over plain HTTP. A TLS-terminating reverse proxy or load balancer (e.g., NGINX, HAProxy, F5 BIG-IP, or a cloud load balancer) must be placed in front of the platform. This component is responsible for terminating TLS and forwarding traffic to the admin-ui container.
The proxy must pass the following HTTP headers to the application:
HostX-Forwarded-ForX-Forwarded-Proto: httpsThe following default limits and settings apply to the runtime.
| Parameter | Default Value | Description |
|---|---|---|
| Synchronous Payload Ceiling | 30 MB | Requests with payloads larger than this are rejected with an HTTP 413 status. See error code S2R-RUN-0413. |
| Per-Operation Timeout | 100 ms | The default timeout for a backend operation. This is configurable on a per-operation basis. |
| Per-Operation Retries | 2 | The default number of retries for a backend operation. This is configurable on a per-operation basis. |
| Data Retention | 60 days | The default retention period for runtime data. This is configurable. |
The platform is engineered and tested to support a baseline of approximately 1 million calls per day.
This baseline has been verified with repeatable load-test scenarios covering sustained, burst, and slow-backend conditions. Administrative dashboards remain responsive (sub-second load times) even with large service estates because they query pre-computed aggregation tables instead of raw log data. Sizing for higher throughput is covered in the Operations documentation.
To secure the admin UI and manage operator access, the platform integrates with external identity providers for authentication and Role-Based Access Control (RBAC). Supported integrations include:
While an evaluation stack can be run without an SSO provider, all production deployments should be fronted by your organization's identity provider.
S2R-ADM-0421, it indicates that the pgcrypto extension is missing or not enabled in the PostgreSQL database.S2R-RUN-0413, the synchronous payload size has exceeded the 30 MB limit.UTF-8 encoding.