Hosting A Site At Heroku With Email at Site5 (or any other mail provider probably)

My wife’s non-profit theater website, Cry Havoc Theater was created by moi after we had a temporary dalliance with WordPress. We bought a really nice template but couldn’t figure out how to make it work well with her logos. So I built a site on sunday using Rails and Bootstrap. I hosted it on Heroku using Amazon Route 53 DNS which is my standard now that Zerigo has started charging a lot more money. This costs me about $1.11 a month per site.

The kicker to this story is that I had never bothered to set up email on The Sports Pool Hub because I just use a non-branded Gmail account (and no one has ever signed up so it’s a moot point anyway). Because we’d originally created and hosted the site at Site5 (which I totally and whole-heartedly recommend by the way for any WordPress hosting you might want to do), I had originally set up her webmail there. When she tried to log in the other day after I’d moved to Heroku, that clearly didn’t work anymore.

After spending a little time googling and thinking about the solution, I learned about MX records and I figured I could still host the mail at Site5 while the host was at Heroku. Unfortunately, there was precious little documentation on how to do that. The fantastic support team at Site5 were quick to respond to my request and after 10 minutes of configuration, I had mail back up and running at Site5. This is a reminder/tutorial for anyone else out there wanting to do the same thing. You will need the mail subdomain from your host (ours was but yours may be different). You will also need the IP address for the domain.

In your AWS Dashboard, go to Route 53. Click on Hosted Zones and then go to the recordset for the zone/domain that you want to route email for. Create an A record for the mail subdomain with a value of the IP address that you received from your host. Site5 told me to set the TIL to 1 hour so feel free to choose that. Save the record.

Then create an MX record with the same Name as the A record you just created. I made the TIL the same as the A record and set the Value to “10”. This sets the priority the routing goes through. With only 1 option, 1 would have been fine but most of the examples I’d seen chose 10 for later flexibility. Save the record set.

Then at Site5 (or wherever the email hosting is happening), in SiteAdmin, you need to edit the MX record for the domain in question. It was originally set up as a root domain, It needs to be whatever the mail subdomain was from steps 1 and 2 above. In this case, After propagation, which in our case was immediate, pinging your mail subdomain should result in the IP address provided by your mail provider. You can then go to /webmail and login.

The hardest part as with anything new is just figuring out the details. The implementation was pretty straightforward.

Web Deployment Cage Fight – 2002 versus 2011

When I first started doing web development with Visual Studio 2005, it was pretty painful work. Not only was the development itself difficult in many ways (if I say “typed DataSet” and “bloodthirsty bedbugs”, which makes you cringe more?) but the deployment of sites was often a long, tedious manual process for a site of any size. I distinctly remember having to log into my hosting provider, upload a zip file or collection of files, manually unzip or move them around and then hope that everything and the stars were lined up properly. Microsoft tried to make things easier with the Publish technology from Visual Studio but that never worked particularly seamlessly, at least not in my limited experience. On top of all that, it required considerable discipline (and a kickass source control which I’m not sure existed) if you wanted to deploy certain changes but not others.

Take a quantum leap forward into 2011. Over the last 3.5 days, I built a website to serve as my central home on the web, a place where I can aggregate my work, writing and other activities easily. I built the site in Rails, used git for source control and when it came time to deploy the site, Heroku for the hosting. To deploy my site, I had to do to things: [sourcecode language=”bash”]heroku create[/sourcecode] and [sourcecode]git push heroku master[/sourcecode] When that was done, I had a live, working test site on the internet that I could test in multiple browsers, get feedback on, etc. When I was ready to redirect my current home on the web to the new one, all I had to do was add a custom domain and Zerigo DNS add-on at Heroku, update my nameservers and presto chango, the production site was up and running.

On top of that, because branches are so painless and easy in git, I can create a new branch, work on it, merge it with the master and update the site all from the command line of my laptop. The idea of having to log into a hosting provider to upload files suddenly feels like waterboarding. If you have a significant test suite, it’s a matter of having your tests pass and then just updating your production site. Obviously, as a site grows, it won’t be quite that easy but it’s not going to get that much harder either.

The smart folks at Heroku have removed some of the major obstacles to web development so we can focus more on writing the code now and less on the administrative agony. On top of all that, for small sites like mine, the cost is negligible or non-existent. Lots of things aren’t better in 2011 than they were in 2002 (the world’s going to end next year) but web deployment, if you choose the right tools, is infinitely better in a way that’s almost inexpressible.