How to Deploy an API-Only Ruby on Rails Application to Render | by David Vera Castillo | Nov, 2022

an alternative to heroku

photo by Martin Sanchez Feather unsplash

Since Heroku’s free tier is no longer available, you’ll need to consider deploying your application to other providers that allow you to do this free.

Heroku’s processes are really straightforward when deploying a RoR app, whether full stack or API only, and if you can afford the monthly fee I’d say it’s worth it.

However, for developers just starting out in their careers, like me, there are other services that still have free tiers for deploying RoR applications, if you know that they each have their own specific configuration. One such service is Render.com and while this article aims to show the process for deploying an API-only application, the process for deploying a full-stack application has already been explained about Render.com. Documentation,

Set up your repository with PostgreSQL

Ruby on Rails comes with SQLite3 configured by default so you will need to have PostgreSQL installed in your application.

If you are creating a new project from scratch you should use:

rails new mysite --database=postgresql

If you are deploying an existing repository, you need to make sure that in your Gemfile the line:

gem 'sqlite3'

is replaced by:

gem 'pg'

Then, to install the dependencies you need to run:

bundle install

You should push your changes to GitHub, as render allows you to deploy whenever the configured branch is pushed.

Note: If your project is deployed to a different service and you think the following configuration may conflict with it, consider creating a separate branch.

Finally, you need to check config/database.yml file contains postgresql In the Adapter Defaults section, as follows:

default: &default
adapter: postgresql
encoding: unicode
# For details on connection pooling, see Rails configuration guide
# https://guides.rubyonrails.org/configuring.html#database-pooling
pool: <%= ENV.fetch("RAILS_MAX_THREADS") 5 %>

And in the output section, usually at the end of the file, you need to change the default values:

production:
<<: *default
database: mysite_production
username: mysite
password: <%= ENV['MYSITE_DATABASE_PASSWORD'] %>

In the following configuration, so you can include the DATABASE_URL environment variable:

production:
<<: *default
url: <%= ENV['DATABASE_URL'] %>

modify project configuration

Open config/puma.rb and uncomment the workers line and preload_app Line:

 Puma can serve each request in a thread from an internal thread pool.
# The `threads` method setting takes two numbers: a minimum and maximum.
# Any libraries that use thread pools should be configured to match
# the maximum value specified for Puma. Default is set to 5 threads for minimum
# and maximum; this matches the default thread size of Active Record.
#
max_threads_count = ENV.fetch("RAILS_MAX_THREADS") 5
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") max_threads_count
threads min_threads_count, max_threads_count

# Specifies the `port` that Puma will listen on to receive requests; default is 3000.
#
port ENV.fetch("PORT") 3000

# Specifies the `environment` that Puma will run in.
#
environment ENV.fetch("RAILS_ENV") "development"

# Specifies the `pidfile` that Puma will use.
pidfile ENV.fetch("PIDFILE") "tmp/pids/server.pid"

# Specifies the number of `workers` to boot in clustered mode.
# Workers are forked web server processes. If using threads and workers together
# the concurrency of the application would be max `threads` * `workers`.
# Workers do not work on JRuby or Windows (both of which do not support
# processes).
#
workers ENV.fetch("WEB_CONCURRENCY") 4

# Use the `preload_app!` method when specifying a `workers` number.
# This directive tells Puma to first boot the application and load code
# before forking the application. This takes advantage of Copy On Write
# process behavior so workers use less memory.
#
preload_app!

# Allow puma to be restarted by `rails restart` command.
plugin :tmp_restart

Open open/environments/production.rb and find the following line:

# Disable serving static files from the `/public` folder by default since
# Apache or NGINX already handles this.
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?

and then append RENDER The variables are as follows:

# Disable serving static files from the `/public` folder by default since
# Apache or NGINX already handles this.
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present? || ENV['RENDER'].present?

Create a PostgreSQL database

Render allows users to create a PostgreSQL database that lasts for 90 days in the free tier. You can always make a new one when the old one expires. The process to create one is as follows:

  1. log in render dot com Or create a new account if you haven’t already. You can use your GitHub account to allow your repository to be deployed on push.
  2. Click on the New button in the navbar and select the PostgreSQL option:
  3. Choose a name and a region. You can also customize the database name, user, and version if needed.
  4. Select Free plan type and click on Create Database
  5. Wait for the newly created database to be deployed, then copy it internal database URL And save it for later.

create a build script

Now, we need to create a build script. This script differs from the instructions found in the render docs when deploying an API-only application, and can cause a lot of headache. For API-only applications, you need to create a file called bin/render-build.sh and paste the following:

#!/usr/bin/env bash
# exit on error
set -o errexit

bundle install
bundle exec rake db:migrate

If you want to load seed values ​​for your database you should add the following line at the end of the file:

bundle exec rake db:seed

Next, make sure the script is executable by running the following command in the console:

chmod a+x bin/render-build.sh

Then, push the changes and you are ready to deploy.

create a web service

Now you can create Web Service in Render by clicking on New >> Web Service.

In the next window, configure your GitHub account if you haven’t. Then, you can choose the repository you want to deploy to. Find it and click Connect.

Later, if you don’t want to deploy to the default GitHub branch, you can configure a specific name, region, and branch that you want to deploy to.

important:

Make sure the environment is set to Ruby. Make sure to clear the Build Command and set it to:

./bin/render-build.sh

which calls the script created earlier. Also, clear the start command and set it to:

bundle exec puma -C config/puma.rb

You should have your configuration as follows:

Next, you can check the plan type and make sure it is set to Free. Then, you should click on the Advanced button.

Now you need to add all the environment variables required for your application. There are two mandatory variables:

DATABASE_URL => The internal database URL that you saved above form you PostgreSQL service
RAILS_MASTER_KEY => Paste contents of the config/master.key file

Finally, you can click on Create Web Service, and you can check the progress of the deployment. I suggest you check the logs to make sure everything is working properly. If you have followed these steps your application should be successfully deployed.

This Post Has One Comment

Leave a Reply