It's Never Been Easier toMove from Heroku to Render

taps mic

Hey, is this thing on?

It is? Fantastic. Anyway! Hi and hello—my name’s Ed and I’ve recently come onboard here at Render to help bring our developer advocacy and developer experience to the next level. So far that’s involved a lot of talking. But I keep saying I’m a software developer, and in the wake of Heroku ending their free tier we’ve had a ton of interest in bringing apps over to Render. So, after a day in the lab and some invaluable help from resident Render knower-of-things Dan Wendorf, I’m very pleased to let you know that migrating your applications from Heroku to Render is easier than ever.

Okay, great, I hear my hypothetical listener saying. How?

So we’ve had a Heroku importer, @renderinc/heroku-import for a little while now, and for a lot of happy Render customers it’s been very effective. It hasn’t worked for everyone, though, because of two major limitations:

• Our importer only worked with Heroku’s official buildpacks. No custom buildpacks.
• Our importer only worked with one buildpack per app. If your app needed Ruby and Node, or needed something like Elixir or even just jq, you were out of luck.

Emphasis on the past tense there, though, because @renderinc/heroku-import version 3.0.0 removes those limitations. When running heroku render:import against your application, we’ve clevered up the importer to handle both of these situations and now we help you produce a Dockerfile that’s able to capture the exact^† behavior of your application as it runs on Heroku.

The new process does you one extra solid too, though. When we’re gathering the necessary information from your Heroku account, we emit a .render-buildpacks.json file into your repository for you to check in alongside Dockerfile.render and render.yaml. This file’s not complicated, it looks like this:

{
  "buildpacks": [
    "https://github.com/opendoor-labs/heroku-buildpack-p7zip.git",
    "heroku/ruby",
    "heroku/nodejs"
  ]
}

The nice thing about having this file in your local repo is that now you can modify it. Which sounds obvious, right? But what .render-buildpacks.json does is give you a nice, gradual on-ramp to Render. Do you need a piece of functionality that you know mostly through its buildpack? Great! Add it to the list and when you push to your Git origin, Render will pick that one up, too. It’s the same behavior you’re used to with heroku buildpack:add, but it’s versioned and you can roll back through normal Git commands if you ever run into problems.

We don’t need to go on and on about this even further, though, because this is just about what’s changed, not what was great before. Here’s where to go for next steps:

• Our core migration guide covers, step-by-step, how to take heroku render:import and bring your application whole-cloth over to Render.
• If you’d like to see an in-action migration of an application from Render to Heroku, we’ve got them for Django and Rails; they aren’t using heroku render:import, so it’s a little more of the scenic route, but it’s a deeper dive if you’re so inclined.

If you’ve got questions, or you’d just like to share a success story, hit us up on Twitter. You can get the Render mothership @render or say hi to me personally @edropple. Now get to it—and thanks for using Render. I hope you go build something cool.

^† – Okay, the developer part of my brain wants me to qualify this, and it’s right. To the best of our knowledge, the importer duplicates the behavior of buildpacks running on Render. We’ve tried it on some fairly complex repositories and gotten the behavior we expected out of it. You might have an edge case we haven’t seen, though, and we can help you with that, too; our support team’s standing by at support@render.com to help however we can.