Cloud Server for Ruby on Rails in Europe
Ruby on Rails remains one of the most productive web frameworks for building full-stack applications. Its convention-over-configuration philosophy lets small teams ship fast. But Rails needs a real server - a properly sized, always-on machine that can handle requests, background jobs, and asset compilation. For teams serving European users, that server should be in Europe.
Why EU hosting matters for Ruby on Rails
Rails applications are full-stack by nature. They serve HTML, handle authentication, process payments, send emails, and often manage file uploads. Every one of these operations involves personal data from your users. Under GDPR, that data must be processed on infrastructure within the EU if you are serving EU residents.
Network latency matters for Rails specifically because its request cycle is synchronous by default. A Rails app renders HTML server-side, which means users feel every millisecond of round-trip time. Hosting in Prague gives you 5-20ms to most of Western and Central Europe, compared to 100-150ms from a US-based server.
Background jobs via Sidekiq also benefit from EU hosting. If your jobs send transactional emails, process webhooks, or sync with EU-based third-party services, keeping everything in the same region reduces latency for those operations too.
Minimum server requirements
Rails is more resource-intensive than lighter frameworks. Asset compilation with Propshaft or Sprockets is particularly demanding.
- RAM - 2 GB minimum for running Puma and the Rails app. Asset compilation with
rails assets:precompilecan spike to 1.5-2 GB on its own, so 4 GB is strongly recommended for production deployments that compile assets on the server. - CPU - 2 cores minimum. Puma's multi-threaded model benefits from real CPU parallelism. 4 cores is ideal for medium-traffic applications.
- Disk - 20 GB minimum. PostgreSQL data, uploaded files (if stored locally), logs, and the Ruby gem cache add up. SSD is required for reasonable database performance.
- Ruby - Version 3.2 or later. Ruby 3.3 offers significant performance improvements over 3.1.
- Bundler - Version 2.4 or later for reliable gem dependency management.
- PostgreSQL - Version 15 or later. Rails' Active Record works best with PostgreSQL for production use.
Recommended DCXV configuration
DCXV cloud VPS plans start at EUR 15/month. For a small Rails application with light traffic, the entry plan covers the minimum. For a real production deployment with background jobs and database, the 2-core / 4 GB RAM plan is the practical starting point.
Rails with Sidekiq runs two processes: Puma (web server) and Sidekiq (background jobs). Each needs headroom. On 4 GB of RAM, you can run Puma with 2-3 workers, Sidekiq with 5-10 threads, and still have room for PostgreSQL if it runs on the same server.
For larger applications or those expecting growth, DCXV dedicated hardware from EUR 49/month gives you isolated CPU and RAM with no shared contention. Data centers in Czechia and Portugal serve Central Europe with excellent connectivity. 24/7 engineer support is included in every plan. Contact sales@dcxv.com or see configurations at https://dcxv.com/data-center#cloud
Setup guide
Deploy a Rails application on Ubuntu 22.04 with Puma, PostgreSQL, and Sidekiq.
# Install Ruby 3.3 via rbenv and system dependencies
sudo apt update && sudo apt install -y git curl libpq-dev postgresql postgresql-contrib redis-server nginx
git clone https://github.com/rbenv/rbenv.git ~/.rbenv && echo 'eval "$(~/.rbenv/bin/rbenv init -)"' >> ~/.bashrc
~/.rbenv/bin/rbenv install 3.3.0 && ~/.rbenv/bin/rbenv global 3.3.0
# Install Bundler and application gems
gem install bundler
cd /var/www/myapp && bundle install --deployment --without development test
# Compile assets and run database migrations
RAILS_ENV=production bundle exec rails assets:precompile
RAILS_ENV=production bundle exec rails db:migrate
# Start Puma with systemd (create /etc/systemd/system/puma.service)
sudo systemctl enable puma && sudo systemctl start puma
# Start Sidekiq with systemd (create /etc/systemd/system/sidekiq.service)
sudo systemctl enable sidekiq && sudo systemctl start sidekiq
Performance expectations
A Rails application on a 2-core / 4 GB instance in Prague, with Puma and PostgreSQL co-located:
- Response time - 50-150ms for typical HTML page renders with database queries. Static assets served via Nginx return in under 5ms.
- Throughput - 100-300 requests per second for database-backed pages with Puma running 2 workers and 5 threads each.
- Background jobs - Sidekiq with 10 threads processes 200-500 jobs per minute depending on job complexity.
- Network latency - Under 20ms to Germany, Austria, Poland, and the Czech Republic from Prague.
- Asset compilation - A medium-sized Rails project compiles assets in 60-120 seconds on 2 cores.
Rails in production is not lightweight, but it is well-understood and reliable. With the right server configuration in an EU data center, you get consistent performance and the compliance posture your European users expect.
These are expectations for hardware of this class, not measurements from our own lab. Treat them as a starting point for sizing and measure your own workload: real numbers depend on your data, your queries and your tuning far more than on the provider.
