Solid Cable
Database-backed Action Cable adapter for Rails — replaces Redis as the Action Cable pub/sub backend using the application database (SQLite, PostgreSQL, MySQL). Solid Cable features: SolidCable::Server Action Cable adapter, polling-based message delivery (configurable polling_interval), automatic message cleanup via message_retention config, multi-database support, and Rails 8 default for Action Cable without Redis. Enables real-time WebSocket features in agent apps without Redis infrastructure — particularly valuable for SQLite-based Rails 8 applications on single-server VPS deployments.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Solid Cable messages stored unencrypted in DB — don't broadcast sensitive agent data (credentials, PII) via Action Cable. Channel subscription auth via ApplicationCable::Connection#connect must validate agent identity. solid_cable_messages table accessible to anyone with DB read access.
⚡ Reliability
Best When
Your Rails 8 agent app uses SQLite or wants to eliminate Redis — Solid Cable provides Action Cable pub/sub from your existing database with no additional infrastructure for low-to-moderate WebSocket traffic.
Avoid When
You need high-frequency broadcasting (>100 msg/sec), sub-50ms WebSocket delivery, or are already running Redis for Solid Queue.
Use Cases
- • Agent notification WebSockets without Redis — ActionCable.server.broadcast('agent-#{id}', payload) delivers real-time agent status updates via Solid Cable database pub/sub; agent dashboard shows live status without Redis setup
- • Rails 8 no-Redis real-time — config.action_cable.cable = {adapter: 'solid_cable'} in cable.yml; Rails 8 agent apps get WebSocket broadcasting using existing SQLite database; eliminates Redis as operational requirement for moderate-traffic agent platforms
- • SQLite VPS agent deployment — single-server agent app with SQLite database uses Solid Cable for real-time features; no Redis subscription, no additional process; agent WebSocket events stored and polled from solid_cable_messages table
- • Agent chat channels — ApplicationCable::Channel with stream_from 'agent-chat-#{session_id}' broadcasts agent conversation messages via Solid Cable; browser WebSocket receives messages within polling_interval milliseconds
- • Development WebSocket testing — Solid Cable works identically in development and production without Docker Redis service; agent developers get working WebSockets from rails new without docker-compose setup
Not For
- • High-frequency broadcasting — Solid Cable polls DB for messages; Redis BLPOP delivers in <1ms; for agent systems broadcasting >100 messages/second use Redis Action Cable adapter or Pusher
- • Horizontal scaling with many dynos — Solid Cable's polling works across processes on same DB; for large clusters (>10 processes) Redis adapter is more efficient for Action Cable pub/sub
- • Sub-100ms message delivery — polling_interval default is 100ms; for agent real-time requiring immediate delivery use Redis Action Cable adapter
Interface
Authentication
No external auth — uses existing database connection. Action Cable channel authentication uses Rails session or token via ApplicationCable::Connection.
Pricing
Solid Cable is MIT licensed, maintained by the Rails core team. Free for all use.
Agent Metadata
Known Gotchas
- ⚠ cable.yml adapter must be solid_cable not async — development defaults to async adapter; production needs adapter: solid_cable in config/cable.yml; deploying Rails 8 agent without updating cable.yml falls back to async (in-process only, doesn't work with Puma multi-process); agent WebSocket broadcasts silently fail across processes
- ⚠ polling_interval tuning required — default polling_interval of 100ms means 100ms broadcast latency; agent real-time features needing faster updates require polling_interval: 50 (or lower) at cost of increased DB load; SQLite with high polling creates contention; benchmark for your agent's traffic pattern
- ⚠ solid_cable_messages table grows unbounded without retention — message_retention: 1.day in solid_cable.yml required; without retention config, every broadcast accumulates in DB forever; agent apps with frequent broadcasts fill disk; Rails 8 default sets retention but verify your cable.yml has it
- ⚠ SQLite WAL mode required for concurrent cable connections — multiple Puma threads each polling solid_cable_messages table need WAL journal mode; default SQLite journal mode causes read-write lock conflicts under load; enable WAL: pragma journal_mode: wal in database.yml for agent production deployments
- ⚠ Action Cable DB connections count against pool — each Puma thread running Action Cable polling uses a DB connection; config.action_cable.worker_pool_size (default 4) plus Puma threads must fit within database pool size; agent apps with many concurrent WebSocket connections exhaust connection pool without tuning
- ⚠ Not horizontally scalable without shared DB — Solid Cable works across multiple Puma processes on same DB server; for multi-server agent deployments (load balanced), all processes must share same database; SQLite is per-file (single server only); PostgreSQL or MySQL Solid Cable works across multiple servers sharing same DB
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Solid Cable.
Scores are editorial opinions as of 2026-03-06.