On April 25, 2026, we turned off the server that stood between our readers and every image we publish, rewrote 1,006 article images and 26 page images to point straight at storage, and cancelled the hosting bill for it, in one sitting. No reader noticed, which was the point.
This is the piece about images, which is the part of a publishing stack everyone underestimates until it breaks.
What we had
When we built the platform in March, the images went into object storage with permanent addresses, which was right. But we put a separate media server in front of that storage, hosted on its own service, to act as the library: uploads, thumbnails, a browsable catalogue. It was a reasonable choice in March. By April it was a second system to keep alive, on a second host, with its own login and its own failure modes, and every image address on every site ran through it. If it went down, every photograph on every publication went with it.
That is exactly the kind of dependency this series is about. We had built our own platform and then rented a piece of it back.
The decision
The alternative was to let the storage be the library. Every image already had a permanent address in storage; the media server was just a proxy in front of it. Remove the proxy, and the address on the page is the address of the file.
The one thing the proxy had given us was permissions: which publication could put what where. So the question became whether the storage layer itself could enforce that. We compared two options. A cheaper commodity bucket would have won on cost at scale and on portability. The storage attached to our own database won on one requirement I would not give up: per-publication write permission enforced by the storage itself, tied to the same user accounts the newsroom already has, not by an application sitting in front of it. If Strolling Ballantyne's editor can only write into Strolling Ballantyne's folder, that rule has to hold even if every application we write has a bug. Only one of the two could promise that, because its permissions and our newsroom's logins are the same system.
The day
A new storage bucket with permission rules per publication. A small upload function for the newsroom desk to use. Eighteen files changed across the site and the desk so that every place an image is rendered understands the new addresses. Then one database statement that rewrote 1,006 published articles and 26 pages from the old proxy addresses to direct storage addresses. Then a verification that every rewritten address served the right file. Then the proxy was shut down and its hosting cancelled.
Readers saw the same photographs on the same pages. The only visible change was that they loaded from one hop instead of two.
What I took from it
Two things. The first is that a media library is not a product you need to buy. It is a folder with rules, and if your database already knows who is allowed to do what, the rules belong there.
The second is more general and it recurs through this series: every piece of the stack we did not own turned out to be a piece we eventually had to replace, usually on a day we had not planned for. The media server was the first. The analytics vendor was the second. Each time, the replacement was smaller, cheaper and ours.
This is No. 03 in We Built Our Own. Previous: Two weeks in March. Next: Email we own.