Rogue Amoeba - Under the Microscope " Blog Archive " The Sleep-Promoting Resilience of Boring Infrastructure
Strange name.<br>Great software.
Apps
Airfoil
Audio Hijack
Farrago
Fission
Loopback
Piezo
Soundsource
Store
Support
Company
Blog
← Previous
-->
The Sleep-Promoting Resilience of Boring Infrastructure
“Legacy” doesn’t have to be a bad word.
Posted By Lee Falin on August 19th, 2026
In last month’s post on incremental improvements, I highlighted some recent user-facing updates we’ve made here at Rogue Amoeba. Today, I’d like to share some details on the backend systems that have kept the company running strong for nearly a quarter of a century.
Measured against current development trends, Rogue Amoeba takes a very conservative approach to infrastructure. You might guess this is because we’re not a web app company, so we don’t have to think about infrastructure at scale. While there is a measure of truth to that, our infrastructure codebase is actually nearly double the size of the codebase for our commercial products. That infrastructure powers a wealth of systems, including our online store, Customer Dashboard, software updates, and Support Center.
Because of the importance of those systems, we’ve long avoided adopting untested technologies and complex architectures. A few weeks ago, while discussing the fact that one of our most recent rollouts found us “updating” to a 30-year-old technology, I jokingly asked our CTO Quentin, “What’s the opposite of being on the bleeding edge?” His response echoes one of the core tenets of our infrastructure philosophy:
“Being resilient.”
In our infrastructure planning, we regularly ask how we can make things less complicated, easier to maintain, and more resilient. When we make a change, ensuring our customers can access our site, download and purchase our software, and get the support they need is top of mind.
At a past job working in real-time transaction processing for a major fintech, I received the advice to deploy systems that won’t keep you up at night. That’s what we do at Rogue Amoeba. Most of our infrastructure decisions focus on decades-old, battle-tested technologies. Further, whenever we do update a dependency or migrate tech, those changes are rolled out slowly and deliberately.
And so, here are two recent examples of sleep-promoting systems we’ve deployed atop "boring" tech stacks:
FastCGI Migration
After we enhanced our software update system to show richer release notes, we noticed the changes were putting a relatively high strain on our server. That led us to take a hard look at some of the most legacy of our legacy systems, our CGI scripts. Over the years, we built these to handle things like update notifications, in-app support requests, and order fulfillment. With the Python foundation recently having removed the cgi library1, we decided it was time to start looking at other options.
There are many modern tech stacks we could have chosen to migrate these systems to, including AWS Lambda, Google Cloud Functions, and Cloudflare Workers. But instead, we asked, “What’s the simplest thing we can do to make these scripts significantly more performant?” That question was answered about 30 years ago, with the development of FastCGI.
After some initial testing and experimentation, we migrated all of our CGI scripts to FastCGI relatively easily. The performance improvement was notable, making it clear that “FastCGI” is named well:
This graph compares four performance metrics for one of our most heavily utilized APIs, across both the old CGI stack and the new FastCGI stack. "Mean" represents the average response time of all requests, and while that improved significantly, the worst-case scenarios are especially striking. To measure those, we used the common P90/P95/P99 SLA metrics.2, which say “90%/95%/99% of requests are handled faster than this.”
As you can see above, all three of those worst-case scenarios improved significantly under FastCGI. Could AWS Lambda have gotten us down to single-digit response times? Maybe. Would it have exponentially increased our infrastructure complexity and cost? Definitely. For us, that trade-off wasn’t worth it.
SQLite Migration
Another recent migration involved transitioning our primary order database from MySQL to SQLite. Folks who know about databases might think I wrote that backwards, but no.
Industry thinking around databases has shifted quite a bit over the years. By the early 2000s, MySQL and PostgreSQL had become the standard databases used in web development. That was followed by a brief surge of “NoSQL” advocacy that warned “you’d better be ready for big data.” As a result, many people migrated to systems like Mongo and Cassandra.
I have a good amount of experience with big data, having worked for both a major bioinformatics research institute that dealt with petabytes of genetic data3 and a fraud-analytics company that had to process billions of rows of transactional...