Zero-Cost Object Storage: A Stateless S3-Compatible Proxy

A technical founder built a stateless S3-compatible proxy to leverage personal cloud storage, bypassing premium fees. This architecture uses NestJS, Fastify, OpenDAL, and BullMQ to achieve zero direct storage costs.

A technical founder, posting under the handle devto, claims to have built a fully stateless S3-compatible object storage solution for $0, leveraging hundreds of gigabytes of idle personal cloud storage across Google Drive, Dropbox, and Mega accounts. The project's core tenet was to eliminate storage costs by ensuring files exist on the infrastructure only in-flight as streaming data, never cached or retained on local servers.

Stateless Architecture for Zero Cost

The fundamental constraint for this project was strict statelessness. The founder reports that no files are cached or stored on their own servers. Data passes through the system as streams, directly to and from personal cloud storage providers. This design eliminates server-side storage costs and simplifies data privacy, as the infrastructure itself does not retain user data. The architecture relies on abstracting diverse cloud storage APIs into a unified S3-compatible interface.

Three-Server Monorepo Design

To manage complexity and ensure performance, the system is structured as a monorepo containing three distinct, decoupled services built with NestJS and Fastify. Fastify was chosen over Express to mitigate Node.js HTTP overhead when proxying heavy data streams. The services include:

• The Main API Server: This service handles user authentication, the web dashboard, and OAuth flows. It is explicitly designed not to process raw file data or synchronization jobs, aiming for high availability and responsiveness.
• The Worker Server: Heavy asynchronous tasks, such as sync jobs, are pushed from the Main API to a BullMQ queue. The Worker server then processes these background jobs, preventing them from blocking the primary API traffic and ensuring safe, non-blocking execution.
• The S3-Compatibility Server: This dedicated server is responsible for parsing standard AWS S3 API signatures, translating S3-specific XML payloads, and directly streaming object data. Its singular focus optimizes for S3 protocol compatibility and data throughput.

Adapter Pattern with OpenDAL

To manage the disparate APIs of various cloud storage providers (Google Drive, Dropbox, Mega), the founder implemented the Adapter Pattern. This approach defines a unified StorageAdapter interface, allowing the core engine to interact with any connected provider identically, regardless of its underlying API specifics. For low-level file system operations, the project utilizes OpenDAL (Open Data Access Layer), which provides a robust data access abstraction layer. This combination prevents the codebase from becoming entangled with provider-specific logic, streamlining integration and maintenance.

What We'd Change

The technical elegance of abstracting multiple storage providers into an S3-compatible layer is evident. However, the reliance on personal cloud storage accounts presents significant limitations for any commercial application. For businesses, using individual Google Drive or Dropbox accounts would introduce critical compliance, security, and scalability issues. Data governance, access control, and audit trails would be fragmented and difficult to manage across disparate personal accounts.

Furthermore, while the founder claims zero direct storage costs, the performance and reliability of such a system are inherently tied to the rate limits and service level agreements (SLAs) of consumer-grade cloud storage. These are typically not designed for high-throughput, mission-critical business operations. For a production-grade service, dedicated cloud storage (like S3 itself or alternatives) offers predictable performance, enterprise-grade security features, and formal SLAs that personal accounts cannot match. The operational overhead of managing multiple personal accounts as a single logical bucket could also become substantial as usage scales.

This architecture demonstrates a clever technical solution to a cost problem for hobby projects or highly niche, non-commercial applications. It highlights ingenuity in resourcefulness rather than a scalable, enterprise-ready blueprint. The core principle of abstracting storage providers is sound, but the choice of personal accounts as the backend is the critical limiting factor for broader applicability.

The project demonstrates how a founder can eliminate direct storage costs for personal or small-scale projects by creatively repurposing existing resources. The technical implementation, particularly the use of a monorepo, message queues, and an adapter pattern, provides a clear blueprint for managing complexity in distributed systems. This approach offers a path for highly technical founders to defer infrastructure expenses during early development, focusing resources on product features. The trade-off involves accepting the limitations of consumer-grade storage for performance, reliability, and enterprise compliance.

The investor read

This project signals a strong drive among indie and micro-SaaS founders to aggressively minimize infrastructure costs, even for core components like object storage. While the specific implementation of using personal cloud accounts is unlikely to scale to venture-backed levels due to inherent compliance, security, and performance limitations, the underlying technical pattern of abstracting storage providers (via OpenDAL and the Adapter Pattern) is robust. Investors should note this as a common bootstrapping tactic, allowing founders to validate ideas with minimal burn. For a product leveraging this approach to become investable, it would need to replace personal accounts with enterprise-grade, cost-optimized storage backends, or target a highly niche market where these limitations are acceptable.

Pull quote: “The project demonstrates how a founder can eliminate direct storage costs for personal or small-scale projects by creatively repurposing existing resources.”