Binary Solo

Generating self-signed certificates for web services

2026-09-10T00:00:00+01:00

Private web services such as PostgreSQL or Redis shouldn’t be exposed to the internet. This keeps them secure, as they can only be accessed via an SSH session to the machine they’re installed on, or through a private cloud network.

However, if you must expose them to the internet, I recommend securing them using self-signed certificates. This way, the connection cannot be hijacked or eavesdropped upon.

Since these are internal services, there’s no value in using a public certification authority (CA) such as Let’s Encrypt to issue the certificates. We can create our own trusted certificate chain for authentication.

Creating the certificates

We need to create a root certificate which will be used to sign all other certificates. This certificate sits at the top of the trust chain, and is used to vouch for all other certificates via a cryptographic signature.

$ openssl req -x509 -newkey rsa:4096 \
    -keyout ca.key \
    -out ca.pem \
    -days 3650 \
    -nodes \
    -subj "/O=My Company/CN=My Company Root CA"

The -subj contains metadata to store in the certificate. O stands for organization, and CN stands for common name.

The private key (ca.key) generated by this command is the most important secret. It will be used to sign all other certificates. Keep it safe!

The certificate (ca.pem) is our root certificate which we will implicitly trust.

Next, create a key and certificate signing request (CSR) for a certificate to install on the server:

$ openssl req -newkey rsa:4096 \
    -keyout server.key \
    -out server.csr \
    -nodes \
    -subj "/O=My Company/CN=My Server"

And another key and CSR for clients:

$ openssl req -newkey rsa:4096 \
    -keyout client.key \
    -out client.csr \
    -nodes \
    -subj "/O=My Company/CN=My Client"

Sign both server and client CSRs with the root certificate:

$ openssl x509 -req \
    -in server.csr \
    -CA ca.pem \
    -CAkey ca.key \
    -CAcreateserial \
    -out server.pem \
    -days 825 \
    -sha256

$ openssl x509 -req \
    -in client.csr \
    -CA ca.pem \
    -CAkey ca.key \
    -CAcreateserial \
    -out client.pem \
    -days 825 \
    -sha256

The server.key and server.pem files are installed on the server, and the client.key and client.pem files are presented by the client when creating the connection. This ensures authentication happens in both directions, the client authenticates the server, and the server authenticates the client.

The root certificate (ca.pem) serves as the trusted authority that vouches for the client and server certificates. That’s the certificate we implicitly trust, so store it safely!

If an attacker attempts to connect with their own certificates, authentication will fail as the server’s certificate won’t have been signed by the CA certificate presented by the attacker.

Let’s look at how to set this up in PostgreSQL.

Securing PostgreSQL with self-signed certificates

This section assumes you have PostgreSQL installed on your server.

Allow the PostgreSQL TCP port through your firewall:

$ sudo ufw allow 5432/tcp

Ensure PostgreSQL binds to all available TCP interfaces:

# /etc/postgresql/<version>/main/postgresql.conf

# ...

listen_addresses = '*'

# ...

Force SSL authentication on the server for external connections:

# /etc/postgresql/<version>/main/pg_hba.conf

# TYPE  DATABASE    USER      ADDRESS     METHOD
# Enforce SSL authentication for all client connections
hostssl all         all       0.0.0.0/0   trust     clientcert=verify-ca
# Reject all non SSL connections
host    all         all       0.0.0.0/0   reject

Setting clientcert to verify-ca verifies the client certificate against the trusted root certificate.

Upload the root certificate (ca.pem), server private key (server.key), and server certificate (server.pem) to the server using SCP.

Ensure all 3 files are owned by the postgres user:

$ sudo chown postgres:postgres path/to/ca.pem
$ sudo chown postgres:postgres path/to/server.key
$ sudo chown postgres:postgres path/to/server.pem

The private key must have 600 permissions:

$ sudo chmod 600 path/to/server.key

Open the PostgreSQL configuration once again and add in the paths to these files:

# /etc/postgresql/<version>/main/postgresql.conf

ssl = on
ssl_ca_file = '/path/to/ca.pem'
ssl_cert_file = '/path/to/server.pem'
ssl_key_file = '/path/to/server.key'

Restart the PostgreSQL server:

$ sudo systemctl restart postgresql

You can now connect to the PostgreSQL server using:

$ psql "host=<server_ip_address> user=postgres sslcert=./client.pem sslkey=./client.key sslrootcert=./ca.pem sslmode=verify-ca"

sslmode=verify-ca on the client connection ensures authentication is performed in both directions. Using this technique, connections to PostgreSQL are secure over the internet.

Securing Redis with self-signed certificates

This section assumes you have Redis installed on your server.

Allow the Redis TCP port through your firewall:

$ sudo ufw allow 6379/tcp

Upload the root certificate (ca.pem), server private key (server.key), and server certificate (server.pem) to the server using SCP.

Ensure the files are owned by the redis user:

$ sudo chown redis:redis path/to/ca.pem
$ sudo chown redis:redis path/to/server.key
$ sudo chown redis:redis path/to/server.pem

The private key must have 600 permissions:

$ sudo chmod 600 path/to/server.key

Open the Redis configuration file and make the following changes:

# /etc/redis/redis.conf

bind * -::*

# Protected mode requires a password for external connections,
# but since we're using SSL certs for authentication, we can safely
# disable it.
protected-mode no

port 0
tls-port 6379

tls-cert-file path/to/server.pem
tls-key-file path/to/server.key
tls-ca-cert-file path/to/ca.pem

Restart Redis:

$ sudo systemctl restart redis

Redis will now perform SSL authentication in both directions. Connect to the server by presenting the client certificate using:

$ redis-cli -h <server_ip> --cert ./client.pem --key ./client.key --cacert ./ca.pem --tls

Conclusion

In this post we covered how to issue a root certificate and sign client and server certificates using it. We then secured connections to PostgreSQL and Redis using these certificates.

We haven’t covered security best practices to keep the private keys and certificates safe. These are largely organisation dependent and out of scope for a simple guide like this one.

Ensure you keep your private keys extremely safe, especially the root CA’s private key. Issue a new certificate for each service, and in some cases you may wish to issue one for each user of each service.

The docs of web services such as Redis and PostgreSQL are very thorough in their explanation of TLS configuration, so consult those to formulate your deployment strategy, and keep your services secure!

Anatomy of a Ruby gem

2026-09-02T00:00:00+01:00

A Ruby gem is a package of Ruby code. It’s usually uploaded to a gem server such as RubyGems, although a newer alternative called gem.coop is emerging.

A gem is usually installed using bundler, which is Ruby’s official package and dependency manager.

While most Rails developers may never need to build a gem from scratch, I always learn loads when working with plain Ruby outside of Rails.

A Ruby gem doesn’t have a rigid directory structure like Rails, nor are tests automatically set up. This is all left up to the developer. In this post, I’ll cover how to create a Ruby gem from scratch, including setting up Minitest for the test suite.

Structure of a gem

Create a folder for your new gem (we’ll use the placeholder name my-gem throughout this tutorial):

$ mkdir my-gem
$ cd my-gem

Then, create a Gemfile and gemspec for it, as well as a License file:

$ touch Gemfile
$ touch my-gem.gemspec
$ touch LICENSE.txt

The Gemfile contains the dependencies required to locally develop the gem, such as debug, rake, or minitest. Dependencies required for your gem’s functionality must be defined in the gemspec.

The my-gem.gemspec file contains all metadata regarding your gem, including it’s runtime dependencies.

Add your chosen open source license to the LICENSE.txt file. I usually release everything I write under the MIT license.

Create a basic folder structure to contain your code:

$ mkdir lib
$ mkdir test
$ mkdir bin
$ mkdir scripts

The lib folder contains your package’s code. The test folder contains your test suite. bin is for any executables your package may emit, and the scripts folder is for development scripts such as linting, running tests, or releasing the gem.

Directory skeleton

The folder structure is pretty free-form, but this is the logical structure I like to use. You may wish to use a different structure if you prefer — the structure isn’t enforced.

Within these folders, pretty much anything goes, but there are a few conventions worth using.

Under lib, there should be a file named after your gem which is the entry point for your package, and a folder also named after your gem containing the implementation.

$ cd lib
$ mkdir my-gem
$ touch my-gem.rb

Create a version file with a constant denoting the gem’s version number:

$ touch my-gem/version.rb

# lib/my-gem/version.rb

module MyGem
  VERSION = "0.1.0"
end

The gemspec

With these files in place, we can implement a basic gemspec:

# my-gem.gemspec

# Read in the version from the file we just created
require_relative "lib/my-gem/version"

Gem::Specification.new do |spec|
  spec.name          = "my-gem"
  spec.version       = MyGem::VERSION
  spec.author        = # Enter your name
  spec.email         = # Enter your email address
  spec.summary       = # Enter a brief summary for what your gem does
  spec.license       = "MIT"
  spec.homepage      = # Add a link to your gem's homepage. Usually the repo's URL.

  # The files to ship with your gem. I like to ship the fewest files required
  # for the gem to work, hence git is used to read all files under `lib`, `bin`
  # and the LICENSE file.
  spec.files         = `git ls-files -z`.split("\x0").filter { |f| f.match(%r!^(lib|bin)/|^LICENSE!) }

  # Any executable files provided by your gem
  spec.executables   = ["my-gem"]
  # The location of the executable files
  spec.bindir        = "bin"

  # The paths to add to Ruby's `LOAD_PATH` when your gem is activated.
  spec.require_paths = ["lib"]

  # The minimum Ruby version
  spec.required_ruby_version = ">= 3.4.0"

  # Runtime dependencies for your gem
  spec.add_dependency "dry-cli",        "~> 1.4"
end

The full specification for this file can be found here: https://guides.rubygems.org/specification-reference/.

Read the gemspec in your Gemfile so dependencies are loaded:

# Gemfile

source "https://rubygems.org"

gemspec

Writing code for the package

The implementation of your package goes in the lib/my-gem folder. The file structure is completely up to you, and it will depend on what you’re building.

All files need to be manually required, or autoloaded in lib/my-gem.rb. You may use Zeitwerk to autoload your code, as this is what Rails uses, but I personally don’t use it in gems as I prefer more control over my file structure and module names.

Let’s create a basic implementation file to continue with this demonstration:

$ touch lib/my-gem/hello.rb

# lib/my-gem/hello.rb

module MyGem
  class Hello
    def say
      puts "Hello world!"
    end
  end
end

# lib/my-gem.rb

require_relative "my-gem/hello"

Ensure all your code is namespaced by a module named after your gem to prevent conflicts.

Setting up the test suite

Next, let’s set up Minitest to run a test suite. Add minitest to your Gemfile:

# Gemfile

source "https://rubygems.org"

gemspec

gem "rake"

group :test do
  gem "minitest"
  gem "minitest-profile"
  gem "minitest-reporters"
end

We add rake to run the test suite, and a couple of other minitest packages to improve the testing experience.

All test file names must conventionally start with test_. Create test/helper.rb to contain the global test configuration:

$ touch test/helper.rb

# test/helper.rb

require "minitest/autorun"
require "minitest/reporters"

# Require your gem's code
require File.expand_path("../lib/my-gem", __dir__)

# Customise the test reporter
Minitest::Reporters.use! [
  Minitest::Reporters::DefaultReporter.new(
    color: true
  ),
]

module MyGem
  # The base class for your tests.
  class TestCase < Minitest::Test
    module DSL
      # A basic DSL method so tests can be declared using `test "" do ... end`
      # just like Rails.
      def test(name, &block)
        test_name = "test_#{name.gsub(/\s+/, '_')}".to_sym
        raise "Duplicate #{test_name} in #{self}" if method_defined?(test_name)

        if block_given?
          define_method(test_name, &block)
        else
          define_method(test_name) do
            raise "Please implement the test: #{name}"
          end
        end
      end
    end

    extend DSL
  end
end

We do some basic setup in the helper as explain in the comments. The most important part is the test DSL method. Without this, test methods would have to be defined as

def test_does_something
  # ...
end

which is not very readable. Using this DSL, we can write:

test "does something" do
  # ...
end

Create a test:

$ touch test/test_hello.rb

# test/test_hello.rb

require "helper"

module MyGem
  class TestHello < TestCase
    test "says hello" do
      # Capture STDOUT so we can read what's written using `puts`
      original_stdout = $stdout
      $stdout = StringIO.new

      Hello.new.say

      assert_equal "Hello world!", $stdout.string.strip
    ensure
      # Ensure we reset `STDOUT` back to what it was
      $stdout = original_stdout
    end
  end
end

Create a Rakefile and initialise the test task provided by Minitest so we can run the tests:

$ touch Rakefile

# Rakefile

require "minitest/test_task"

Minitest::TestTask.create

Install dependencies and then run the tests:

$ bundle install
$ bundle exec rake test

You can run specific tests using the I argument:

$ bundle exec rake test I=/hello/

More details on the Rake task and how to run tests using Minitest is available in the official docs.

Now that we have the tests working, let’s look at releasing the gem.

Building and releasing the gem

To release the gem, we first need to build it. In your gemspec, comment out the following lines:

# spec.executables   = ["my-gem"]
# spec.bindir        = "bin"

We haven’t created any executables, so this will result in an invalid spec. Then, initialise a git repo and commit your code:

$ git init
$ git add .
$ git commit -m "Initial commit ..."

And finally, build your gem:

$ gem build my-gem.gemspec

This will create a .gem file in your current directory. This is a compressed ZIP file. Rename the extension to .zip and you can extract it using your OS’s archiving utility.

Within this archive, you’ll find three more archives:

checksums.yaml.gz
data.tar.gz
metadata.gz

checksums.yaml.gz contains signatures for your package to ensure its integrity.

data.tar.gz contains your package’s code.

And, metadata.gz is your evaluated gemspec, stored as a YAML dump of a Gem::Specification object.

The entire .gem archive is pushed to a Gem server for distribution.

Distributing your gem

RubyGems.org is the most popular open source gem server and the default for most projects. Create an account on their website.

Then, add the rake task to release your gem to your Rakefile:

# Rakefile

require "bundler/gem_tasks"
require "minitest/test_task"

Minitest::TestTask.create

Release your gem using:

$ bundle exec rake release

You may have to log into RubyGems on your terminal. Follow the on-screen instructions. After pushing your gem, users can add it to their Gemfile to use it in their projects!

Wrapping up

That was a look inside a basic Ruby gem. There’s always a lot to learn when your remove all the supports Rails gives you, and building a Ruby gem is a great way to level up your pure Ruby skills.

To improve your experience, you can add scripts to your scripts/ folder to run your tests and release your gem.

Deploying Rails apps to a server using Mimas

2026-09-01T00:00:00+01:00

Deploying a Rails app to a server can have many moving parts. We need a reverse proxy to terminate SSL and serve static assets, ensure deploy errors don’t affect the active release and that successful deploys are zero-downtime, and finally, configure log rotation and database backups.

mimas, along with its Rails plugin automates all of this, making it easy to self-host your Rails apps instead of paying the ridiculous prices for a PaaS.

See my blog series on Ruby app deployment to understand how Mimas works under the hood.

Adding Mimas to your app

Add Mimas and its Rails plugin to your bundle and create a binstub for it:

$ bundle add mimas-rails -g development
$ bundle binstub mimas

Run the init command to setup the config files needed by Mimas:

$ bin/mimas init

You’ll be prompted for details about your domain and server. A pre-deploy hook to build your Rails assets will also be set up.

A /deploy folder will be created with a mimas.rb configuration file, a puma.rb file to configure Puma in production, and a Caddyfile to configure the Caddy reverse proxy.

All these files are self-documented. Consult the Puma and Caddy docs for further information on those files.

Deploying your app

Provision your production server if you haven’t already:

$ bin/mimas provision production

If you need PostgreSQL or Redis, use the mimas-postgresql and mimas-redis plugins to set those up.

$ bin/mimas postgresql setup production
$ bin/mimas redis setup production

Create a database if you’re not using SQLite:

$ bin/mimas postgresql create_db my_app_production production

Make a note of the database password generated.

Create an .env file on the server for your app’s sensitive information:

$ bin/mimas env edit production

This will open your text editor. Add in environment variables as key-value pairs:

RAILS_MASTER_KEY=...
DATABASE_PASSWORD=...
REDIS_URL=unix:///run/redis/redis-server.sock

You don’t need to set RAILS_ENV as that is set in the Mimas configuration (mimas.rb).

Ensure you update your database.yml to read the DATABASE_PASSWORD.

# config/database.yml

production:
  <<: *default
  user: my_app_production
  password: <%= ENV["DATABASE_PASSWORD"] %>
  database: my_app_production

Push your site to your server:

$ bin/mimas push production

That’s it! Your app should be live at the domain name you provided in mimas.rb. If you run into any issues, ensure your DNS is configured correctly.

All future deploys will be zero downtime. If a deploy throws an error, it will be rolled back and the existing service will be unaffected.

To manually rollback a deployment, revert your code change and deploy again.

Mimas is still in early stages of development, but I use it to run Scattergun, so it’s fairly production tested. Give it a go and let file an issue (or better, create a PR), if you run into problems!

Redis server setup for Rails apps

2026-08-26T00:00:00+01:00

In this post, we’ll discuss how to install and configure Redis on an Ubuntu server for use with Rails apps.

Installing Redis

Install Redis using the apt utility:

$ sudo apt install redis-server

This will create a new Linux user called redis, and install a systemd service to run Redis under that user.

Configuring Redis

Redis has a configuration file located at /etc/redis/redis.conf. The file is largely self-documented, so I recommend reading through it to see the avaiable options. Depending on what you’re using Redis for, you may wish to set the maxmemory and maxmemory-policy settings.

For example, a cache server might set an expiration policy for maxmemory-policy, but when used as Sidekiq’s data-store, you absolutely do not want it to drop jobs when maxmemory is hit, so a noeviction policy is appropriate.

When running Redis on the same server as your Rails app, make the following changes to the config file:

bind 0.0.0.0
port 0

unixsocket /run/redis/redis-server.sock
unixsocketperm 777

The bind and port directives disable TCP binding, so Redis is only available via a Unix socket. This keeps it secure as the server cannot be accessed from outside the machine.

Then we define the path to the Unix socket using unixsocket, and the file permissions for the socket file using unixsocketperm. 777 means all users on the machine have execute permissions on the socket file, and hence can access Redis via a Unix socket.

I recommend against exposing Redis to the internet. If you run Redis on a standalone server, create a private IP for it and only bind it to that IP address. If you must expose it to the internet, ensure you create a self-signed certificate to authenticate and encrypt access. That setup is out of scope for this guide.

Restart the Redis service to apply the changes:

$ sudo systemctl restart redis-server

You can now supply the Redis URL to the Rails app:

unix:///run/redis/redis-server.sock

I recommend setting this value in an environment variable and reading it into your app where required.

Redis and Mimas

The mimas deployment tool for Ruby apps has a Redis plugin to automate this process.

Everything covered in this article is automated by the plugin. Have a look at the source code to dig deeper!

PostgreSQL server setup for Rails apps

2026-08-25T00:00:00+01:00

Following on from my series on Ruby app deployment, in this post, I’ll cover the installation and setup of PostgreSQL for Ruby and Rails apps.

We’ll discuss how to install, secure, and backup PostgreSQL databases on an Ubuntu server.

Installing PostgreSQL

Install PostgreSQL using apt:

$ sudo apt install postgresql postgresql-contrib

The postgresql-contrib package installs a number of useful extensions. The full list can be found on GitHub.

The above command will create a new Linux user called postgres and install a systemd service to run PostgreSQL under this user.

You can ensure the server is running by accessing the CLI:

$ sudo -u postgres psql

Configuring PostgreSQL

PostgreSQL has its own concept of users (also known as roles), which are useful for access control to different databases. The default role is called postgres and is a super user with full-access to all databases on the server. I recommend against using this role to access databases from your Rails app. Create a new role for each app (we’ll discuss this shortly).

The configuration files

PostgreSQL has two main configuration files that we are concerned with: postgresql.conf and pg_hba.conf. Both these files are located in the config directory, which can be found by running:

$ sudo -u postgres psql -c 'SHOW config_file;'

postgresql.conf contains settings related to the running of the server, such as memory settings, and the location of the data directory. The file is self-documented so you can have a read through it to understand the options.

pg_hba.conf defines access control to the server and its databases. They are defined in a table-like format as:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             postgres                                peer

# ...

The default rules will vary depending on your installation of PostgreSQL, but it will always contain the above rule which allows the postgres Linux user access to the whole database server. The value peer under METHOD means that the postgres Linux user can access the postgres role within PostgreSQL without additional authentication.

I recommend the following additional rules in this file:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# Allow access via the local Unix socket to all databases and roles using password authentication
local   all             all                                     scram-sha-256

# Allow access via `localhost` to all databases and roles using password authentication
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256

# Reject all external connections
host    all             all             0.0.0.0/0               reject

You can find the complete documentation for this file in the PostgreSQL docs.

When running your Rails app on a single server, where the app and database are on the same machine, it’s best to access the PostgreSQL server via the Unix socket.

In such a setup, you can still access your database using SSH. GUI apps like DBeaver can also be used through an SSH tunnel.

If you must expose PostgreSQL to the internet, ensure you issue self-signed certificates to authenticate access. Setting this up is out of scope for this guide.

Creating a role and database

After PostgreSQL has been configured, and access control defined, we can create a role and database for our Rails app.

$ sudo -u postgres psql -c 'CREATE ROLE <app_name> WITH LOGIN PASSWORD <password>'

Ensure you generate a secure password for the role using a password manager, or use openssl on the command line as:

$ openssl rand -hex 64

Once you have created the role, create all the databases your app needs:

$ sudo -u postgres psql -c 'CREATE DATABASE <app_name>_production OWNER <app_name>'
$ sudo -u postgres psql -c 'CREATE DATABASE <app_name>_production_queue OWNER <app_name>'
$ sudo -u postgres psql -c 'CREATE DATABASE <app_name>_production_cache OWNER <app_name>'
$ sudo -u postgres psql -c 'CREATE DATABASE <app_name>_production_cable OWNER <app_name>'

All these databases can now be accessed using the role name and password based on our earlier pg_hba.conf settings. Using this technique rather than peer authentication, means we don’t have to create a new Linux user for each app.

Configure Rails’s database.yml to point to these databases:

production:
  primary:
    <<: *default
    user: <%= ENV["DATABASE_USER"] %>
    password: <%= ENV["DATABASE_PASSWORD"] %>
    database: <app_name>_production
  cache:
    <<: *default
    user: <%= ENV["DATABASE_USER"] %>
    password: <%= ENV["DATABASE_PASSWORD"] %>
    database: <app_name>_production_cache
    migrations_paths: db/cache_migrate
  queue:
    <<: *default
    user: <%= ENV["DATABASE_USER"] %>
    password: <%= ENV["DATABASE_PASSWORD"] %>
    database: <app_name>_production_queue
    migrations_paths: db/queue_migrate
  cable:
    <<: *default
    user: <%= ENV["DATABASE_USER"] %>
    password: <%= ENV["DATABASE_PASSWORD"] %>
    database: <app_name>_production_cable
    migrations_paths: db/cable_migrate

Ensure you set the database user and password we created earlier as environment variables, and the above setup should just work. In the absence of a database URL, the Ruby PostgreSQL client will automatically try and connect on the Unix socket.

Database backups

Database backups are absolutely critical. It’s arguably more important than the application code, as no product or company can recover from losing the database.

The frequency of backups will depend on your application’s scale. For most small-scale apps, hourly backups should be sufficient.

Never store backups on the same machine as your database server, as this defeats the purpose of the backups in the first place. If your database server is destroyed, you’ll lose the backups too.

On Hetzner, I use their block storage for database backups. These are cheap and can be mounted as volumes on your database server. They’re also replicated across three physical servers ensuring data integrity.

For additional security, we’ll also encrypt our backups to keep user data safe.

`pg_dump`

PostgreSQL has a utility called pg_dump to create backups.

$ sudo -u postgres pg_dump \
    --format=custom \
    --username=postgres \
    --dbname="<db_name>" > database_backup.dump

The custom format is a compressed binary format which keeps the backup size efficient, and allows for easy restores. We use the postgres user as it has access to all database and simplifies access control.

Consult the docs for complete usage information.

To encrypt this dump, we’ll use hybrid encryption. This combines asymmetric key and symmetric key encrytion.

We’ll first generate a public key and private key. The public key is kept on the server to encrypt the backups, and the private key must be downloaded and kept safely in a password manager, as it will be needed to decrypt backups.

We can’t use these keys directly for encryption, as this method can only encrypt data smaller than the key size itself. As such, we’ll generate a new symmetric encryption key to encrypt the data, and then encrypt that key using the public key of our key-pair, and store that within the data.

To decrypt the backup, we’ll use the private key to decrypt the symmetric key used to encrypt the data, and then use that key to decrypt the data itself.

openssl has a utility called smime which makes this entire process seamless. All we need to do first is generate our key pair.

$ openssl req -x509 -newkey rsa:4096 -keyout private_key.pem -out pg_dump_certificate.pem -days 36500 -nodes -subj '/CN=PostgreSQL Backup Certificate'\"

Download private_key.pem from the server and keep it safe. Leave pg_dump_certificate.pem on the server to encrypt backups.

Backups can now be generated and encrypted using:

$ pg_dump \
    --format=custom \
    --username=postgres \
    --dbname=<db_name> |
    openssl smime \
        -encrypt \
        -aes256 \
        -binary \
        -outform DER \
        -out database_backup.dump.enc \
        "<path/to/certificate>"

To decrypt the dump, run:

openssl smime -decrypt -binary -inform DER \
  -in database_backup.dump.enc \
  -inkey <path/to/private/key> \
  -out backup.dump

Restore the dump using:

sudo -u postgres pg_restore \
  -U <role_name> \
  -d <database_name> \
  --no-owner --no-acl --clean \
  <path/to/dump>

Ensure the role and database exist on the server before attempting restoration.

Conclusion

We covered a lot of details about PostgreSQL in this article. Running your own database instead of a managed database service can be a huge cost saving, but does come with additional work.

That’s why I created mimas and the mimas-postgresql plugin. These tools allow your to deploy Ruby and Rails apps to your own servers with ease. Everything discussed in this article has been automated by these tools.

Have a look at the source code if you’re curious, and try them out on your projects!

Ruby installation and management with rv

2026-08-11T00:00:00+01:00

Ruby version management can be quite fiddly. All Ruby developers need multiple Ruby versions installed, as different projects may use different Rubies.

For the past few years, I’ve used rbenv along with ruby-build to install and manage Ruby versions. They’re good tools, but I was using them more out of inertia than anything else.

When it came to building Mimas, which is a tool to deploy Ruby apps to a VPS, I started researching alternatives. Initially, I landed on chruby and ruby-install.

chruby simply manipulates environment variables to ensure the correct Ruby binary is selected, contrasting with rbenv which shims the ruby command to intercept invokations and load the appropriate binary.

ruby-install and ruby-build both make it easier to build Ruby binaries from source, but ruby-install doesn’t need to be updated every time a new Ruby version is released.

chruby’s cleaner approach of using environment variables rather than a shim was a huge selling point for me, but then I discovered rv.

What is `rv`?

rv is a relatively new tool which aims to be a lot more than a Ruby version manager. See the project Readme for a detailed roadmap, but for now, I use it only to install and manage Ruby versions.

The biggest point of difference is that rv doesn’t build Ruby from source on your machine. The project maintainers host precompiled binaries for all popular operating systems and CPU architectures. This means that Ruby can be installed in under 2 seconds, rather than about 15 minutes.

Installing Ruby with `rv`

Install the latest Ruby version with rv using:

$ rv ruby install latest

or specify a version:

$ rv ruby install 4.0.6

This will download the correct precompiled binary for your system. This makes Ruby upgrades on servers an order of magnitude easier as you don’t have wait 15 minutes for the build, or worry about the additional CPU usage if it’s a production web server.

Switching Ruby versions with `rv`

When it comes to switching between different Ruby versions, rv takes the best bits of both rbenv and chruby and combines them.

The rv shell command prints out instructions to integrate rv with your chosen shell. Once integrated, it automatically detects the active Ruby version using the .ruby-version or .tools-versions file in your project, and selects it using environment variables.

Additionally, you can use rv run to run commands within a Ruby environment. This can be used to run a command in a different Ruby that what’s currently active, or to setup a Ruby environment where the shell integration doesn’t apply (such as, when a login shell isn’t available).

I think this is an elegant solution that allows users to execute Ruby commands seamlessly in an interactive shell, while also providing a way to configure a Ruby environment explicitly, without shimming the ruby command itself.

See the project readme for detailed usage docs.

`rv` in my workflow

I’ve switched all Ruby management to rv in my deployment tool: Mimas. It simplified the server provisioning process, and reduced the time required to install a new Ruby to mere seconds.

I’ve also started using rv for my local development environment. It took me just a few minutes to uninstall rbenv and get everything working with rv. I really can’t recommend it highly enough. Go and give it a try!

Zero-downtime Ruby deployment without Docker

2026-07-31T00:00:00+01:00

In the final part of this series, we’ll build upon the setup created in Part 2a and close the loop by deploying code from our machine to the server.

Part 2a covered the setup to serve Ruby apps, but that app was created on the server itself. To deploy code, we need a way to copy our project files to the server and reload the server process for the changes to take effect. Ideally, we also want to ensure the new code starts up correctly and is healthy, before switching traffic over to it (sometimes known as blue-green deploys).

At the end of the post, I’ll introduce Mimas, which automates everything discussed in this post. Hence, this post is largely theory and doesn’t contain code examples for every step. Although, this knowledge will stand you in good stead if you choose to build your own deployment tooling.

Here are the steps required for zero-downtime blue-green deployments:

Copy the code to the server.
Start a new server process with the deployed code.
Health-check the new process.
Switch the reverse proxy to the new server’s Unix socket.
Gracefully stop the old process without dropping requests.

Let’s take this step-by-step.

Copying code to the server

Heroku popularised the git push technique to copy code to a server. Personally I’m not a fan of this method when deploying code to a VPS, because it uses the server as a build server. git push will send your project as-is to the server, and any artifacts that require building, such as JavaScript assets, or an entire static site, will need to be done on the server.

This creates more moving parts as build dependencies such as Node need to be installed on the server. I prefer to build the site locally, or on a CI server, and push the built files to the hosting server. The most efficient way to do this is to create a GZIP archive of all required files, and then use SCP to copy that to the server.

Starting and health-checking new server process

After we have the GZIPped code on the server, we can extract it using the tar -xf command. To start the server process, we’ll create a new systemd service for the release. The way we set up the server in Part 1 means that this can be done without sudo privileges.

When the new systemd service has been created and started, we’ll make a curl request to the new Unix socket to ensure it is running.

Switching the reverse proxy and stopping the old service

When the new service has been health-checked, we can change the Caddyfile to point to the new Unix socket, and reload Caddy. Caddy does this seamlessly without downtime, and gracefully completes any requests in-flight.

And finally, we need to stop and remove the old service. Both Puma and Falcon stop gracefully without dropping requests when SIGTERM is sent to the process, so we won’t lose any requests here either.

And that’s it, our new code will be up and running!

Automation

Doing all the above steps manually is a recipe for disaster. With so many things going on, this needs to be automated for reliability. I’ve created a CLI tool called Mimas which automates everything I’ve covered in this blog series, and is optimised for single server Ruby deployments.

Introducing Mimas

My goal with Mimas was to create a single solution for end-to-end deployments, from securing the server, to configuring log rotation, and everything in between. These were my goals when building Mimas:

Securing the server, including creating the required user acccounts.
Installing and configuring Caddy.
Installing prerequisite software including Ruby.
Deploying multiple sites on a single server.
Deployment of static sites as well as Ruby apps.
Creating systemd services to automatically start and restart web services.
Zero-downtime and blue-green deploys.
Configure log rotation.

It’s still early days so there are likely to be issues. All my static sites (including the blog you’re reading) are now hosted on a VPS and deployed using Mimas. I’ve also created an official Bridgetown plugin for it, so you can deploy your Bridgetown static or hybrid apps to a VPS easily!

While it works well with static sites and simple Rack apps, Rails support is currently untested. I’m planning to migrate one of my Rails apps off Render, and onto a VPS, so I will release an official Rails plugin for Mimas in the coming weeks based off that work.

EDIT: Mimas now has a Rails plugin. Here’s the blog post describing it.

Mimas is written in Ruby and works by running Bash commands and scripts over SSH. There’s nothing fancy going on under the hood. The code should be fairly easy to follow, and the Readme describes how it all works.

Docker is far too heavy-handed for most projects, and PaaS providers can be quite expensive for small-scale and side projects. I hope that Mimas helps self-hosting become a bit more accessible as a free all-in-one solution.

Falcon as a web server for Ruby applications

2026-07-24T00:00:00+01:00

In the previous post, we covered how to install and run Caddy, and then use it as a reverse proxy to serve a Rack app, and discussed why this is the conventional configuration.

However, Falcon aims to change this. It has a mode called Falcon Virtual designed specifically to face the internet and perform SSL termination and SNI resolution to serve multiple sites. It also supports HTTP/2 natively. It’s designed for high I/O throughput using Ruby Fibers making it efficient at serving static assets.

That got me thinking that it would be great to serve Ruby apps using Ruby end-to-end. This post describes a strategy to serve a Rack app using Falcon, without an additional reverse proxy. And also, why that’s a really bad idea and I wouldn’t recommend it.

To be clear, Falcon’s great, but the approach of serving a Ruby web app without a reverse proxy is wrong in my opinion, and I’ll explain why at the end.

You’ll need a domain name that you own, and can point at your server to complete this guide.

Initial setup

If you worked through the previous post, and have Caddy installed on your server, stop the Caddy service as it will clash with Falcon. Falcon will need to bind to ports 80 and 443 to serve internet HTTP and HTTPS traffic.

# Run as the `admin` user
$ sudo systemctl stop caddy

Apart from that, this guide builds on the server setup described in Part 1.

Ports lower than 1024 are privileged and can only be bound to by processes with elevated privileges. However, I’d prefer to run Falcon as the deploy user. That way, automated tools can manage it without needing to connect as admin.

Authbind

There’s a utility called authbind which enables processes run by users without elevated privileges to bind to privileged ports.

SSH to your server as admin and install authbind:

$ ssh admin@<ip-address>
$ sudo apt install authbind

Then, we need to create files representing each port we’d like to allow a user to bind to, and give them the execute permission on that file:

$ sudo touch /etc/authbind/byport/80
$ sudo touch /etc/authbind/byport/443
$ sudo setfacl -m u:deploy:rx /etc/authbind/byport/80
$ sudo setfacl -m u:deploy:rx /etc/authbind/byport/443

We create two files for the two HTTP ports and give the deploy user the necessary permissions. Using authbind, we can now run a process under the deploy user that can bind to these ports.

Certbot

While you’re connected as admin, install certbot to issue SSL certificates, as Falcon doesn’t do this automatically.

$ sudo snap install --classic certbot

Exit the SSH session and reconnect as deploy:

$ ssh deploy@<ip-address>

A basic Rack app

Create a new Rack app within a folder named after your domain name:

$ mkdir -p ~/http/example.com

Scaffold an empty Ruby project:

$ cd ~/http/example.com
$ bundle init
$ touch config.ru
$ bundle add rack falcon

Create a basic Rack app as shown below:

# config.ru

class App
  def call(env)
    [200, { "content-type" => "text/plain" }, ["It is now #{Time.now.utc}"]]
  end
end

run App.new

You’ll also need to create a Falcon config file that is executable:

$ touch falcon.rb
$ chmod +x falcon.rb

# falcon.rb

#!/usr/bin/env falcon-host

require "falcon/environment/rack"

service "example.com" do
  include Falcon::Environment::Rack
end

Bootstrapping an SSL certificate

This is where things start to get tricky because Falcon doesn’t automatically issue SSL certificates. We’ll use a utility called certbot to issue certificates. Certbot makes a request to Let’s Encrypt, which issues something called an ACME challenge. This is an HTTP request to your server for a file certbot places at a conventional location. It’s used to validate that you own the domain and server.

This leads to a catch-22 problem where we need an SSL certificate (even an invalid one), to be able to start Falcon so it can serve the ACME challenge used to issue the SSL certificate.

We’ll solve this problem by:

Creating a self-signed SSL certificate and point Falcon at that in the absence of a valid certificate.
Handle the ACME challenge HTTP request using the self-signed certificate.

Issuing a self-signed certificate

First, update the Falcon config so it looks for a live SSL certificate, and falls back to a self-signed certificate if one doesn’t exist:

# falcon.rb

#!/usr/bin/env falcon-host
# frozen_string_literal: true

require "falcon/environment/rack"
require "falcon/environment/tls"

service "rack.forkhandles.cc" do
  include Falcon::Environment::Rack
  include Falcon::Environment::TLS

  # Required due to https://github.com/socketry/falcon/pull/355
  ssl_private_key { OpenSSL::PKey.read(File.read(ssl_private_key_path)) }

  # Define a location for the self-signed certs used to bootstrap a valid cert
  lets_encrypt_bootstrap { "/home/deploy/.config/letsencrypt/bootstrap" }
  # Define a location for the live certificates
  lets_encrypt_root { "/home/deploy/.config/letsencrypt/live" }

  # Fallback to the self-signed cert if a valid cert doesn't exist
  ssl_certificate_path {
    live_cert = File.join(lets_encrypt_root, authority, "fullchain.pem")
    bootstrap_cert = File.join(lets_encrypt_bootstrap, authority, "fullchain.pem")

    if File.exist?(live_cert)
      return live_cert
    else
      return bootstrap_cert
    end
  }

  ssl_private_key_path {
    live_pk = File.join(lets_encrypt_root, authority, "privkey.pem")
    bootstrap_pk = File.join(lets_encrypt_bootstrap, authority, "privkey.pem")

    if File.exist?(live_pk)
      return live_pk
    else
      return bootstrap_pk
    end
  }
end

Create the directory structure for the certificates, and issue the self-signed certificate.

$ mkdir -p ~/.config/letsencrypt/bootstrap
$ mkdir -p ~/.config/letsencrypt/live
$ mkdir -p ~/.config/letsencrypt/log
$ mkdir -p ~/.config/letsencrypt/lib

$ mkdir ~/.config/letsencrypt/bootstrap/example.com
$ cd ~/.config/letsencrypt/bootstrap/example.com
$ openssl req -x509 -newkey rsa:2048 \
    -keyout privkey.pem \
    -out fullchain.pem \
    -days 365 \
    -nodes \
    -subj "/CN=example.com"

Responding to the ACME challenge

Next, we need to handle the ACME challenge. Implement a Rack middleware to match and respond to the challenge’s HTTP request:

# config.ru

class AcmeChallenge
  MATCHER = /\A\/\.well-known\/acme-challenge\/([\w-]+)/
  def initialize(app)
    @app = app
  end

  def call(env)
    if match = env["PATH_INFO"].match(AcmeChallenge::MATCHER)
      token = match[1]
      challenge_file = File.join(__dir__, ".well-known", "acme-challenge", token)

      if File.exist?(challenge_file)
        [200, {}, [File.read(challenge_file)]]
      else
        [404, {}, [""]]
      end
    else
      @app.call(env)
    end
  end
end

class App
  def call(env)
    [200, { "content-type" => "text/plain" }, ["It is now #{Time.now.utc}"]]
  end
end

use AcmeChallenge
run App.new

The middleware will detect a challenge request, and read the file placed by certbot in the conventional location and return it to fulfil the challenge.

We can now finally run Falcon:

$ cd ~
$ authbind --deep falcon virtual /home/deploy/http/**/falcon.rb

The glob pattern should find the falcon.rb files for all sites on the server and start them. It will use the domain specified as the service name in falcon.rb to match requests to the correct site.

With the server running, create a second SSH connection as deploy and run certbot:

$ certbot certonly --webroot --agree-tos --email <your email> -w ~/http/example.com -d example.com  --work-dir ~/.config/letsencrypt/lib --logs-dir ~/.config/letsencrypt/log --config-dir ~/.config/letsencrypt/

Certbot should issue your certificate and Falcon should automatically detect it after a few seconds. Once the certificate is issued, certbot will automatically renew it.

Your Rack app should now be accessible from the internet, using your domain name, with a valid SSL certificate.

A systemd service

You can create a systemd service for Falcon Virtual as shown below:

[Unit]
Description=Falcon Virtual
After=network.target

[Service]
Type=notify
NotifyAccess=all
User=deploy
ExecStart=/usr/bin/bash -lc 'authbind --deep falcon virtual %h/http/**/falcon.rb'
Restart=always

[Install]
WantedBy=default.target

Place the above contents in ~/.config/systemd/user/falcon-virtual.service, and then start the service using:

$ systemctl --user enable --now falcon-virtual

Why this setup is a bad idea

If you followed along the previous post which used Caddy, as well as this one, you probably already understand why I don’t recommend this approach.

Beyond the added fiddliness to manage SSL certificates and the ACME challenge, it also makes zero-downtime deploys impossible when upgrading Ruby. Falcon Virtual starts a main process, and then forks off processes for each of your sites. While we can reload code without stopping processes, it’s impossible to change the Ruby binary without stopping the main Falcon Virtual process.

Also, Falcon is an application server. It’s pretty damn great at being an application server. Caddy is a purpose-built web server and reverse proxy. Falcon will always be more tricky to use as a web server than Caddy.

I recommend keeping your reverse proxy independent from your Ruby processes as this is the most flexible setup.

In the next, and final part of this series, we’ll look at deploying Ruby apps to a server.

Part 3. Zero-downtime Ruby deployment without Docker

Serving Ruby apps with Caddy as a reverse proxy

2026-07-24T00:00:00+01:00

In this post, we’ll cover how to serve a Rack app using Caddy as a reverse proxy. We won’t be covering how to deploy code to the server as yet. We’ll create the Rack app on the server to handle basic HTTP requests.

This guide builds upon the server setup in Part 1 of this series.

You’ll need a domain name that you own, and can point at your server to follow along with this guide.

Why use a reverse proxy?

Ruby apps are conventionally served through a reverse proxy. Popular Ruby app servers such as Puma aren’t focused on being web servers. Their focus is on running Ruby code, and not on web server features like load balancing, SSL termination, response compression, or serving static assets. While Ruby servers may have those features, it’s not their primary focus, and hence they’re fiddly to use.

A reverse proxy handles all the web server related tasks like SSL termination and serving static files, while handing off HTTP requests to the application server. Most popular Ruby app servers also don’t support HTTP/2, which provides a significant performance gain when serving static files.

Installing Caddy

Caddy is a fantastic new-ish web server that can also be used as a reverse proxy. The documentation is accessible and thorough, and it can be configured with ease unlike older alternatives like Nginx.

SSH to your server as the admin user:

$ ssh admin@<ip-address>

Caddy can be installed using the system package manager (in this case apt, since we’re on Ubuntu). However, that also installs a systemd service, so I prefer downloading the binary to customise the service to my preference.

# Update the apt source for Caddy
sudo apt-get install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor --no-tty --batch --yes -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt-get update

# Download and install the Caddy binary
mkdir ~/tmp
cd ~/tmp
apt-get download caddy
mkdir -p caddy-unpack
dpkg -x $(find caddy*.deb) ~/tmp/caddy-unpack
sudo mv ~/tmp/caddy-unpack/usr/bin/caddy /usr/local/bin/caddy
cd ~/
rm -rf ~/tmp

Caddy needs to bind to the standard ports 80 and 443 to serve HTTP and HTTPS traffic. These are privileged ports, meaning only processes running as root (or with elevated privileges using sudo) can bind to them. Alternatively, a process has to be given access to bind to those ports.

As such, the Caddy systemd service has to be created using the admin user with elevated privileges, even though it will run under the deploy user. The service will contain a definition giving the process the releavant permissions.

But, before we can install the service, let’s create a Caddyfile containing a base configuration as the server can’t start without a config file. The Caddyfile needs to be owned by and under the deploy user’s home directory so it can be modified without connecting as admin.

Instead of reconnecting as deploy, create the config files under the deploy user using sudo, and change their ownership:

sudo mkdir -p /home/deploy/http
sudo touch /home/deploy/http/Caddyfile
sudo touch /home/deploy/http/caddy.global

sudo cat <<STRING >> /home/deploy/http/caddy.global
{
  servers {
    protocols h1 h2
  }
}
STRING

sudo cat <<STRING >> /home/deploy/http/Caddyfile
import caddy.global
import */Caddyfile
STRING

sudo chown deploy:deploy -R /home/deploy

caddy.global contains global settings that apply across all websites on the server. I restrict it to HTTP/1 and HTTP/2 because I find HTTP/3 causes weird connection issues in browsers in between deploys.

The Caddyfile is the main configuration file we’ll pass into Caddy. It loads the global settings and the individual Caddyfiles of all our websites.

The Caddy configuration is held in memory, so if you deploy a new site and need Caddy to pick up it’s config, you’ll need to reload the service. Caddy handles this gracefully with zero downtime.

Then, give the deploy user just enough sudo access to reload and monitor the caddy service.

sudo touch /etc/sudoers.d/deploy

cat << STRING >> /etc/sudoers.d/deploy
deploy $(cat /etc/hostname)=(root) NOPASSWD: /bin/systemctl reload caddy
deploy $(cat /etc/hostname)=(root) NOPASSWD: /bin/systemctl status caddy
STRING

Next, create the Caddy service file:

sudo cat << STRING > /etc/systemd/system/caddy.service
[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=deploy
ExecStart=/usr/local/bin/caddy run --environ --config /home/deploy/http/Caddyfile
ExecReload=/usr/local/bin/caddy reload --config /home/deploy/http/Caddyfile --force
TimeoutStopSec=5s
LimitNOFILE=1048576
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target
STRING

The AmbientCapabilities gives it access to bind to ports 80 and 443 to serve HTTP and HTTPS requests. This access can only be given by a user with elevated privileges, which is why we can’t create this service within the deploy user.

The Ruby app’s service will be created in the deploy user as it doesn’t need elevated privileges.

Enable and start the service:

$ sudo systemctl daemon-reload && sudo systemctl enable --now caddy

Caddy should have started running. Verify it with:

$ sudo systemctl status caddy
$ curl -kv http://localhost:2019/config/

The Caddyfile is blank, so it won’t serve anything yet. Let’s create an app for it to serve.

A basic Rack app

Disconnect your SSH session and reconnect as the deploy user:

$ ssh deploy@<ip-address>

Create a folder for your site named after your domain name:

$ mkdir -p ~/http/example.com

Create a Caddyfile specific to this site, and scaffold an empty Ruby project:

$ cd ~/http/example.com
$ touch Caddyfile
$ bundle init
$ touch config.ru
$ bundle add rack falcon

We’re using Falcon as our server here, but you can use Puma if you wish.

Open up a text editor (I use vim), and create a basic Rack app as shown below:

# config.ru

class App
  def call(env)
    [200, { "content-type" => "text/plain" }, ["It is now #{Time.now.utc}"]]
  end
end

run App.new

You’ll also need to create a Falcon config file:

$ touch falcon.rb

# falcon.rb

#!/usr/bin/env falcon-host

require "falcon/environment/rack"

service "example.com" do
  include Falcon::Environment::Rack

  rackup_path   File.expand_path("./config.ru", root)
  ipc_path      File.expand_path("./application.sock", root)
  scheme        "http"
  protocol      Async::HTTP::Protocol::HTTP
end

The Falcon configuration sets binds the app to a Unix socket at application.sock. It also sets the scheme as http since Caddy handles SSL termination, and the protocol declaration automatically chooses between HTTP/1.1 and HTTP/2 depending on the request.

We run the app on a Unix socket to avoid port clashes with other services. When there are multiple web apps, or multiple instances of an app running on a single server, managing port numbers between all of them would be impossible.

At this point, you can do a quick test to check the app can be run:

$ bundle exec falcon host falcon.rb

Create a second SSH session, change to the site’s directory, and use curl to check if the server is running:

$ curl --unix-socket application.sock http://localhost/

If the request succeeds, close the second SSH session, go back to the first one, and use Ctrl+C to stop the server. Now that we know it works, we can create a systemd service to start it automatically and keep it running.

Running the app using a systemd service

Create the service file:

$ mkdir -p ~/.config/systemd/user
$ touch ~/.config/systemd/user/example.com.service

Add the below code block to the service file:

[Unit]
Description=example.com Web Service
After=network.target

[Service]
Type=notify
NotifyAccess=all
User=deploy
WorkingDirectory=/home/deploy/http/example.com
ExecStart=/usr/bin/env bash -lc 'bundle exec falcon host falcon.rb'
KillMode=mixed
TimeoutStopSec=60
Restart=always

[Install]
WantedBy=default.target

A couple of things to note in the above service:

bash -lc is used to start the server. This loads ~/.profile ensuring chruby loads and the environment variables pointing to the Ruby binary and Gems are set.
KillMode=mixed sends SIGTERM only to the main process when the service is stopped. This allows the server to stop gracefully without dropping requests. If it fails to exit within the timeout, then SIGKILL will be sent to the main process as well as child processes.

Start the service:

$ systemctl --user enable --now example.com

Check that it is running using curl as we did earlier. We can’t access this via the internet as yet because we haven’t pointed Caddy to it.

Configuring the Caddy reverse proxy

Configure Caddy to act as a reverse proxy to the Unix socket for your domain name:

# example.com/Caddyfile

example.com {
  reverse_proxy unix///home/deploy/http/example.com/application.sock
}

Reload Caddy:

$ sudo systemctl reload caddy

You can do this as the deploy user despite it being a sudo command because we gave it specific access for it earlier in this guide.

Your Rack app should now be available at your domain!

Conclusion

Rack underpins every popular Ruby web framework and server, and hence you should be able to use this same techniqe to serve apps built with Rails, Hanami, Roda, or any other framework.

In the next part, we’ll look at an alternate approach where Falcon itself is internet facing, and used for SSL termination and as a reverse proxy for multiple websites. We’ll also discuss why I don’t recommend that approach.

Part 2b. Falcon as a web server for Ruby applications

Part 3. Zero-downtime Ruby deployment without Docker

Server setup for Ruby web applications

2026-07-23T00:00:00+01:00

The ease of using Heroku and other similar platforms means a generation of developers, including me, have never really needed to setup and manage servers during our career. As such, I was a bit afraid of server admin and self-hosting my apps.

Sadly, with the enshittifcation of PaaS providers, and an upward trend in pricing, I could no longer ignore the benefits of self-hosting. For example, Scattergun is one of my side projects with exactly $0 ARR. I’m paying $49/month to host it on Render.com. It needs 1 web service, 1 job runner, a Postgres database, and a Redis instance. All very basic for a Rails app, and at that level, I can probably run it on a single €5.49/month Hetzner box.

The trade-off for the lower price is that I need to do more ops work myself, but again, for small to medium sized apps, I feel this is a worthy trade-off with an efficient deployment setup.

Tools like Kamal have emerged recently to simplify self-hosting. However, nothing tackles the problem end-to-end, from securing the server, to log rotation, to database backups etc.

Kamal also uses Docker, which I’m not keen on as it’s a bit of a behemoth. It makes a lot of sense when you’re deploying to a fleet of servers, but I’ll be deploying to a single server and I feel it’s overkill for that.

This is the first of a series of posts where I’ll desribe my self-hosting setup for Ruby (and Rails) applications that covers the process of deploying apps to a single server end-to-end.

The first step towards self-hosting is to secure the server. In this post I’ll describe the security steps I like to take when I create a new VPS, and the software I install to run Ruby apps.

Creating a VPS

Create a VPS using your preferred cloud provider. I personally use Hetzner. This guide is based on Ubuntu 26.04, but you should be able to adapt it for other distros.

Ensure you configure an SSH key for root access, rather than using a password. Here’s my blog post on managing SSH keys for server access.

Upgrade packages and enable firewall

SSH to your server as root.

$ ssh root@<ip-address>

Then, update all system packages:

$ apt-get update && apt-get -y upgrade

Next, enable the firewall so only SSH, HTTP, and HTTPS ports are open:

$ ufw default deny incoming
$ ufw default allow outgoing
$ ufw allow OpenSSH
$ ufw allow http
$ ufw allow https
$ ufw --force enable

Creating users and restricting permissions

I create two users on my web servers: admin and deploy. admin will have sudo access, and will only be used for the initial server setup. After a server is provisioned, it will never again be used by an automated tool. root login is completely disabled.

Automated tools will connect as deploy to deploy the apps and run related tasks. It will not have sudo access as I’m not comfortable with automated tools running sudo commands, or with web applications running under a user that can gain elevated privileges.

Password login is insecure, and maintaing passwords for multiple servers is unwieldy, so we’ll restrict it and use SSH keys instead.

Create the admin user:

# Add a new user, set the default shell,
# and create a home directory
$ useradd admin -s /bin/bash -m

# Disable password login
$ passwd -ld admin

# Sync the private keys to allow SSH access
$ rsync --archive --chown=admin:admin ~/.ssh /home/admin

# Allow passwordless sudo for `admin`
$ echo "%admin $(cat /etc/hostname)=(root) NOPASSWD:ALL" > /etc/sudoers.d/admin

# Validate the modified sudoers file
$ visudo -c -f /etc/sudoers.d/admin

Disable root login completely as the admin user can now use sudo to gain root privileges. Password authentication is also disabled at system level in the same file.

$ touch /etc/ssh/sshd_config.d/user.conf
$ cat << STRING >> /etc/ssh/sshd_config.d/user.conf
PermitRootLogin no
PasswordAuthentication no
STRING

$ systemctl restart ssh
$ passwd -ld root

Next, create the deploy user:

$ useradd deploy -s /bin/bash -m
$ passwd -ld deploy

# Enable lingering so the user's systemd services keep running
# when the user doesn't have an active session.
$ loginctl enable-linger deploy

$ rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Since the deploy user won’t have sudo access, it can’t create systemd services in the system-wide location: /etc/systemd/system. As such, we’ll create them in the user-specific location: ~/.config/systemd/user/. By default, these services start when the user starts a session and stop after the session concludes. Enabling lingering as demonstrated above ensures services start on system boot and keep running even when the user isn’t connected.

Additional security steps

The below snippet updates several kernel and system settings to harden it against network and file-system attack vectors. I’ve adapted the settings from this script by Javier Ramirez. I won’t get into the details as there’s quite a lot, but you can search for each individual setting to learn more about it if you’re curious.

$ cat <<STRING > /etc/sysctl.d/network-security.conf
# Disable ICMP redirects.
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# ICMP noise hygiene.
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Drop spoofed/martian packets at the door.
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# SYN-flood resilience as the server handles
# port 80/443 traffic from the internet.
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 5

# Hide kernel internals from unprivileged eyes (kernel pointer leaks, dmesg,
# perf side channels) and disable unprivileged eBPF.
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.perf_event_paranoid = 3
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2

# Only processes with CAP_SYS_PTRACE may ptrace.
kernel.yama.ptrace_scope = 2

# Block runtime kernel replacement via kexec (one-way until reboot).
# CAVEAT: if you ever set up kdump crash dumps, remove this line first.
kernel.kexec_load_disabled = 1

# Filesystem link/dump hardening.
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.suid_dumpable = 0

# Turn off Martian logging
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.default.log_martians = 0
STRING

$ sysctl --system >/dev/null

For additional security, install fail2ban to block IPs trying to brute force SSH access to the server:

$ apt-get install fail2ban -y
$ touch /etc/fail2ban/jail.local
$ cat << STRING >> /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1d
findtime = 10m
maxretry = 5

[sshd]
enabled = true
STRING

$ systemctl enable fail2ban

And finally, install molly-guard to prevent accidental reboots. This requires the user to enter the server’s hostname to reboot it, or run reboot.no-molly-guard to bypass the check. It adds an additional layer of scrutiny to avoid accidental reboots.

$ apt-get install molly-guard

Reboot the server for changes to take effect:

$ reboot.no-molly-guard

root connections to the server will no longer be possible after reboot. Use admin instead. You may wish to add some additional layers of security, but this provides a good baseline.

Here’s a script with all the above steps: https://gist.github.com/ayushn21/41b1ceb4fc2651d7d849c432c0a4fa05.

Next, we’ll install the prerequisite software to run Ruby apps.

Installing Ruby prerequisites

Re-connect to your server as the admin user:

$ ssh admin@<ip-address>

Install Ruby’s prerequisites:

$ sudo apt-get install curl jq xz-utils build-essential zlib1g-dev \
  libyaml-dev libssl-dev libncurses-dev libffi-dev \
  rustc libjemalloc-dev -y

The above list includes rustc to enable YJIT, and libjemalloc-dev to use jemalloc for enhanced memory management.

I prefer using ruby-install and chruby to install and manage multiple Ruby versions, rather than alternatives such as rbenv. I feel it has a cleaner approach as it works by configuring environment variables, rather than using shims to intercept commands and direct them to the correct Ruby binary.

Install both utilities:

# Install ruby-install
$ wget https://github.com/postmodern/ruby-install/releases/download/v0.10.2/ruby-install-0.10.2.tar.gz
$ tar -xzvf ruby-install-0.10.2.tar.gz
$ cd ruby-install-0.10.2/
$ sudo make install
$ cd ..
$ rm ruby-install-0.10.2.tar.gz
$ rm -rf ruby-install-0.10.2/

# Install chruby
$ wget https://github.com/postmodern/chruby/releases/download/v0.3.9/chruby-0.3.9.tar.gz
$ tar -xzvf chruby-0.3.9.tar.gz
$ cd chruby-0.3.9/
$ sudo make install
$ cd ..
$ rm chruby-0.3.9.tar.gz
$ rm -rf chruby-0.3.9/

Disconnect from the admin user:

$ exit

Installing Ruby

Install Ruby as deploy as that’s the user the apps will be run under.

$ ssh deploy@<ip-address>

$ ruby-install --no-install-deps --cleanup ruby -- --enable-yjit --with-jemalloc --disable-install-rdoc

Building Ruby will take a bit of time. After it completes, enable chruby by sourcing its scripts in your .profile:

$ cat <<EOF >> ~/.profile

# Use chruby to auto-switch Ruby versions
source /usr/local/share/chruby/chruby.sh
source /usr/local/share/chruby/auto.sh
EOF

Finally, source the scripts into your current session, set a default Ruby, and setup bundler.

$ source /usr/local/share/chruby/chruby.sh
$ source /usr/local/share/chruby/auto.sh

$ rm -f -- ~/.ruby-version
$ echo $(chruby) > ~/.ruby-version
$ echo 'gem: --no-document' >> ~/.gemrc

$ gem update --system
$ gem install bundler
$ bundle config set --global without 'development test'

The server is now ready to serve Ruby applications. In the next couple of posts, we’ll explore two different deployment setups.

Part 2a. Serving Ruby apps with Caddy as a reverse proxy

Part 2b. Falcon as a web server for Ruby applications

Binary Solo

Generating self-signed certificates for web services

Creating the certificates

Securing PostgreSQL with self-signed certificates

Securing Redis with self-signed certificates

Conclusion

Further reading

Anatomy of a Ruby gem

Structure of a gem

Directory skeleton

The gemspec

Writing code for the package

Setting up the test suite

Building and releasing the gem

Distributing your gem

Wrapping up

Deploying Rails apps to a server using Mimas

Adding Mimas to your app

Deploying your app

Further reading

Redis server setup for Rails apps

Installing Redis

Configuring Redis

Redis and Mimas

Further reading

PostgreSQL server setup for Rails apps

Installing PostgreSQL

Configuring PostgreSQL

The configuration files

Creating a role and database

Database backups

pg_dump

Conclusion

Further reading

Ruby installation and management with rv

What is rv?

Installing Ruby with rv

Switching Ruby versions with rv

rv in my workflow

Further reading

Zero-downtime Ruby deployment without Docker

Copying code to the server

Starting and health-checking new server process

Switching the reverse proxy and stopping the old service

Automation

Introducing Mimas

Further reading

Falcon as a web server for Ruby applications

Initial setup

Authbind

Certbot

A basic Rack app

Bootstrapping an SSL certificate

Issuing a self-signed certificate

Responding to the ACME challenge

A systemd service

Why this setup is a bad idea

Serving Ruby apps with Caddy as a reverse proxy

Why use a reverse proxy?

Installing Caddy

A basic Rack app

Running the app using a systemd service

Configuring the Caddy reverse proxy

Conclusion

Server setup for Ruby web applications

Creating a VPS

Upgrade packages and enable firewall

Creating users and restricting permissions

Additional security steps

Installing Ruby prerequisites

Installing Ruby

`pg_dump`

What is `rv`?

Installing Ruby with `rv`

Switching Ruby versions with `rv`

`rv` in my workflow