Ruby Default Web Server
Last updated 21 March 2020
Table of Contents
When you deploy a Ruby application without a Procfile a default webserver will be used. For Rack this means $ bundle exec rackup is run for Rails $ rails server. Depending on the version of these libraries you are using and what gems you have in your Gemfile, the WEBrick server may be used to run your production application.
Even if your application does not use WEBrick, it is HIGHLY recommended you do not rely on this implicit behavior and instead explicitly declare how you want your webserver started via a Procfile. If you don’t have a preference we recommend configuring your application to run on Puma. When selecting a webserver make sure that it can handle concurrent requests.
The rest of this article contains information about WEBrick and why it is not a good idea to run it in Production.
What is WEBrick
The Ruby standard library comes with a default web server named WEBrick. As this library is installed on every machine that has Ruby, most frameworks such as Rails and Rack use WEBrick as a default development web server.
While WEBrick should be fine for development, it was not designed to handle a high concurrent workload that a Ruby app must serve in production. A production web server should be used instead.
Why not WEBrick
WEBrick will spawn a new thread for each request, this behavior can be fine for some applications but due to the GVL this means that WEBrick cannot make use of multiple cores. If you need maximum performance Heroku recommends a multi-process multi-threaded server, we currently recommend Puma.
If you do not specify a web server in your Procfile, it is likely that you’re running WEBrick in production. If you continue to run WEBrick it is likely that requests will take a long time, possibly timeout, and you will need to use many more dynos than your application requires.
Rather than doing this, ensure you use a production web server.
Production web server
A production Ruby web server is capable of handling multiple request concurrently. We currently recommend using the Puma web server.
Please add it as a dependency to your Gemfile, add a Procfile that specifies your production web server, commit to git and deploy. For a detailed explanation read Deploying Rails Applications With Puma.