Hi folks, it has been a little time since my last post, I was thinking about what could be a nice topic to cover here, but some recent issues have made my mind to write a short post, not even a complete tutorial, almost a mental note but not only mental anymore.

I was testing my local environment to deploy an app in Rails (version 7, in this case).

Honestly, I guess this is the second time I have crossed the same problems. Well, not Rails problems per se, I’m kinda new to this but I’ve found it amazing for prototyping. Issues are more related to the lack of general experience with the toolset, so I’ll make a step-by-step guide here of what happened.

The following steps were replicated on the server, from the beginning to the final command to get the app started. I’m also assuming that you already have a Rails installation configured.

Well, first of all I took the simplest steps I could remember, from a terminal:

git clone <project-url>   # or pull, if the repo is already configured
cd <project-dir>

bundle install

rails assets:precompile

Now, let’s try to run it for the first time, as a quick check:

RAILS_ENV=production rails s

It worked! But wait, the CSS is not loading anymore… oh, I see, Javascript also not working… Uhm, something wrong is not alright, right? Let’s check.

With a quick search on the web, I remembered of a small snippet of configuration lacking in the production.rb file:

config.serve_static_files.enable = true

You can safely disable this if you’re running behind another server as a proxy, like Nginx or Haproxy, but as I was testing locally it must be enabled.

But no Javascript working as well. In fact, only a file that wasn’t loading. There’s something extra you’ll need if you have a custom library of plain JS.

For example, if you have a script called index.jsinside the dateutils folder:

app/
└── javascript/
   ├── application.js
   └── dateutils/
      └── index.js
config/
└── importmap.rb

Then we can simply “pin” it in the importmap.rb file:

# config/importmap.rb
pin "dateutils/index"

# alternatively, if you have more files inside dateutils/
pin_all_from "app/javascript/dateutils", under: "dateutils"

Now your code is ready to be imported anywhere else:

// app/javascript/application.js
import "dateutils/index"

There’s something important to mention, that is the Rails credentials file and how to configure different files according to the enviroment.

This is not clear in the “getting started” guide, so you’ll have to figure out by yourself the best way to deal with these files.

Normally, we can just use the default method for editing secrets in the credentials file, using:

EDITOR=vim rails credentials:edit

But, if you need different secrets/keys and any other configuration by environment, you should use the --environment option:

EDITOR=vim rails credentials:edit --environment=development

This command will generate another file in the config/credentialsfolder, named development.yml.enc. Neat, huh?

Therefore you can safely configure the default credentials file in config/credentials.yml.enc, because it is the fallback when no environment is provided (or if you’re in production).

Remember, the master.keyfile stores the secrets used to encrypt the credentials file; it’s added to .gitignore, so you’ll need to upload it separately to your server in order to access the credentials files (you can copy it with scp or even copy & paste using vim or nano).

I’ve found more valuable information about this in this post.

Last but not least, don’t forget to create your database and run the migrations:

RAILS_ENV=production rails db:setup && rails db:migrate

Now if you just run your app with rails s, the process will stop if you quit the ssh session on your server. This is easily fixed by using the flag -d(daemon process). Therefore, the complete command for running your instance is:

RAILS_ENV=production rails s -d &

And it’s done! Now you’ll be able to leave the SSH session without stopping the app.

I think this is okay for now. There isn’t much more to add at the moment. It’s enough for a small troubleshooting session that I hope will help someone else.

If you’re stuck with something related to this article, don’t hesitate to send me a message, I’ll see how I could assist you.

See you next time!