Testnet gave developers and infrastructure teams a place to build with Shelby before customer data and long-running customer environments were involved.
It also gave us confidence in the core platform. Testnet showed that the architecture was reliable and performant, allowing us to move the question forward from can this system work? to what should we build around it for real customer workloads?
Opening the system to builders gave us direct feedback on what mattered most in practice: the tooling they relied on, the APIs they expected and the compatibility edge cases that only emerged through real use.
More importantly, it changed our understanding of where the strongest customer demand was coming from and what those teams needed from the data layer.
Customers showed us what mattered most
Shelby began with decentralization as a central part of the proposition.
Testnet showed that teams cared most about what that architecture enabled: performance, economics, control, verification and whether it solved a real workload problem.
The question became less about maximising decentralisation for its own sake and more about where distribution created real value, and how much coverage each workload actually needed.
The AI use case became much clearer
As Testnet progressed, the strongest demand increasingly came from AI and other compute-intensive workloads. This shifted the question from whether decentralized hot storage could be performant and cost-effective to what the data layer needs to do when compute is distributed, expensive and increasingly dynamic.
Bringing a new compute environment into a workload can mean another copy, another staging process, another cache, more synchronization, another set of permissions or another endpoint in the pipeline.
That made the gap between compute flexibility and data flexibility much more tangible.
Familiar workflows matter
Teams do not want another storage interface to learn. Existing applications, tools and pipelines are already built around object storage, and in most cases that means S3.
That reinforced an important principle: changing the infrastructure underneath should not mean changing how the application talks to storage.
S3 compatibility is what makes it possible to try Shelby alongside existing infrastructure without having to first rewrite the surrounding workflow.
Fewer copies does not mean zero movement
Testnet also sharpened how we think about copies.
Data still needs to be available where workloads use it, and teams may still stage, cache or replicate data depending on the workload.
The opportunity is to reduce the repeated full-copy provisioning and operational work that can accumulate as more environments are introduced.
A surprising amount of modern data management is really copy management. Testnet made that problem much more visible.
Verification resonated
Testnet showed that the verification part of Shelby's proposition mattered to people.
Teams were drawn to the idea that important data could carry evidence about what happened to it from the moment it was written.
Shelby creates a sequenced cryptographic record as part of each write, giving an authorised party a way to check what object or version was committed, when it was written and in what order successive writes occurred.
That is a specific primitive. It does not prove who originally created the data, establish ownership or authenticity, or determine what happens once that data enters another system.
But the demand points to a broader question: as valuable data and IP move between storage systems, compute environments, models and agents, what will teams need to be able to prove?
The write record gives Shelby a foundation to build from. Real customer workflows will help determine which additional forms of evidence are valuable enough to belong in the data layer itself.
The next layer has to come from real workloads
Testnet gave us confidence in the core architecture and showed us how builders wanted to interact with it.
Object storage is a foundation for a wide range of workloads, from analytics and data lakes to newer AI-native patterns. As AI demand grows, those workload shapes are changing quickly: GPU environments are becoming more dynamic, agent interactions are creating new access patterns, and data increasingly needs to serve multiple systems and locations.
That is why we want the next layer of Shelby to be shaped with customers.
Private Beta gives us a way to see which needs repeat across workloads, which are specific to individual teams, and where new capabilities will create the most value.
The core platform gives us the foundation. Real customer use should shape what we build on top of it.