Well, sort of. As far as listeners are concerned, you probably haven’t noticed any change at all, which means we did a super good job on this move. What we did was change our hosting provider for episode storage, and we wanted to explain why.
Since we’re a web development podcast, I thought it would be helpful to provide some background information on this move for others who might be interested in a more DIY solution for a podcast or any other type of media hosting. It’s not as big and scary as you might think, and you end up with a lot more control over your data as a result.
Why Self-Host?
Let me start with a brief overview of why we went self-hosted in the first place. After all, there are plenty of very good services out there that offer great platforms like Libsyn, Podbean, Blubrry, and others for hosting podcast episodes. While these platforms are a fantastic choice for non-technical content creators, they don’t do anything you can’t do on your own. What you are really paying for with them is less the actual storage piece of the puzzle, and more for the additional features they provide, like analytics and distribution.
In our case, we already solve our analytics with a multilayered approach. Internally, we use Seriously Simple Stats, which feeds into Google Analytics. We also utilize Chartable and proxy our show links through Podtrac. With all that coverage, we actually get really good information about how our show is consumed. (For what it’s worth, I may end up swapping out Podtrac for Chartable completely down the road, as it appears they have a product that’s more useful, and blends other sources into the mix.)
As for distribution, this task isn’t so much hard as it is time consuming. Most of the big podcast hosting services have direct pipelines to submitting shows to services like Apple, Google, Spotify, Stitcher, etc. Don’t get me wrong, that’s incredibly useful, and probably worth a good part of the value you pay for. But most platforms do let you submit your own RSS feed. By utilizing WordPress, we automatically create our own feed without the need for a service. Generally, a Google search for “submit podcast to [Platform Name]” will give you a relatively quick answer.
And so it was for me, when we launched The Drunken UX Podcast. Libsyn’s basic package is $15 (yes, they have a cheaper plan, but it’s not very robust for most purposes, more of a taste-test sort of option), which was $15 I knew I could save. AWS offers their Free Tier for 12 months on many of their common services. That gave me 5GB of space on S3 object storage and 50GB of outbound CDN bandwidth on Cloudfront for free.
For the cost of a few hours of my own labor, I was able to save $15/month or so by not using a service, and doing it myself.
The Problem
Well, recently, 12 months came up, which meant my access to the AWS Free Tier was going to expire. On top of that, for the last few months we’ve been exceeding the 50GB of free bandwidth on our Cloudfront CDN too. Not by much, but it would begin to add up once we were off the free tier.
This is actually pretty simple. I still want to keep costs down, and while AWS S3 and Cloudfront are cheap services, metered bandwidth can make your costs unpredictable. Having an episode featured somewhere might cause a traffic surge that would prove costly. As a side note, this is another reason the managed service providers for podcasts are good, they protect against that if you don’t want to have to worry about such things.
The storage side was relatively cheap, and after a year and a half of producing The Drunken UX Podcast, we’ve generated roughly 3GB in audio. So this is obviously less of a concern than the cost of sending that data to our listeners.
To quantify this, off the AWS Free Tier, our current hosting costs for storage and bandwidth based on our existing traffic would be about $5.18. Obviously super cheap still, but we’re prone to spikes, and it will only grow from here as we store more files and serve ever more data. This time next year we could very realistically be pushing $10 or $15 a month. I wanted to avoid that risk.
The Solution
As my year of the AWS Free Tier came up, I started looking at other options. We already host the website for Drunken UX on a server I manage on Digital Ocean. For some time now, DO has offered an object storage service called Spaces. But until recently, it lacked certain piece of specific functionality I needed. That lack – custom domains – was addressed in the last few months, which meant it was back on to my short list.
The cost problem that Spaces solved for me is a simple one. It’s $5/month for 250GB of storage and 1TB of outbound bandwidth straight up (in this way, it’s functionally equivalent to S3 style object storage, but it’s billed more like block storage). Both of these caps are far and away more than we need. Our storage needs are very predictable, and our bandwidth would have to grow by a factor of about 18 to break the 1TB cap. The result is that I’m still spending less than using a podcast hosting service, less than I would at AWS, and now I have much more room to grow with no risk of increased costs for the foreseeable future. Not that I wouldn’t welcome the kind of growth that would require 1TB of bandwidth, that’d be a pretty cool problem to have, too.
Additionally, remember when I mentioned I needed custom domain functionality? That’s because we host our episodes on one – episodes.drunkenux.com. I did this intentionally to protect us in the event of exactly this kind of move. At the start of this article, I said that you shouldn’t have noticed any outage of our hosting. That because I already had this domain pointed at our Cloudfront CDN on AWS. All I had to do was copy my data off S3 wholesale, and upload it to Spaces using the same path structure. Since I already maintain backups of this data, that task is relatively trivial and can be done through Digital Ocean’s web GUI for Spaces. After that was done, a simple DNS update to change the CNAME destination of our custom domain ensured users would be routed to my new host, with everything exactly where it was before.
Isn’t object storage cool?
Secondarily, this also reduced the number of billable services I needed from two, to one. On AWS, I had to use both S3 for storage, and point Cloudfront at that for a CDN (the CDN isn’t strictly necessary, mind you, but it’s cheaper to serve data that way than straight out of S3). On Digital Ocean, it’s CDN is integrated into Spaces already, and it’s just a setting you turn on or off based on what you need.
Conclusions
First, if you want to know more about block storage, object storage, CDNs, and how they work, we recorded an episode on that you can check out. It’s a good starting point if this idea is appealing to you, but you’re not totally clear on all the technology just yet. Even if you’re just passingly curious, check it out.
Don’t get me wrong, this approach isn’t for everyone, and I wouldn’t suggest you go into it blindly. It can be incredibly satisfying though, if you have a DIY mindset, and like the idea of realizing some cost savings for your podcast. It’s not that it’s especially hard, but you just have to have the time and wherewithal to roll your sleeves up and dig in.
I happen to like being in control of the destiny of our data. Our own object storage with our own CDN subdomain means I’m not tied down. I can be flexible if the passage of time warrants a new strategy, and it doesn’t leave me wondering about updating episode URLs in the feed and hoping that gets out to everyone without messing up tracking.
If you want to try out Digital Ocean, use the link here for it and our referral code will get you a $50 credit for your first month, which is a great way to try it out. Fair disclosure, that obviously gives us a modest kick back, too. Either way, my plug is my own on this, and isn’t a sponsored message or paid commercial here. I just really like the service and have found it easy to use.