Riviera demonstrates how to build a scalable, modular content processing system that avoids technical debt through reusable transformations. It provides a blueprint for preparing unstructured data for AI applications, now accessible to external developers via API.
Every day, Dropbox products transform enormous amounts of content behind the scenes. Open a PowerPoint deck on your phone in Dropbox, and it’s rendered into a crisp preview you can quickly browse. Finalize an agreement in Sign, and it's flattened into a PDF. Upload a video to Replay—our video review and approval tool—and it's transcoded into a lightweight version that streams instantly. These experiences span different products, but they're all powered by the same underlying system.
That system is Riviera, our content processing platform that’s been iteratively improving content transformation in our products for roughly a decade. Whenever a file needs to be prepared for another application, Riviera does that heavy lifting in the background while operating at a massive scale. (For example, Riviera transforms vast amounts of massive media into streamable content, each day producing output equivalent to 8 years of video). Initially, Riviera started as an internal service for generating file previews, but over time, it evolved into a shared platform used across Dropbox by product teams like Search, Replay, Sign, and Dash. We are now making these capabilities available to our developer ecosystem and design partners through API and Model Context Protocol tools.
As Dropbox built AI-powered products like Dash, the need for reliable, reusable content transformation only grew. Before an AI model can answer questions about a document or summarize a report, that content has to be extracted, converted, and prepared in a consistent way—a challenge many developers now face as they build AI applications of their own. Whether you're building a content management system, automating document workflows, indexing files for search, or preparing documents for AI applications, you can now use our API to build on the same infrastructure that powers Dropbox products.
In this story, we’ll cover how Riviera grew from a preview service into a shared platform, the architectural decisions that made that possible, and why we've opened those capabilities to engineers outside of our organization.
Because Dropbox users store all kinds of files, they need to be able to open any of them on any device quickly and see something useful. These are what we refer to as previews, a visual representation of your files across Dropbox surfaces. Meeting that expectation is harder than it sounds. Dropbox supports more than 300 file formats, each of which can produce multiple outputs: thumbnails, full previews, extracted text, streaming manifests, metadata, and more. To do this, we needed to consider how to build a system to serve these previews.
Building a separate service for every file format and every output would quickly become unmanageable. Doing so would mean many capabilities would end up duplicating small pieces of other capabilities. Imagine both PowerPoint and Word processing needing PDF logic, if they lived as separate services we then have to maintain similar PDF logic in two places. This would make maintenance more difficult and spread redundant dependencies around the environment where Dropbox runs (the collection of software and hardware that make up our architecture). Configurations would drift, package versions would skew, and the operational burden would grow.
This meant we needed a managed platform, a place where we could construct these services to be shared across many different features. We needed one place where the dependencies and tools could live, with a team that could build deep expertise in these capabilities. We also needed a design that could scale against all of our stored file types and make the platform itself manageable.
In attempting to solve for this problem, the breakthrough came when we stopped thinking about every preview as a separate feature. Instead, we broke each task into a series of smaller transformations that could be reused. Rendering a PowerPoint preview, for example, doesn't require a custom PowerPoint renderer from start to finish. Riviera first converts the presentation into a PDF, then turns each PDF page into an image that can be displayed anywhere.
Those same PDF-to-image steps can also be reused for PDFs themselves and for other workflows that need page images. By building reusable transformations instead of one-off pipelines, we could support new file types and new products without starting from scratch each time.
That idea shaped Riviera’s architecture. We built a central point for collecting requests, composing the work to be done, and dispatching that work to backend workers. This central piece validates requests and caches responses which protects the backend workers from duplicate or invalid work. Each backend worker belongs to a specific type of transformation, which allows us to have one point of maintenance and scaling per capability. Today, Riviera has more than 100 such capabilities performing hundreds of thousands of transformations every second.
Separating coordination from execution made the platform easy to extend. Supporting a new file format or a new type of transformation usually meant adding another plugin rather than changing Riviera's core infrastructure. As Riviera grew, the core system stayed stable while its capabilities continued to expand.
While Riviera wasn't originally intended to be a shared platform—it started as an internal tool run by a dedicated Previews team—it didn't take long for other teams to recognize they had similar content transformation problems. For instance, the thumbnails created for previews turned out to be equally useful for machine learning teams normalizing images for feature extraction. If both consumers could use the same 160×160 thumbnail, Riviera only had to generate it once.
The Search team soon adopted Riviera to prepare documents for indexing. As Dropbox expanded with products like Sign, DocSend, and Replay, those teams also found they could reuse existing transformations instead of building new infrastructure. As adoption grew internally across our organization, we opened the plugin model to product teams themselves. Engineers could contribute new transformations while the Riviera team maintained the platform's core architecture. Plugins became Riviera's shared library of transformations.
Dropbox Replay, our video review product, became one of the best examples of this model in practice. To build a video review product, you have to complete the complex task of transcoding and manipulating video data. Riviera was able to fill that need, allowing the product to grow rapidly and iterate on its capabilities instead of building from the ground up.
A pattern emerged. Product teams identified a transformation they needed. Riviera exposed an existing capability or added a new plugin. Features that might once have taken months shipped in weeks, and every addition made the platform more capable for the next team that adopted it.
When Dash brought AI to Dropbox, it created a new kind of demand for Riviera. Before an AI model can answer a question about a document or summarize a report, the document has to be transformed into something the model can understand. Doing that well means extracting text, recognizing scanned pages, pulling out metadata, and converting hundreds of different file formats into a consistent representation.
Those aren't AI problems. They're content transformation problems, and they're exactly what Riviera was built to solve. Just as Replay found value in Riviera’s media capabilities, the Dash team was able to accelerate their content processing pipelines by using existing Riviera features.
Because Riviera already supported hundreds of file types and transformations, the Dash team didn't have to build a new document processing system from scratch. As Dash ingests content from Dropbox, Google Drive, Slack, and other connected sources, Riviera prepares those files for indexing and AI. Later, when someone asks a question about a document, those transformed contents are then used as relevant context for the models to generate a response.
That investment paid off well beyond Dash. Improvements to text extraction made both AI responses and search results more accurate. Faster caching reduced the work required to generate previews, answer questions, and process documents. Support for a new file type only had to be added once before it became available everywhere Riviera was used.
That's the advantage of shared infrastructure. Instead of every product solving the same content transformation problems independently, Dropbox solves them once in Riviera, and every product built on top of it benefits.
Riviera started with a single goal: make it possible to preview any file stored in Dropbox. Solving that problem meant building reusable content transformations instead of product-specific pipelines. As more teams across Dropbox adopted the platform, Riviera expanded far beyond previews to support hundreds of file formats and increasingly diverse workloads, powering features across Search, Replay, Sign, Dash, and more.
That growth shaped both the platform and the philosophy behind it. Unlike a feature, which delivers value once, a platform becomes more valuable every time another team builds on it. Each new product introduced new file types, workloads, and requirements. Every improvement made Riviera more capable, and every team building on top of it benefited from those investments.
The platform was also designed to scale without becoming more difficult to maintain. Its plugin architecture allows engineers to add support for new file formats and transformations without changing the core system, while clear boundaries around what belongs in Riviera have kept it focused on transforming content reliably at scale.
Today, we’re extending that reuse beyond Dropbox by making a growing set of Riviera capabilities available through our public API and MCP tools. The platform that began as an internal preview service is now infrastructure that developers can build on, too. And while the technology has changed dramatically over the past decade, the idea behind Riviera hasn't. Build reusable systems around common problems, and they'll continue creating value long after the original use case is gone. To learn more about the available capabilities, visit our developer portal here.
Acknowledgments: Special thanks to Team Riviera, as well as everyone who contributed along the way and helped bring Riviera to where it is today.
If building innovative products, experiences, and infrastructure excites you, come build the future with us! Visit jobs.dropbox.com to see our open roles.
Continue reading on the original blog to support the author
Read full articleEngineers face increasing data fragmentation across SaaS silos. This post details how to build a unified context engine using knowledge graphs, multimodal processing, and prompt optimization (DSPy) to enable effective RAG and agentic workflows over proprietary enterprise data.
Building a scalable feature store is essential for real-time AI applications that require low-latency retrieval of complex user signals across hybrid environments. This approach enables engineers to move quickly from experimentation to production without managing underlying infrastructure.
Engineers must process massive unstructured multimedia data efficiently. This integration demonstrates how specialized architectures can achieve deep multimodal understanding at exabyte scale while maintaining low computational overhead and high search relevance.
This article provides a blueprint for moving beyond manual prompt engineering. By using DSPy to create automated feedback loops between human labels, LLM judges, and agent prompts, engineers can systematically improve AI performance and reduce operational costs at scale.
