How our universal content processing platform Riviera evolved for AI and beyond

From previews to pipeline: How Dropbox’s Riviera became a shared content backbone

Every day, Dropbox products quietly transform user content: a PowerPoint becomes a browsable preview, a signed agreement is flattened into a PDF, a video uploaded to Replay is transcoded for instant streaming. These experiences run on Riviera, an internal content processing platform that has been evolving for roughly a decade. Originally built to generate file previews, Riviera now serves product teams across Search, Replay, Sign, and Dash, and Dropbox is exposing its capabilities externally via an API and Model Context Protocol (MCP) tools.

What began as a solution to a preview problem became the foundation for Dropbox’s AI ambitions. Before a model can summarize a report or answer questions about a document, that content must be extracted, converted, and normalized — the exact kind of work Riviera already did at scale. Now external developers can build on that same infrastructure for their own document workflows, search indexing, and AI pipelines.

The limits of bespoke pipelines

Supporting previews across more than 300 file formats, each with multiple outputs like thumbnails, extracted text, and streaming manifests, presented a coordination challenge. A separate service for every format and output combination would be operationally untenable. PDF logic, for instance, might need to live in both PowerPoint and Word services, duplicating maintenance and dependencies across the environment. Configurations would drift, packages would skew, and the burden would spread.

The solution was a managed platform with a central place for dependencies and tools, backed by a team with deep expertise in content transformation. The breakthrough came when the team stopped treating each preview as a standalone feature. Instead, they decomposed work into smaller, reusable transformations. A PowerPoint preview doesn’t require a custom PowerPoint renderer from end to end: Riviera converts the presentation to PDF, then turns each PDF page into a displayable image. Those same PDF-to-image steps serve PDFs directly and other workflows needing page images.

This idea shaped Riviera’s architecture. A central point collects requests, validates them, composes the required work, and dispatches it to backend workers, while caching responses to shield workers from duplicate or invalid calls. Each worker handles one specific transformation type, giving the platform a single point of maintenance and scaling per capability. Today Riviera runs more than 100 such capabilities, executing hundreds of thousands of transformations per second.

Separating coordination from execution kept the core stable. Adding a new file format or transformation generally meant adding another plugin, not altering Riviera’s infrastructure.

From internal tool to shared platform

Riviera was not designed as a shared platform — it started as an internal service run by the Previews team. But other teams quickly saw the overlap. Thumbnails generated for previews, for example, were equally useful to machine learning teams normalizing images for feature extraction. If both groups could use the same 160×160 thumbnail, Riviera would only need to generate it once.

The Search team adopted Riviera for document indexing. Teams behind Sign, DocSend, and Replay found they could reuse existing transformations instead of building new infrastructure. As internal adoption grew, the plugin model was opened to product teams themselves, letting engineers contribute transformations while the core team maintained the architecture. Plugins became Riviera’s shared library of capabilities.

Replay showed the model working at full strength. Building a video review product required complex transcoding and video manipulation work that Riviera already covered, allowing the product to focus on iteration rather than infrastructure. A clear pattern emerged: a product team would request a capability, and Riviera either exposed an existing one or added a new plugin. Features that might have taken months to build shipped in weeks, with each addition making the platform more attractive to the next adopter.

AI creates a new class of demand

Dash, Dropbox’s AI assistant, introduced a different kind of content processing requirement. Before a model can answer a question about a document, the document has to be transformed into a machine-readable form: text extracted, scanned pages recognized, metadata pulled, and hundreds of formats converted into one consistent representation. These are content transformation problems, not AI problems — and exactly what Riviera was built to solve.

Dash reused Riviera’s existing media and document capabilities rather than building a new system from scratch. The advantage extended beyond Dash: improvements to text extraction improved both search results and AI answers. Faster caching reduced duplication of work across previews, queries, and document processing. File type support added once became available everywhere Riviera is used.

Why shared infrastructure wins

Riviera began with a single goal: preview any file stored in Dropbox. Reaching that goal required building reusable transformations instead of product-specific pipelines. As adoption spread internally, the platform expanded well beyond previews, supporting an increasingly diverse set of workloads across Search, Replay, Sign, and Dash.

A platform compounds in value where a feature does not. Each new product introduces new file types and requirements, and every improvement benefits every team building on top of it. Riviera’s plugin architecture keeps that growth manageable — engineers can add support for new formats without touching the core, and clear boundaries keep the platform focused on reliable content transformation.

Dropbox is now extending that reuse to external developers by making a growing set of Riviera capabilities available through a public API and MCP tools. The infrastructure that started as an internal preview service is now something developers can build on themselves. The technology may have changed over a decade, but the underlying principle hasn’t: build reusable systems around common problems, and they will keep delivering value long after the original use case fades. Capabilities are documented in the Dropbox developer portal.