Support pluggable S3-compatible managed storage backends

[bherila]

Problem description

Temps currently treats managed S3-compatible storage as RustFS-backed infrastructure. That is a good default for many cases, but it makes the managed S3/Blob path depend on a single object-storage implementation.

Operators may want a different S3-compatible backend for reasons such as:

• production maturity and operational risk posture
• storage efficiency for repeated data across environments
• multi-node or geo-distributed storage topology
• compatibility with existing self-hosted object-storage deployments
• provider-specific administrative APIs for bucket, key, policy, and lifecycle management

A common deployment shape is one app with multiple environments, such as:

production
staging
development
preview-<branch>

Each environment may need more than one S3 bucket, for example:

uploads
private-files
hls-media
backups

If each environment gets isolated buckets and its own service-facing container integration, a RustFS-only implementation can become limiting. This is especially true when environments intentionally contain similar or copied data, because backend-level storage behavior becomes an operational concern.

This request is not asking Temps to implement object-level deduplication or content-defined chunking. Those are storage-engine concerns. The request is for Temps to let operators choose an S3-compatible managed storage backend while preserving the same app-facing S3 interface.

Proposed solution

Add a pluggable managed S3-compatible storage backend abstraction for Temps-managed s3, blob, and similar object-storage services.

RustFS can remain the default backend. Add Garage as an optional backend because it is self-hosted, S3-compatible, lightweight, and has a different operational/storage model.

Possible configuration/API shape:

services:
  media:
    type: s3
    backend: garage
    buckets:
      - uploads
      - private-files
      - hls-media

or via API/CLI parameters:

temps service create s3 media --backend garage --bucket uploads --bucket private-files --bucket hls-media

Useful behavior:

• Keep rustfs as the default backend for compatibility.
• Add garage as an optional backend.
• Keep app-facing environment variables stable, e.g. S3_BUCKET, S3_ENDPOINT, S3_ACCESS_KEY, S3_SECRET_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_ENDPOINT_URL, etc.
• Support multiple buckets per linked environment/service where the app needs distinct storage surfaces.
• Generate per-environment credentials/policies rather than sharing a single broad credential across all environments.
• Treat provider-specific lifecycle as backend-specific: container creation, config generation, health checks, bucket creation, key/policy creation, metrics, backup, restore, and migration hooks.
• Document backend tradeoffs rather than replacing RustFS outright.
• Provide a migration/export path between supported S3-compatible backends using normal S3 copy/mirror semantics.

A rough internal shape might be a trait/interface such as:

ManagedS3Backend
  provision_service()
  create_bucket()
  create_access_key()
  render_runtime_env()
  health_check()
  backup()
  restore()
  migrate_from()

The important part is that projects consume an S3-compatible endpoint while Temps handles the backend-specific management details.

Alternatives considered

• Keep RustFS as the only managed backend: simplest, but forces every operator into one object-storage implementation.
• Use only external S3-compatible storage sources: works, but loses the value of Temps-managed service provisioning, credential injection, lifecycle management, and environment isolation.
• Add a one-off Garage service type unrelated to s3/blob: possible, but it would duplicate concepts that should probably be backend-specific implementations of the same managed S3-compatible service contract.
• Ask Temps to implement deduplication itself: not appropriate; deduplication should remain the responsibility of the selected storage backend.
• Ask Garage to support a different dedupe/chunking algorithm: that could be a separate Garage upstream issue, but it should not block Temps from supporting Garage as an optional backend.

Additional context

Garage is only the first motivating backend. This feature would make room for other S3-compatible storage backends in the future while keeping RustFS as the default.

The goal is not to expose every backend-specific option in application configuration. The goal is to let operators choose the managed storage engine at the Temps service layer while applications continue to see standard S3-compatible settings.