Using Thruster web server for Ruby apps

Recently, I set up some deployment scripts for a Ruby app where I wanted the server to handle SSL termination.

In the "old" days, I would set up Caddy with reverse proxy the app with something like this:

# Caddyfile
yourdomain.com {
    reverse_proxy localhost:3000
    tls
}

On top of this, I would usually run Caddy as one of the dependencies in a docker-compose.yml file to make it easier to install and reinstall everything.

Recently, Basecamp released a simple reverse proxy server that handles everything I would need for serving Ruby apps in a gem called Thruster.

As per the GitHub repo, here is what this server brings:

• HTTP/2 support
• Automatic TLS certificate management with Let's Encrypt
• Basic HTTP caching of public assets
• X-Sendfile support and compression, to efficiently serve static files

For 99% of the use cases out there, this fits the requirements perfectly. And best of all, I could run this in the same container as my Ruby app. This means I don't need a separate container to run Caddy.

Configuration

The gem is stated as a "no configuration" software, and this is almost true.

In reality, you still need to (at the very least) specify to Thruster which domains you want it to request SSL certificates for.

This is done via the environment variable TLS_DOMAIN.

The good thing about this is that it is possible to specify multiple domains, so Thruster can automatically request the correct Let's Encrypt certs for each of them.

For instance, if my app is serving from domain1.com and domain2.com, I could just specify it as TLD_DOMAIN=domain1.com,domain2.com and Thruster would pick this up just fine.

Running Thruster

To run Thruster, all you need to do is prefix it with the command you usually use to run your Ruby app.

For example, if you're on Rails, you'd normally type bin/rails server.

The modification for thruster would be thrust bin/rails server.

I feel this is why I like Thruster so much. With Caddy, I needed to set up a reverse proxy (oftentimes with trial and error with that darn Caddyfile). Using Thruster, I was able to get things set up in less than 3-5 minutes.

Use Cases

There are many options for serving web requests from Ruby (and Rails) apps these days in production environment.

1. You can do a reverse proxy, such as with nginx or Caddy,
2. You can use Kamal,
3. Or you can just use Thruster and have Docker monitor the service itself.

I think in most cases, options (1) and (2) makes the most sense if it's on servers you control.

For (3), there is a special use case: self hosted applications. In other words, Ruby apps that your customers run on their own infrastructure and where they're the ones installing the app.

The difference between the three described options is that in cases (1) and (2), it is easy for the devops person to go in and reconfigure things easily.

When providing a Docker image (likely the most often scenario) to a customer to self-host, there are a lot of things that can go wrong.

The customer may not be familiar with managing their own server, for example. Or perhaps the customer does not want to fiddle around with reverse proxies to make things work.

In these cases, it's easier to just hand over a Docker container where things "just work".

I ran into this problem while developing my self-hosted email marketing software, and luckily Thruster was available.

As I packaged everything into containers anyway and provide a docker-compose.yml file, this also dropped my container dependencies from 4 to 3, eliminating the need to run nginx or Caddy.

Conclusion

Thruster is a pretty good alternative for handling reverse proxies to your Ruby app.

Its simple "no-configuration" option makes it work very well in many scenarios.

For myself, when packaging Ruby apps that need to be run in environments I don't control (ie. self hosted apps on customers' machines), this is the way to go.