S3-compatible storage: external endpoints and local MinIO use different trust boundaries
Sysaro does not store plaintext S3 credentials in Control Plane desired state. External endpoints are probed by the selected Agent, while local MinIO has a typed systemd adapter for bind, ports and storage path.
How the service fits into Sysaro
External S3
The endpoint must be an HTTP(S) origin without embedded credentials; plain HTTP is allowed only for loopback MinIO.
Access/secret credentials are encrypted in the browser for the selected Agent and are not meant to appear as plaintext in the Control Plane.
Connection health runs from the Agent through AWS Signature Version 4, so the result reflects reachability from that server.
Local MinIO
The typed adapter owns /etc/sysaro/services/minio.env and the 90-sysaro.conf systemd drop-in.
Fields cover bind address, API/console ports, data directory and the browser console switch.
Storage paths are restricted to dedicated roots such as /var/lib/minio, /srv/minio, /data/minio or /mnt/<mount>; arbitrary /home or /etc paths are rejected.
Provisioning boundary
The generic package installer intentionally does not deploy MinIO with hidden defaults.
Production provisioning requires explicit volumes, credentials, listen/TLS and backup policy; those choices belong in a dedicated adapter rather than a silent install.
After an API-port change, readiness derives the port from Sysaro-owned config and remains loopback-only.
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.