Founder Notes Part 3: Unifying 15+ Cloud Providers with Rust

In Part 2, we explained why Local-First became a trust requirement. Part 3 addresses the implementation challenge: how do you support 15+ providers in one runtime without shipping heavyweight dependency stacks?

---

Q: Integrating 15+ providers sounds brutal. What makes it hard in practice?

A: The complexity is not just endpoint differences; it is identity and request semantics.

AWS SigV4, Azure OAuth2, and multiple vendor-specific HMAC variants all demand distinct signing flows. Some providers are close enough to look familiar, but different enough to break if canonicalization is even slightly off.

If you pull full SDKs for every platform, binary size and dependency surface explode quickly. That is manageable in server-centric SaaS, but expensive and fragile in Local-First distribution.

Q: How did Rust help you keep things unified and lightweight?

A: We treated provider support as a trait contract, not a per-vendor architecture.

Our core abstraction is a `Scanner` trait:

#[async_trait]
pub trait Scanner {
    async fn scan_resources(&self) -> Result<Vec<WastedResource>>;
    fn provider_name(&self) -> &str;
}

Each provider implements the same operational contract. For many integrations, we use focused REST clients with `reqwest` instead of full-service SDKs. That lets us include exactly what we need for scanning, and nothing more.

Q: Does this compromise capability for long-tail providers?

A: It improves focus and maintainability.

We do not need every service endpoint for every provider. We need reliable coverage for high-impact waste classes: compute, storage, snapshots, public IPs, and load balancers.

By implementing only required signing and API paths, we keep execution fast and packaging lean while still covering the workflows customers care about most.

Q: How do you handle concurrency at multi-region scale?

A: Async tasks, not heavyweight threads.

With Rust + `tokio`, region scans run as lightweight tasks multiplexed over a small OS thread pool. We parallelize region and resource queries via `join_all`, which improves throughput while keeping memory behavior stable.

This is important for Local-First: performance must be strong even on ordinary enterprise endpoints.

Q: Why still enforce rate limiting if scans run from customer environments?

A: Decentralized traffic does not remove provider limits or operational etiquette.

Local-First distributes origin IPs, which helps avoid centralized bottlenecks. But we still use token-bucket controls to prevent burst patterns that can trigger provider throttling or defensive systems.

Good scanners should be fast, predictable, and polite to upstream APIs.

Q: What did this architecture unlock for the roadmap?

A: It gave us a foundation for safe automation.

Once discovery is consistent across providers, the next step is controlled execution: planning, approvals, and auditable cleanup workflows. That is exactly what we cover in Part 4.