Running on Kubernetes or need full infrastructure isolation? This page covers running the dashboard as a separate process on the same server. For running Rails Pulse on completely separate infrastructure — including Kubernetes sidecar and isolated deployment patterns — see Separate Dashboard.

Overview

For production environments, you can run the Rails Pulse dashboard as a standalone process, completely separate from your main Rails app. This provides several benefits:

• Dashboard remains accessible when main app is under heavy load
• Separate resource allocation for monitoring vs application
• Enhanced security — isolate dashboard access from your public app
• Independent scaling — dashboard doesn’t scale with your app instances

Quick Start

The dashboard is a mounted engine. It needs your app’s models, routes, and config/initializers/rails_pulse.rb (authentication, database connection), so the server must start from your Rails application’s root directory. It loads config/environment.rb from there and refuses to boot without it.

cd /path/to/your/app
RAILS_ENV=production SECRET_KEY_BASE=... bundle exec rails_pulse_server

rails_pulse_server wraps rackup on the gem’s lib/rails_pulse_server.ru; the equivalent explicit command is:

RAILS_ENV=production bundle exec rackup $(bundle show rails_pulse)/lib/rails_pulse_server.ru -p 3001

The standalone server starts on port 3001 by default (PORT or -p override it).

Two environment variables matter:

• SECRET_KEY_BASE — required. It signs the dashboard’s session cookie, and the server refuses to start without it.
• RAILS_ENV — selects the database (from config/database.yml or DATABASE_URL, exactly as your main app does) and decides whether dashboard authentication is on. Authentication is enabled outside development and test, so an unset RAILS_ENV boots an unauthenticated dashboard against the development database.

The session cookie is marked Secure in production, so it is only sent over HTTPS. Terminate TLS at your reverse proxy. For a deliberately non-TLS deployment on a private network, set RAILS_PULSE_INSECURE_SESSION=1.

Read-Only: The standalone process serves only the dashboard. It does not run your app’s middleware, so it records no requests of its own.

Healthcheck Endpoint

The standalone server includes a /health endpoint that verifies database connectivity:

curl http://localhost:3001/health
# Returns: {"status":"ok","mode":"dashboard","database":"connected","timestamp":"..."}

This is useful for load balancers, uptime monitors, and deployment health checks.

Deployment Options

Separate Subdomain (Recommended)

Proxy the standalone server behind nginx on a dedicated subdomain:

server {
    server_name pulse.myapp.com;
    location / {
        proxy_pass http://localhost:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Kamal Deployment

Deploy the dashboard as a Kamal accessory using the same application image, so config/environment.rb and your initializer are present:

# config/deploy.yml
accessories:
  rails_pulse:
    image: your-app-image  # Same image as your main app
    host: your-server
    cmd: bundle exec rails_pulse_server
    env:
      clear:
        RAILS_ENV: production
      secret:
        - SECRET_KEY_BASE
        - DATABASE_URL  # or rely on config/database.yml in the image
    port: "3001:3001"
    healthcheck:
      path: /health
      port: 3001
      interval: 10s
      timeout: 5s

Authentication

The standalone process has your app’s models but not its session store, Warden or Devise helpers, and it runs on its own hostname, so config.authorize and config.authentication_method are ignored here (a notice is logged once per process). Outside development and test it falls back to HTTP Basic against RAILS_PULSE_USERNAME and RAILS_PULSE_PASSWORD, and denies everything when the password is unset.

To run something else, set config.standalone_authentication_method. It follows the same rules as authentication_method: deny by rendering or redirecting, or by returning false.

# config/initializers/rails_pulse.rb
config.standalone_authentication_method = proc {
  authenticate_or_request_with_http_token do |token, _options|
    ActiveSupport::SecurityUtils.secure_compare(token, ENV["RAILS_PULSE_DASHBOARD_TOKEN"].to_s)
  end
}

See Authentication for the hooks the embedded dashboard uses.

Recording deployments

The deployments API is served by whichever process mounts the dashboard, so point CI at the standalone server’s URL, or use the rails_pulse:record_deployment rake task from the main app. See Deployment Tracking.

Next Steps

• Database Setup — Configure a dedicated Rails Pulse database for use with the standalone server
• Authentication — Secure your standalone dashboard