Service management depth, documented per infrastructure component
These pages connect public search intent to the exact shipped management boundary instead of treating every detected service as fully managed.
PostgreSQL 18
Sysaro verifies PostgreSQL major version 18, manages lifecycle and provides Data Services workflows for databases, roles/access, backup/restore and health. Automatic postgresql.conf tuning is not claimed as shipped yet.
Valkey
Valkey supports discovery/adoption, structured settings, lifecycle and Redis-compatible topology workflows for Replication, Sentinel and Cluster. It is represented as its own service kind instead of falling back to an SQL model.
Temporal Server
Sysaro discovers Temporal Server as a systemd unit or canonical OCI workload, manages lifecycle and probes readiness on loopback port 7233. The typed PostgreSQL deployment profile is validated and previewed, while destructive apply to arbitrary existing installations is intentionally blocked.
ClickHouse
For ClickHouse, Sysaro manages only /etc/clickhouse-server/config.d/90-sysaro.xml with listen address, HTTP/native ports, maximum connections and concurrent queries. Vendor/manual files remain untouched; users, storage and replication are not claimed as fully managed yet.
S3-compatible storage
External S3 endpoints use credentials encrypted in the browser for a specific Agent, and health is checked by that Agent with AWS SigV4. Local MinIO additionally supports lifecycle/readiness and typed systemd configuration without hidden automatic provisioning.
OpenTelemetry Collector
The Sysaro typed profile requires OpenTelemetry Collector Contrib because it uses contrib components. It manages OTLP receivers, the health endpoint, Prometheus export and loopback routing to Loki/Tempo; a core-only Collector remains visible in inventory but cannot receive this profile.
Remotion render worker
A Remotion worker in Sysaro is a Managed Process preset bound to a managed Node.js runtime with FFmpeg/FFprobe completeness checks. Lifecycle can use systemd or a canonical OCI workload, but Sysaro does not replace project code with a hidden generic render script.
Why these pages exist
A single catalog row is useful for fleet operations but is too compressed for architecture, security boundaries and migration decisions. Each page therefore documents the management depth, owned files/endpoints and related use case without inventing upstream capabilities.
The same service IDs and canonical names are exported through service-evidence.json and checked against the Control Plane ServiceCatalog during QA.