What to build
Expand Lithos remote state support beyond the current S3 / R2 story.
Remote state is one of the strongest parts of the tool because it lets a team or CI runner share a single source of truth for resource IDs and deploy history. Today that path is still fairly narrow: the docs call out Amazon S3 and Cloudflare R2, which is good coverage for some teams but leaves out users who standardize on Azure, Google Cloud, or self-hosted object storage.
The best next step is probably not a long list of one-off providers. A stronger design would be to separate the state backend contract from provider-specific credential loading and then add backends in a way that keeps configuration predictable and failure modes understandable.
Candidate backends / workarounds
- Generic S3-compatible endpoint support to unlock platforms like MinIO, Backblaze B2's S3 API, DigitalOcean Spaces, and Wasabi.
- Native Google Cloud Storage support for teams already deploying through GCP.
- Native Azure Blob Storage support for teams standardizing on Azure.
- Self-hosted MinIO guidance as an officially documented workaround for teams that want remote state without another managed SaaS dependency.
Acceptance criteria
- Lithos has a clear backend abstraction for remote state operations instead of baking provider behavior directly into one path.
- At least one new backend ships, or generic S3-compatible endpoint support lands in a way that clearly unlocks multiple platforms.
- Backend-specific auth/env-var requirements are documented with working config examples.
- Load/save round-trips, missing-credential failures, and common provider misconfiguration cases are covered by tests.
- The docs explain when to choose each backend and how migration from an existing remote state setup should work.
Out of scope
- Replacing object-store state with a database service.
- Solving multi-writer orchestration beyond Lithos's current state semantics.
- Building every possible provider in a single pass.
What to build
Expand Lithos remote state support beyond the current S3 / R2 story.
Remote state is one of the strongest parts of the tool because it lets a team or CI runner share a single source of truth for resource IDs and deploy history. Today that path is still fairly narrow: the docs call out Amazon S3 and Cloudflare R2, which is good coverage for some teams but leaves out users who standardize on Azure, Google Cloud, or self-hosted object storage.
The best next step is probably not a long list of one-off providers. A stronger design would be to separate the state backend contract from provider-specific credential loading and then add backends in a way that keeps configuration predictable and failure modes understandable.
Candidate backends / workarounds
Acceptance criteria
Out of scope