S3Lab is optimized for local, loopback operation by default.

• Default serving mode: HTTP only.
• Default host binding: 127.0.0.1 for both S3 and inspector endpoints.

HTTPS should be treated as an explicit secure mode for non-local workflows.

• TLS is disabled unless you enable it with --tls-cert/--tls-key or --tls-auto.
• Remote hosts (--host or --inspector-host not loopback) are rejected unless --allow-remote-host is provided.

If you need to run S3Lab beyond loopback:

1. Use HTTPS (--tls-cert and --tls-key, or --tls-auto).
2. Use --allow-remote-host intentionally.
3. Expose traffic only through a trusted network path (VPC, VPN, firewall, ssh tunnel).
4. Import trusted certificates into client trust stores before HTTPS use. --tls-auto emits a self-signed certificate and logs startup guidance for trust-store installation.

Inspector follows the same transport mode as the S3 API endpoint. When HTTPS is enabled, Inspector UI starts with https://... (h1) and uses the same certificate material.

When you use --tls-auto, S3Lab writes deterministic filenames under the active data directory:

• s3lab-tls-cert.pem
• s3lab-tls-key.pem

The files are created once and then reused on future runs.

Trust setup patterns:

• Windows: certutil -addstore -f -user Root ./s3lab-data/s3lab-tls-cert.pem
• macOS: security add-trusted-cert -d -r trustRoot -k ~/Library/Keychains/login.keychain-db ./s3lab-data/s3lab-tls-cert.pem
• Linux: copy the cert into a local trust bundle directory and refresh the trust store (for example /usr/local/share/ca-certificates/).

• Keep --allow-remote-host off unless you truly need remote access.
• Bind only to intended hosts.
• Keep the S3 and inspector endpoints on the same trust boundary.
• Limit inbound access to trusted source addresses.
• Rotate explicitly managed certs per environment; prefer CA-signed material for repeated use.

For the supported commands and defaults, keep existing compatibility scripts and docs in HTTP mode by default (loopback transport).