Operations — Overview
This section is the operator's runbook for running SOAP-2-REST by Specaria in production: how to deploy and upgrade safely, what to check day to day, how to…
This section is the operator's runbook for running SOAP-2-REST by Specaria in production: how to deploy and upgrade safely, what to check day to day, how to diagnose the common failure modes, and how to back up and restore.
If you are installing for the first time, start with Installation and the Configuration reference, then come back here.
The pages
- Deployment runbook — the operational deploy sequence (admin-api → runtime → worker → relay/ingest refresh), why the order matters, and how to verify what is actually running via deploy provenance.
- Daily operations — the day-2 playbook: the Operations Dashboard, ingest-health checks, catalog updates, settings, the update channel, and a suggested daily checklist.
- Troubleshooting — symptom-first diagnostics for the
common issues: ingest gaps, schema mismatch after an upgrade, credential-key
errors (
S2R-ADM-0419), payload-too-large (S2R-RUN-0413), lockout, and where to find logs. - Backup & restore — PostgreSQL backup and restore, with the reminder that the database is the single source of truth for all configuration and state.
Operating model in one screen
The product is four cooperating services backed by one PostgreSQL database:
| Service | Role | Operational note | | --- | --- | --- | | admin-api | Control plane | Owns the Flyway migrations. Deploy/upgrade this first. | | runtime | Data plane (conversion) | Stateless; scale horizontally; keep a warm minimum to avoid cold starts. | | worker | Aggregation, discovery derivation, learned examples | Keep healthy — dashboards read the tables it produces. | | admin-ui | Operator web UI | Proxies to admin-api and runtime. |
Two principles run through everything in this section:
- The database is the source of truth. All persistent config and state
lives in PostgreSQL (
s2r_*tables). Back it up; the application pods are disposable. - Dashboards read aggregation tables, never raw logs. Every time-bucketed surface is served from pre-computed aggregations refreshed by the worker, so they stay sub-second even on large estates. If the worker's aggregation refresh is failing, dashboards silently go stale — treat that as high-priority (see Troubleshooting).
Capacity baseline
The platform is engineered and load-tested for a ~1M-calls/day baseline (≈ 12 requests/second sustained, ~100 rps in short bursts). See Daily operations for how to verify headroom and Metrics & SLO reports for the surfaces that show it.