When do I need to restart server in Rails?

I have noticed that when I change rails project files such as a html.erb or .css, I don't have to restart the server with the rails -s command.

But I think when I want to install a new gem I have to. The thing is that I'm trying to get jQuery to work, so i'm tired of doing rails -s all the time.

Can anyone tell me when do I have to run rails -s again when I'm modifying my app and when can I afford NOT to do it? By not doing it, I mean simply refreshing the webpage to see the changes.

2021 UPDATE:

Since this answer is my most visible answer on StackOverflow and it's quite old, I thought it was about time to update it to go a little more in-depth. It's original info is not incorrect, but it's a bit too generic, and I feel I can explain it better with the knowledge I have now. The original answer is preserved below.

The way Rails works vs plain ruby is that it basically requires your files on-the-fly without you needing to add requires on the top of the file. There is nowadays a good relatively in-depth page about it on the official Rails guides here.

Starting on Rails 6, they introduced a new loader to manage the logic for automatically loading the source files, off-loading that work to a gem called zeitwerk. There is also a page on the Rails guides that explains how the new loader works.

The basic idea is something like this:

1. Rails runs a bunch of config files (environment.rb, application.rb, boot.rb, the respective environments/<environment>.rb, config/routes.rb, initializers, etc). All the files ran in this starting phase are in the config directory, so if the changed file is inside the config directory, it probably will need a Rails restart.

2. Rails then starts watching all the files under each of it's autoload_paths (by default each dir inside app) to check when any of them change. It also specifically watches for changes on the config/routes.rb file.

3. Now armed with a nice route configuration, Rails knows to which paths to respond and with which controllers. Once you hit one of the configured routes, Rails will run your controller action.

4. Whenever ruby sees a constant that it doesn't recognize, it calls the method const_missing. Rails overrides this method to get the name of your constant and use it to search for a file with the same name inside each directory of the autoload_paths.

5. When it finds the file it then requires it on-the-fly, with the assumption that it will define the constant that triggered the const_missing, and then the code goes on.

6. Next time the same constant is used, it will now be defined, so it won't even reach the const_missing method.

7. Last but not least, IF the config cache_classes is set to false (the default on the development environment), then whenever Rails catches a change in one of the files it's watching, it will unset the constant associated with the file (that it knows from the name of the file).

So whenever you need to change anything that is loaded in that step 1, with the exception of the specially treated config/routes.rb, you need to restart Rails. Anything else, Rails will reload by that autoload mechanism unless it's set to cache the result.

In production it is also configured by default to preload the classes, so it will load all the classes before even starting the server. That's to avoid the overhead of the whole const_missing, file searching and dynamic require thing.

Non-ruby files, like assets and views are all read by Rails at the time of request, so you can always change them without restarting Rails. (Note: on production assets are usually pre-compiled, so changing the assets inside app/assets won't result in any change. But it is still loading at the time of request, it's just that the file in question is a compiled bundle inside the public directory).

Original answer:

You need to restart you server when you need Rails to be loaded again from the start.

If you're adding or removing gems, then yes, you will need to restart the server.

If you change your version of ruby, change your Gemfile or change something from internal classes of Rails, you will need to restart it, otherwise it should be ok. But if unexpected problems arise, restart the server is the first thing you should try.

Also, on a side-note, you will only see the changes just refreshing the page if config.cache_classes is set to false (which I think is the default for development, but not for production).

Edit:

Just to make sure everyone will notice, tadman said one wise thing at the comments, The general rule of thumb here is making changes to anything outside of app/ or config/routes.rb or db/ will require a restart.

In development you need to restart when:

• You add/remove/update gems in your Gemfile.
• You make some other change to the ruby environment, perhaps via rvm.
• You change any files under config/, although routes.rb is reloaded for you.
• You change any files that you require manually, rather than autoloading.

In production you need to restart when:

• You change any code or gems.

N.B. These behaviours can be changed by editing the respective environment/<env>.rb file if desired, although the defaults are sensible.

You will generally need to restart your server whenever a gem is installed or updated, if you upgrade ruby, or if you change some logic that runs during boot time (like config/boot.rb or config/database.yml). Otherwise it's generally ok not to, even if you edit/add models/controllers.

Side note: the jquery-rails gem makes adding jquery to a project easy.