November 26, 2022 Log No. 1075

Migrating from Heroku

Yes, I do still do site-related things (sometimes) in my free time. And Heroku kinda forced my hand by announcing they were sunsetting their “Free Tier” at the end of November 2022. (This month! The upcoming Monday 11/28, to be exact.) Leading to me having to evaluate if it was worth the trouble of figuring out a new home for my 2 sites where I am still a dedicated (and lonesome) visitor, Cocktailist and Repost Repo.

Of course, since I’m a hoarder by nature, I didn’t want to throw them away. The next step: how to move them. Thankfully I started planning this early on–pretty much right when they announced it, in August–because this took some work that I did over several weekends:

Hosting Service

I had to decide between Heroku’s paid plan, AWS, or Dreamhost. Of course there are other hosting services, but these were the hosting options I was already familiar with so may as well start there. (Dreamhost is the old-school hosting service that I registered with back in 2006 and for whatever reason have never moved away from. And I’m a little surprised–but no complaints!–that it seems to still be going.)

After doing the math, it seemed like it would cost about $20+/month on both Heroku and AWS to run the 2 sites, each needing 1 database. Plus on AWS I would need to set up pretty much everything from scratch on the machine. (Well, I could run a pre-built Docker image but still, that’s set-up required.) Heroku would be an easy upgrade path but it was the most expensive, both now and with scaling for possibly new apps in the future.

Meanwhile on Dreamhost, I was less familiar with the access and resources they provided for Rails–I’d only been using it for simple PHP apps and WordPress til now–but they seemed to be able to run Rails on their “Dedicated” plan and supported unlimited (to my knowledge) DBs, at $13.75/month. And as I mentioned, I already had a site hosted there so it would be nice to consolidate my online assets in one place. So Dreamhost it was.

PostgreSQL to MySQL

But a major difference with Dreamhost is that they only support MySQL, not PostgreSQL which is what both sites were currently using. Not the HUGEST difference but still different SQL DBs. After upgrading my Dreamhost account to a Dedicated plan, I spent my first weekend of the migration exporting my Heroku DBs, then fumbling through some dodgy converter tools, StackOverflow (of course), and MySQL commands to import the data locally. After confirming the data looked legit, I imported them to new MySQL DBs on Dreamhost.

Running the Rails apps on Dreamhost

Now time to actually see if I can get the Rails apps running on my Dreamhost server. They had some decent articles on it; apparently Passenger (which I’d never heard of before, but I guess it helps run apps) and RVM are pre-installed on all machines so all I had to do was update my config to point to where RVM was for Rails to be enabled. A quick SSH and upload of my files, a prod asset pre-compile, a touch tmp/restart.txt (this one was a bit odd but apparently the timestamp of this file is how Passenger knows to reboot the app) and ta-da, it works!

Ah and of course I had to update my app config to point to the new DB servers and figure out how to do secrets management now that the secrets weren’t being injected via the Heroku build pipeline.

At this point technically both apps were migrated off of Heroku and functional, though some bells-and-whistles were missing. But good to have MVP ready to go with more than a month to spare til the deadline! That never happens on the job, haha.

Updating CNAMEs

Now everything was running at subdomains for, but I wanted Cocktailist to be at like it was before. This really should not have taken as long as it did (a weekend, heh), but my network registration stuff was always pretty rusty. (Is it “rusty” if it never gets “un-rusty”? Maybe just “bad.”) It took a few tries before I realized that I had to configure my Namecheap domain registration to point to the Dreamhost nameservers, then host a domain called “” in my Dreamhost account. (And move all my cocktailist assets over there, of course.) I initially thought that the DNS entry had to point to for whatever reason.

Fixing search: pgsearch to Sunspot

This one I JUST did over Thanksgiving week. Switching from PostgreSQL to MySQL unfortunately also broke the site search on Cocktailist, because that used the pg_search gem (which, unsurprisingly, relies on PostgreSQL’s innate full text search functionality). So I had to investigate and implement a new Rails search solution that worked with MySQL. Always fun when you barely know the Rails ecosystem anymore, can barely write Ruby, and don’t really remember the architecture (if it can be called that) of your site.

The Solr Sunspot search gem seemed easy to set up and the implementation seemed pretty 1-to-1 with how pg-search worked, so went with that. The setup was actually very straightforward and somewhat well-documented, so the real struggle for me was trying to figure out how my app worked so I could refactor the search functionality to use the sunspot response, haha. I think I’ve distilled it to this:

backbone.fetch -> API -> json jbuilder -> backbone.collection.parse -> backbone view

…after many debugging hours locally. Also after many sighs of disgust at the code I wrote 7 yrs ago. (I think I have 3 files named “search” in my app code. Not confusing at all.) I think this is the first “data flow” diagram in existence for Cocktailist, which should help until I can finally finish the revamp.

Another clumsy prod “deploy” later and Cocktailist is back to 100% feature parity with the Heroku version!

Repost Repo is still missing the “Swap Colors” feature (which was added in this post: Repost Repository), which I suspect may be due to the move to https, but otherwise works.

It was quite the journey; glad I didn’t procrastinate. I think I value being a visitor (the sole one) to these sites more now, knowing all the recent work that went into them. Definitely more MySQL/Rails exposure than I’ve gotten in a very long time. (Unfortunately can’t say the same for Backbone… >.>)

Leave a Reply

Your email address will not be published. Required fields are marked *