How Storytel Moved 120 Publishers Off Self-Hosted SFTP Without Rebuilding Its Google Cloud Storage Pipeline

Storytel is one of the world's leading audiobook and e-book streaming services. From its headquarters in Stockholm, the company serves nearly 2.7 million subscribers under the Storytel, Mofibo, and Audiobooks.com brands, across ten core markets and more than fifteen others worldwide. Its catalog holds more than 1.8 million titles in over 55 languages, and the group owns publishing houses of its own, including Norstedts, the oldest publisher in Sweden. It operates across the whole storytelling value chain, from publishing through production to streaming.

That catalog does not appear by itself. Every title on the platform arrives as media files and metadata delivered by a publisher or aggregator, and the roughly 120 largest of those deliver in bulk: hundreds of gigabytes of audio a day, in batches that can run to a thousand books at a time. Publisher ingestion is the intake of the entire product. For years, it ran through a single SFTP server that Storytel built and operated itself.

Storytel ultimately moved those publishers one at a time to Files.com, kept the Google Cloud Storage pipeline behind them intact, and absorbed more than twice the daily transfer volume without adding servers.

The Whole Catalog Arrived Through a Server Storytel Ran Itself

The server was a self-hosted SFTP service on a Google Cloud VM, owned and operated by the Content Services engineering team. Publishers connected to it directly to upload audio and metadata, and from there files moved into the Google Cloud Storage buckets that feed the rest of the content pipeline.

By 2023, that server carried roughly 1,000 user accounts and took in hundreds of gigabytes of uploads on an average day. Every part of it was Storytel's to run: the VM, the SFTP software, the accounts, the upgrades. Keeping it current had become a standing drain on a team whose actual job was the content platform. Koen De Smedt, the Senior Engineering Manager who owned the workload, put it plainly when his team first approached Files.com:

“Today we have an internal SFTP server on a Google Cloud VM, but that solution is causing us headaches, so we want to get rid of it.”

Storytel was in the business of streaming stories, and it had ended up in the business of operating internet-facing transfer infrastructure. The two had nothing to do with each other, and the second was taxing the engineers responsible for the first.

Why 120 Publishers Couldn't Just Be Pointed Somewhere Else

More than a hundred external publishers had integrations aimed at the server, each running its own tooling on its own schedule, and none of them under Storytel's control. Any replacement had to meet them exactly where they were.

That set the requirements. The new intake had to speak plain SFTP, because that is what the publishers' systems already spoke. It had to keep every publisher walled off from every other. It had to absorb the real workload: around 200,000 files a month, with individual files as large as 8 GB. And it had to hand everything into the existing Google Cloud Storage buckets, because Storytel had no intention of rebuilding the pipeline behind them.

Storytel's IT Operations team had already been consolidating the company's scattered departmental FTP systems onto Files.com. The Content team decided the ingestion server should follow, and selected Files.com to be the managed, publisher-facing layer in front of its cloud storage. De Smedt described the scale of the use case:

“We use it to receive media files and metadata files from the 120 or so largest publishers that make books available on our content platform.”

A Folder Per Publisher, Swept Into Google Cloud Storage

Storytel stood up a dedicated ingestion site alongside its general-purpose company site. Each publisher received a folder and an account of its own. A publisher connected over SFTP with whatever client it already ran and saw only its own folder.

Behind the folders, Files.com's sync engine pushed everything into Google Cloud Storage and removed each file from Files.com once its transfer was confirmed. The buckets were the same ones the content pipeline had always read from, so nothing downstream changed. Files.com is not where Storytel's content lives; it is the front door the content walks through, and a file stays on it only as long as it takes to confirm it has landed in the bucket.

Cutover One Publisher at a Time, With Stronger Credentials at Every Step

Moving more than a hundred external counterparties is where projects like this usually stall, and Storytel treated the cutover as its own piece of engineering. The team began by sizing the real workload and found that of the roughly 1,000 accounts that had accumulated on the old server over the years, the live core came to about 130. It cleaned up the rest before moving anything.

Then it ran the two systems in parallel. A test environment came first, then internal accounts, then a handful of pilot publishers to validate the path end to end. Only after that did the cutover begin, publisher by publisher. Each move was small enough to schedule with the individual publisher, and each one doubled as a security upgrade: as an account moved, the team updated its connection details and imposed stronger password requirements than the old server had enforced.

There was no big-bang weekend and no synchronized change across a hundred companies Storytel does not control. Before summer 2024, all of the roughly 120 largest publishers were delivering through Files.com, and the self-hosted server was decommissioned.

Double the Daily Volume, and No Server Left to Patch

With the ingestion perimeter on Files.com, Storytel replaced a server its engineers had to keep alive with a service that runs without them.

• The self-hosted SFTP server is gone. Nobody at Storytel patches, upgrades, or operates publisher-facing transfer infrastructure anymore; the Content Services engineers work on the content platform instead.
• All of the roughly 120 largest publishers and aggregators deliver through Files.com, each in its own isolated folder, each on stronger credentials than the old server required.
• Content never lingers on the perimeter. Every file is swept into Google Cloud Storage and removed from Files.com the moment its transfer is confirmed, and the pipeline behind the buckets was never touched.
• Growth stopped being an infrastructure problem. A single publisher uploading a thousand books in one batch is within normal range, and by late 2025 typical daily transfer had risen from under 1 TB to more than 2 TB. Absorbing that took no new servers and no project.

The Content Team Works on the Content Platform

The lesson in Storytel's migration is that retiring the old server never required a leap. It was replaced one publisher at a time, on a schedule Storytel controlled, with credentials tightened at every step, and the Google Cloud Storage pipeline behind it never noticed the change. Files.com became the front door of the catalog. Everything behind the door stayed exactly where it was.