惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

AWS News Blog
AWS News Blog
T
Tenable Blog
Project Zero
Project Zero
T
The Exploit Database - CXSecurity.com
L
LINUX DO - 热门话题
T
Threat Research - Cisco Blogs
T
Threatpost
Security Latest
Security Latest
C
Cisco Blogs
L
Lohrmann on Cybersecurity
S
Security @ Cisco Blogs
Google Online Security Blog
Google Online Security Blog
NISL@THU
NISL@THU
AI
AI
V
Vulnerabilities – Threatpost
Google DeepMind News
Google DeepMind News
C
Cyber Attacks, Cyber Crime and Cyber Security
C
CXSECURITY Database RSS Feed - CXSecurity.com
The Last Watchdog
The Last Watchdog
G
GRAHAM CLULEY
Cloudbric
Cloudbric
H
Hackread – Cybersecurity News, Data Breaches, AI and More
H
Hacker News: Front Page
U
Unit 42
A
Arctic Wolf
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
MyScale Blog
MyScale Blog
O
OpenAI News
Scott Helme
Scott Helme
V2EX - 技术
V2EX - 技术
P
Proofpoint News Feed
博客园 - 叶小钗
Hugging Face - Blog
Hugging Face - Blog
云风的 BLOG
云风的 BLOG
V
Visual Studio Blog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Cyberwarzone
Cyberwarzone
博客园 - 【当耐特】
H
Heimdal Security Blog
S
Schneier on Security
阮一峰的网络日志
阮一峰的网络日志
Help Net Security
Help Net Security
D
DataBreaches.Net
Y
Y Combinator Blog
Hacker News - Newest:
Hacker News - Newest: "LLM"
TaoSecurity Blog
TaoSecurity Blog
K
Kaspersky official blog
N
News and Events Feed by Topic
WordPress大学
WordPress大学
P
Palo Alto Networks Blog

Dropbox Tech Blog

How we used DSPy to turn AI evaluations into better responses in Dash chat How Dropbox uses MCP and Dash to close the design-to-code security gap Beyond code generation: rethinking engineering productivity in the age of AI agents Introducing Nova, our internal platform for coding agents Improving storage efficiency in Magic Pocket, our immutable blob store Reducing our monorepo size to improve developer velocity How we optimized Dash's relevance judge with DSPy Using LLMs to amplify human labeling and improve Dash search relevance How low-bit inference enables efficient AI Insights from our executive roundtable on AI and engineering productivity Engineering VP Josh Clemm on how we use knowledge graphs, MCP, and DSPy in Dash Inside the feature store powering real-time AI in Dropbox Dash Building the future: highlights from Dropbox’s 2025 summer intern class Fighting the forces of clock skew when syncing password payloads Introducing Focus, a new open source Gradle plugin Making camera uploads for Android faster and more reliable How Dropbox Replay keeps everyone in sync Why we built a custom Rust library for Capture Detecting memory leaks in Android applications How we sped up Dropbox Android app startup by 30% Why we chose Apache Superset as our data exploration platform Revamping the Android testing pipeline at Dropbox Our counterintuitive fix for Android path normalization JQuery to React: How we rewrote the HelloSign Editor How we ensure credible analytics on Dropbox mobile apps Engineering Dropbox Transfer: Making simple even simpler Speeding up a Git monorepo at Dropbox with <200 lines of code Building for reliability at HelloSign Store grand re-opening: loading Android data with coroutines Modernizing our Android build system: Part I, the planning Modernizing our Android build system: Part II, the execution Our journey to type checking 4 million lines of Python The (not so) hidden cost of sharing code between iOS and Android Redux with Code-Splitting and Type Checking The Programmer Mindset: Main Debug Loop On working with designers Incrementally migrating over one million lines of code from Python 2 to Python 3 Crash reporting in desktop Python applications What we learned at our first JS Guild Summit How we rolled out one of the largest Python 3 migrations ever Dropbox Paper: Emojis and Exformation Creating a culture of accessibility Adding IPv6 connectivity support to the Dropbox desktop client Accelerating Iteration Velocity on Dropbox’s Desktop Client, Part 2 Accelerating Iteration Velocity on Dropbox’s Desktop Client, Part 1 DropboxMacUpdate: Making automatic updates on macOS safer and more reliable Annotations on Document Previews Open Sourcing Pytest Tools Open Sourcing Zulip – a Dropbox Hack Week Project Building Carousel, Part III: Drawing Images on Screen The Tech Behind Dropbox’s New User Experience on Mobile (Part 2) Building Dropbox’s New User Experience for Mobile, Part 1 Building Carousel, Part II: Speeding Up the Data Model Building Carousel, Part I: How we made our networked mobile app feel fast and local Scaling MongoDB at Mailbox Welcome Guido! Dropbox dives into CoffeeScript Some love for JavaScript applications Plop: Low-overhead profiling for Python Using the Dropbox API from Haskell A Python Optimization Anecdote Translating Dropbox
How our universal content processing platform Riviera evolved for AI and beyond
Andrew Cheung · 2026-07-20 · via Dropbox Tech Blog

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.

It started with a preview problem

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.

A platform begins to emerge

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.

Dash changed the scale

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.

How reusable platforms create lasting value

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.