Installation — Overview

SOAP-2-REST by Specaria runs entirely inside your network. There is no public endpoint: the platform is reached through your own ingress (cloud IAP, an…

SOAP-2-REST by Specaria runs entirely inside your network. There is no public endpoint: the platform is reached through your own ingress (cloud IAP, an internal load balancer, or a reverse proxy you control). This page covers the supported deployment options and how to choose between them.

Since v1.0 the following topologies are generally available.

Architecture at a glance

The platform is a small set of stateless services backed by one PostgreSQL database:

| Service | Role | | --- | --- | | admin-api | Control plane — onboarding, settings, RBAC, OpenAPI/WSDL generation. Owns the Flyway database migrations (applied on startup). | | runtime | Data plane — performs the SOAP↔REST conversion for live traffic. | | worker | Background jobs — traffic aggregation, discovery derivation, learned-example curation. | | admin-ui | The operator web UI; proxies to admin-api and runtime. | | generic-ingest | Universal HTTP traffic-log receiver (used by the generic-HTTP connector). | | cloud-adapter | Provider abstraction for object store, compute provisioning, relay-VM gateway, and secret store (Google Cloud, Azure, VMware adapters; AWS in progress). |

All persistent configuration and state lives in PostgreSQL (tables prefixed s2r_). The database is the source of truth — see Backup & restore.

Deployment options

| Option | Best for | Status | | --- | --- | --- | | Docker Compose (standalone) | The fastest path. A demo, a pilot, or a single-host production install behind your own load balancer / reverse proxy. Runs on any Docker host (cloud VM or on-prem). | GA | | Kubernetes / OpenShift (Helm) | High-availability, cluster-managed workloads in any cloud or on-prem. In-cluster or external PostgreSQL. | GA | | GCP-native | Lowest-touch managed-service path on Google Cloud: Cloud Run + Cloud SQL + Cloud Storage + Cloud IAP, with IAM database authentication and internal-only ingress. | GA | | GCP Marketplace listing | One-click deploy onto GCP. Uses the GCP-native topology under the hood. | GA |

On the roadmap (v1.1+): VM appliance images (OVA / VMware / Hyper-V / Nutanix) and first-class AWS / Azure / Oracle native ports. Sample Terraform environments for AWS, Azure, and a vSphere relay are available today as a starting point — see GCP & multi-cloud notes.

How to choose

Just evaluating, or running a single host? → Docker Compose. One .env file, one docker compose up. Put your own TLS-terminating proxy or load balancer in front.
You run Kubernetes or OpenShift and want HA? → Helm. Scale the runtime horizontally, point at a managed PostgreSQL, integrate with your cluster ingress and OIDC.
You're on Google Cloud and want managed services with the least operational footprint? → GCP-native. Cloud Run autoscaling, Cloud SQL with IAM DB auth, Cloud IAP at the edge.

All three run the same images and the same schema. You can start on Docker Compose and migrate to Helm or GCP-native later by pointing the new install at a restored database backup.

Before you start

Decide your PostgreSQL strategy: the bundled container (Compose) is fine for demos and small installs; production should use a managed or HA PostgreSQL.
Generate two secrets up front — the database password and the credential key (an AES key used to encrypt backend credentials at rest). See Configuration reference.
Pick the bootstrap admin email(s). The first authenticated user to reach the admin UI becomes admin on first boot.
Plan outbound HTTPS egress to the Specaria platform for licensing and updates (a 14-day offline grace covers transient loss). See Egress allow-list.

Next: pick an option above, then review the Configuration reference for the environment variables and secrets every install needs.

All Specaria SOAP to REST docs

Loading…