Valkey reuses Sysaro’s mature Redis-compatible Data Services model
Valkey is not a parallel duplicate module. Sysaro extends the existing Redis-compatible settings and topology model while keeping a distinct service identity and the same Agent safety boundaries.
How the service fits into Sysaro
Why there is no duplicate module
Valkey shares a substantial operational model with Redis, so duplicating screens would make UX and maintenance worse.
Sysaro reuses settings and topology workflows while preserving an explicit Valkey kind in desired and actual state.
Adopting an existing service builds the correct Redis-compatible schema instead of an SQL fallback.
What is managed
Bind and other structured Redis/Valkey settings are validated before an Agent job is dispatched.
Topology workflows cover the Replication, Sentinel and Cluster foundation.
Lifecycle and health stay in the common service/fleet layer while deeper settings remain in Data Services.
Management boundary
Sysaro does not claim that every Redis and Valkey feature is identical; only explicitly supported compatible operations are shared.
Arbitrary configuration fragments with shell/comment delimiters do not pass structured validation.
Further tuning and topology work extends Data Services rather than introducing a generic configuration editor.
What this page does not claim
Detection, lifecycle or a typed subset is not described as complete management of every upstream capability. The canonical current scope is also published in service-evidence.json and the 18-service catalog.