Rails Pulse has two distinct jobs: instrumentation (collecting and writing metrics) and the dashboard (reading and displaying them). These can run together or be separated depending on your needs.

The three modes

1. Embedded (default)

The dashboard runs inside your main Rails app. Mount the engine and everything works out of the box.

# config/routes.rb
mount RailsPulse::Engine, at: "/rails_pulse"

Instrumentation and the dashboard share your app’s process, connection pool, and lifecycle. If your app is down, so is the dashboard.

Best for: Development, low-traffic apps, getting started.

Full setup guide →

2. Standalone dashboard process

The dashboard runs as a separate process on the same server, started with rails_pulse_server. Your main app continues to handle instrumentation and writes metrics to the database — the standalone process just reads from that same database.

bundle exec rails_pulse_server  # starts on port 3001

The dashboard stays up even when your main app is restarting or under load. It has its own port, its own session middleware, and a /health endpoint for load balancers.

Best for: Production apps on a single server, Kamal deployments, keeping the dashboard available during deploys.

Full setup guide →

3. Separate instance

Your main app runs instrumentation only (mount_dashboard: false). A completely separate server or pod — on different infrastructure — runs rails_pulse_server and serves the dashboard.

# Main app — instrumentation only
RailsPulse.configure do |config|
  config.mount_dashboard = false
end

Both connect to the same database, or you can give Rails Pulse its own dedicated database entirely.

Best for: Kubernetes, compliance requirements, zero resource contention between monitoring and application traffic.

Full setup guide →

Comparison

How data flows in every mode

Regardless of which mode you choose, the data pipeline is identical on the collection side:

1. OperationSubscriber hooks into ActiveSupport::Notifications and accumulates per-operation data (SQL queries, template renders, cache reads, etc.) into RequestStore during the request
2. RequestCollector middleware grabs everything from RequestStore after the response is built
3. Tracker fires an Async { } fiber to write Route, Request, and Operation records to the database

The database is the only communication channel between the main app and a standalone/separate dashboard process — there’s no API, no message queue, no pub/sub.