Heroku recieved some negative press for the removal of it’s free tier. Render is a cheaper alternative that boasts many benefits over Heroku. We believe Heroku is still the quickest way to spin up a Rails app but Render is close behind and less than half the price.
Now we’ll explain how to deploy a Rails app on Render. First you’ll need an account, head over to Render and create one. To run a Rails app, we need two things: A server and a database. We’ll focus on the server first. Hit the New button and select Web Service. On the next screen we can choose a GitHub repo, which is a nice way to quickly deploy an application.
Next, we need to complete some simple information about our app:
- Name - the name of the application. This is just used inside Render’s admin
- Region - the region where the webservice will run
- Branch - the branch Render uses to run the application code. This is useful for migrating to Render. For example, we could make a feature branch to test Render, before merging to master.
- Environment - the run time environment. In this case we’ll choose Ruby. When we select this, two new fields appear: Build Command and Start Command
- Build Command - the command that gets run on new deploys. For now we’ll use
- Start Command - the command used to start the webserver. We’re using Puma so we can keep the Render default.
- Instance type - the free tier is fine for this tutorial
Next, hit Create Web Service. This will start the first build. The build wont pass yet but should at least clone the repo and run bundler.
Some versions of Rails require a
SECRET_KEY_BASE environment variable. We can specify that under the Environment tab, in the app’s build screen. Render has a key generation tool, which works great for this purpose.
The next step is to setup a database. Render only supports a few database technologies: Postgres and Redis. We’ll use Postgres for this tutorial.
Hit, the New button and select a Postgres database. Choose a name, region and instance type (Free is fine for now). The name is not important but we advise matching the webservice and DB name.
Connect database to web service
We now have a webservice and database in the cloud but they’re not connected. To do that we need to add the database url to the webservice. Navigate to the database and scroll down on the Info page to copy the Internal Database URL.
Jump back to the webservice and find the Environment tab. Create a new environment variable
DATABASE_URL using the value of Internal Database URL.
Lastly, find the Settings tab and update the Build Command to
bundle install; bin/rails db:migrate so that migrations run with every deploy.
Next, we’ll cover cron jobs. Most Rails apps have some recurring tasks that are handled with cron. To create one in Render, click the New button and choose Cron Job. Because we’re new to Render, we need to provide our billing information at this point. That’s because this feature doesn’t have a free tier (don’t worry, they’re easy to control). Then we can select our repo, which will take us to the setup page.
We’ll need to complete the following information:
- Name - the name of the Cron Job, which is just used inside Render’s admin. Make it something easy to remember.
- Region - the region where the Cron Job will run.
- Build Command - the command that runs on new deploys, we can use
- Schedule - configure when the Cron Job should run. Eg:
*/5 * * * *to run it every 5 minutes
- Command - the command used to run the Cron Job. Eg:
- Instance Type - Starter is fine for now.
Hit Create Cron Job to complete setup. We can suspend the job to prevent it running until it’s ready. Lastly, we need to add
DATABASE_URL to the Environment settings of the Cron Job, just as we did for the webservice.
Lastly, we want a custom domain for our Rails app. Render makes this simple. Navigate to your Web Service, go to Settings and find the Custom Domains section. Add your domain and then add the required CNAME and ANAME record. Render provides instructions for various DNS providers.