System Requirements

Overview

This document specifies the system requirements for deploying and running the SOAP-to-REST platform. It covers the necessary database, container runtime, supported deployment targets, network configuration, and resource baselines. The platform is designed to run entirely within an API publisher's own infrastructure, such as a private VPC, with no public-facing endpoints of its own. It transforms SOAP services into RESTful APIs, and all configuration, state, and traffic data reside within the publisher's environment.

Before beginning installation, confirm that your target environment meets these requirements. These requirements apply to the General Availability (GA) product, version 1.0 and later.

Database Requirements

The platform uses a PostgreSQL database as its source of truth for all persistent data, including service configurations, mappings, audit logs, and pre-computed aggregation tables for reporting. All application tables are prefixed with s2r_.

• Version: PostgreSQL 16 is the validated and tested baseline. While recent prior major versions are expected to work, all official 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.
• Encoding: The database encoding must be set to UTF-8 (ENCODING 'UTF8'). This is critical to ensure that SOAP envelopes, REST payloads, generated API contracts, and content in right-to-left (RTL) languages like Hebrew can be processed without data corruption.
• Extensions: The pgcrypto extension is required for encrypting credentials stored for backend services.
• Authentication: Standard password authentication is supported in all environments. For deployments on Google Cloud, IAM database authentication is also supported. For production environments, using a managed PostgreSQL service (such as Google Cloud SQL or an equivalent) is recommended over the bundled container.

CREATE EXTENSION pgcrypto;

Database connection details are configured via environment variables (e.g., S2R_DB_HOST, S2R_DB_NAME, S2R_DB_USER). For a complete list, see the Installation Configuration reference.

Container and Compute Requirements

The platform is delivered as a set of container images: admin-api, runtime, worker, admin-ui, and a PostgreSQL container for standalone deployments.

• Container Runtime:
  • For standalone deployments: Docker Engine 24+ and Docker Compose v2 are required.
  • For clustered deployments: A Kubernetes or OpenShift cluster is required for the Helm-based deployment.
• Resource Allocation (Evaluation): For a single-host evaluation deployment, the following resources are recommended:
  • RAM: ~2 GB of free memory headroom.
  • Disk: ~2 GB of free disk space for container images and the data volume.
• Resource Allocation (Production): Production resource sizing depends on the number of services and traffic volume. See the Operations guide for detailed guidance.

JVM Details

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.

• You do not need to install a JDK on the host machine.
• The containers are configured with -XX:+UseContainerSupport and a container-aware heap percentage, allowing them to respect memory limits assigned by the container runtime.

Supported Deployment Targets

As of version 1.0, the platform officially supports the following deployment targets:

The platform uses a cloud-adapter abstraction for interacting with object storage, compute provisioning, and secret stores, with existing adapters for Google Cloud, Azure, and VMware.

Network Requirements

Internal Network Design

The platform is designed to operate exclusively within your private network (e.g., a VPC). It has no public-facing endpoints by default. All traffic, API payloads, and metadata remain within your infrastructure. Access to the platform is managed through your existing network gateways and security controls.

Outbound Egress for Licensing

The platform requires outbound HTTPS (TLS 1.3+) connectivity to the Specaria platform for license verification and to check for updates.

• Connection Direction: All connections are initiated outbound from the product to the Specaria platform. The Specaria platform will never initiate an inbound connection.
• Firewall Configuration: Your firewall must be configured to allow outbound traffic on port 443 to the endpoints listed in the Egress Allow-List.
• Offline Grace Period: If the licensing platform is unreachable, the product continues to function normally for a 14-day grace period. After this period, it enters a degraded (read-only) mode until connectivity is restored.
• Failure Behavior: Telemetry or heartbeat failures are designed to fail-open, meaning they will not disrupt API traffic. Entitlement or license validation failures are fail-closed, meaning write operations will be disabled after the grace period expires.
• Data Egress: Outbound telemetry contains only numeric counts, version information, a hashed host fingerprint, an installation ID, a customer label, and a contact email. It never includes API payloads, hostnames, or other personally identifiable information (PII).

TLS Termination

The application containers communicate internally over plain HTTP. A TLS-terminating reverse proxy or load balancer (such as F5 BIG-IP, Citrix ADC, NGINX, HAProxy, or a cloud provider's load balancer) must be placed in front of the platform.

Runtime Limits and Defaults

The following default limits and settings are configured out of the box. Most are configurable on a per-operation basis.

Capacity Baseline

The platform is engineered and load-tested to support a baseline of approximately 1 million calls per day.

• Sustained Throughput: ~12 requests per second (rps).
• Burst Throughput: ~100 rps for short bursts.

Dashboard and UI performance remain fast (sub-second response times) even with large numbers of services because all time-bucketed data is read from pre-computed aggregation tables, not from raw logs at query time. Higher throughput requirements can be met by scaling resources as described in the Operations guide.

Identity and Access Control

Access to the Admin UI and its Role-Based Access Control (RBAC) features (admin, operator, reader roles) is managed by integrating with an external identity provider.

• Supported Providers: Google IAP, Azure AD, and any standard SAML or OIDC provider.
• Recommendation: For any non-evaluation deployment, the Admin UI should be protected by your organization's identity provider.

Troubleshooting

• Credential Operations Fail (S2R-ADM-0421): This error indicates that the pgcrypto extension is not enabled in the PostgreSQL database. A privileged user must run CREATE EXTENSION pgcrypto; on the database.
• Requests Fail with HTTP 413 (S2R-RUN-0413): This error occurs when a synchronous request payload exceeds the configured maximum size (default: 30 MB). The request is rejected by the runtime.
• Degraded (Read-Only) Mode: If the platform cannot reach the Specaria licensing service for more than the 14-day grace period, it will enter a degraded mode. In this mode, existing services will continue to function, but creating or modifying configurations will be disabled until license verification succeeds.

See Also

• Quickstart
• Installation Guide
• Licensing: Egress Allow-List
• Security: Authentication
• API Reference: Error Codes

All SOAP-to-REST docs