HTMX + Rails
IntermediateWeb AppRails views with HTMX: server-driven interactivity as an alternative or complement to Turbo.
Published 27 September 2026
About HTMX + Rails
HTMX + Rails pairs the productivity of Ruby on Rails with HTMX's server-driven interactivity model. Rails already ships with Hotwire (Turbo and Stimulus) for SPA-like navigation and partial updates, but HTMX offers an alternative that some teams find more explicit and predictable. Where Turbo Drive intercepts all navigation automatically and Turbo Frames scope updates by element ID, HTMX requires explicit hx-* attributes on each interactive element, which can be easier to reason about in complex UIs. PostgreSQL is the database, Tailwind CSS is an optional styling addition, and hosting ranges from an affordable VPS to a container platform.
The integration is straightforward: Rails controller actions detect HTMX requests via the HX-Request header and return partial ERB templates instead of full layouts. An HTMX search input triggers a GET /products?q=foo that returns only the results table HTML, and Rails render partial: fits naturally into this pattern. Stimulus controllers can still handle local JavaScript behaviour without interfering with HTMX server communication.
This stack suits Rails teams who want explicit control over which interactions trigger server calls, prefer HTMX's attribute-based model to Turbo's automatic interception, or are migrating existing Rails apps that predate Hotwire. A VPS keeps infrastructure costs low for Ruby applications that do not require serverless scaling.
Key Features
- ✓HTMX attributes explicitly mark which elements trigger server requests, keeping them predictable and auditable
- ✓Rails controller actions detect HX-Request header and return ERB partials for HTMX swaps
- ✓Active Record ORM with associations, scopes, and schema migrations for PostgreSQL
- ✓Tailwind CSS styling works natively with server-rendered ERB templates
- ✓Stimulus controllers available for local client-side behaviour alongside HTMX
- ✓Low-cost VPS hosting, cheaper than PaaS platforms for Ruby workloads
When to Use HTMX + Rails
- →Rails apps where the team prefers HTMX explicit attribute model over Turbo automatic interception
- →Legacy Rails apps being upgraded with interactive features without a full Hotwire migration
- →Admin panels and data management UIs with live search, inline editing, and filters
- →Teams evaluating HTMX as an alternative to component-library approaches in Rails
Pros
- HTMX explicit attributes make it immediately clear which elements trigger server calls
- Rails ERB partials map directly to HTMX fragment responses, so there are few new concepts for Rails developers
- Hetzner VPS significantly reduces hosting costs compared to Heroku or Railway for Ruby apps
- No conflict with Stimulus: both can coexist in the same Rails app
Cons
- Rails already ships Hotwire, so using HTMX alongside it creates two competing interactivity systems
- A self-managed VPS requires manual server management, with no git-push deploys without additional tooling
- Network round-trips limit interactivity, so it's not suitable for real-time or collaborative UIs
- Ruby memory usage per process is high, so VPS sizing requires care for traffic spikes
Database Options for HTMX + Rails
The standard choice: a full PostgreSQL instance on a managed host or your own server, connected from Rails via ActiveRecord, with complete control over configuration and extensions.
MySQL is one of Rails' three primary supported databases: ActiveRecord's mysql2 adapter maps Ruby models directly to MySQL tables with no code changes beyond the database configuration. A common choice in LAMP-adjacent Ruby deployments.
These are highlighted picks. To see all the tools, check the Databases category.
Hosting Options for HTMX + Rails
A self-hosted VPS running the whole Rails + HTMX app yourself, at the price of managing deployment and updates. Entry-level instances start around €4-5/mo, the cheapest option here.
A container-based platform where the whole Rails + HTMX app deploys as a persistent service, a natural fit for a Puma process holding a live Postgres connection pool. No free tier: the Hobby plan starts around $5/mo in usage credit, plus usage-based billing for CPU, memory, and network.
The same persistent-service model as Railway, with a genuinely free tier for small Rails apps, built-in cron jobs, and its own CDN for static assets. Free-tier services spin down after inactivity; predictable always-on pricing starts around $7/mo.
Runs the Rails app as a container close to users across multiple regions, historically a popular choice in the Rails community for its Docker-native deploy model. Billing is usage-based with only a small free allowance.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
HTMX + Rails Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.
Authentication Add-ons
Add authentication when the app needs user accounts — sign-up, login, and data scoped to a specific user instead of a fully open app.
The ecosystem-standard authentication gem for Rails: registration, password reset, session management, and confirmable/lockable modules out of the box. The default here because it's what nearly every Rails project reaches for; Rails itself ships with no built-in auth system the way Django does.
These are highlighted picks. To see all the tools, check the Authentication category.
CI/CD Add-ons
Add CI/CD when you want a dedicated pipeline for running tests, linting, or multi-stage builds before a deploy goes out. Many hosting platforms already redeploy automatically on every push on their own — a CI/CD tool adds the most value on top of that by gating the deploy on a passing test suite, and matters even more when the hosting choice does not auto-deploy at all, such as a self-hosted server.
Runs the test suite and triggers deployments on every push, directly from the same GitHub repo the code already lives in, with no separate CI service to configure.
These are highlighted picks. To see all the tools, check the CI/CD Pipelines category.
Containerization Add-ons
Add containerization when you want the app packaged the same way across local development, staging, and production, or need to deploy somewhere that isn't a managed serverless platform.
These are highlighted picks. To see all the tools, check the Containerization category.
Observability Add-ons
Add observability when you want to catch errors and performance regressions in production before users have to report them.
Error tracking and performance monitoring with dedicated sentry-ruby and sentry-rails gems, covering both controller errors and background-job failures. Open-source with a self-hosted path, alongside its own managed cloud.
A broader observability platform covering APM, infrastructure metrics, and log management in one dashboard, useful once a team is already running other services worth monitoring alongside this app. Managed-only, with pricing that scales by host and usage rather than Sentry's per-error volume.
These are highlighted picks. To see all the tools, check the Infrastructure & APM category.
Email Add-ons
Add email when the app needs to send account verification, password reset, or notification messages.
A transactional email API for account verification, password resets, and notification emails, sent via Resend's official Ruby SDK from a Rails controller or mailer, with a free tier for getting started.
The established high-volume choice, with dedicated IP addresses and deliverability tooling for apps sending at serious scale. No permanent free plan (a 60-day trial, then paid tiers), so it earns its slot when volume and deliverability matter more than upfront cost.
Payments Add-ons
Add payments when the product is ready to charge for subscriptions or one-time purchases.
Styling Add-ons
Add styling when you want a component or utility-class system to build the UI faster than hand-writing CSS from scratch.
A utility-class CSS framework: styles are composed directly in markup via class names instead of writing separate stylesheet files. The default styling choice bundled by most modern framework CLIs (create-next-app, create-vue, the SvelteKit and Astro starters all offer it), and the base layer shadcn/ui components are built on when that's loaded into the catalog in the future.
These are highlighted picks. To see all the tools, check the CSS Frameworks category.
Interactivity Add-ons
Add client-side interactivity when you want local UI state — toggles, modals, dropdowns, tabs — without a full JS framework or an extra server round trip.
Alpine.js adds lightweight, declarative client-side interactivity on top of this stack's HTMX-driven Rails views: toggling a mobile menu, showing a modal, or switching an active tab, all without triggering a server round trip HTMX would otherwise need. It is included via a script tag, with behavior written as HTML attributes (x-data, x-show, x-on) rather than a build step, keeping the stack's zero-bundler approach intact.
These are highlighted picks. To see all the tools, check the HTML-first Frameworks category.
Analytics Add-ons
Add analytics when you want to measure traffic, track visitor behavior, or understand how people actually use the product.
An all-in-one product analytics platform: event tracking, session replay, feature flags, and A/B testing in one SDK. The richest feature set if you want more than pageviews.
The industry-standard, free analytics platform, with native Google Ads and Search Console integration. Requires a cookie consent banner in most jurisdictions (GDPR/CCPA), and all data lives on Google's infrastructure, the tradeoff the other three picks were built to avoid.
A lightweight, privacy-first analytics tool with no cookie banner required. A good fit for simple traffic metrics without PostHog's broader feature surface.
These are highlighted picks. To see all the tools, check the Web & Product Analytics category.
Frequently Asked Questions about HTMX + Rails
How does this compare to Ruby on Rails Starter (without HTMX)?
Same Rails core; HTMX adds partial-page swaps for specific interactions without a JS framework or build step. Rails already ships its own answer to this problem (Turbo/Hotwire); HTMX is worth it instead if you want a syntax that transfers to non-Rails projects too.
How does this compare to HTMX + Django, HTMX + FastAPI, or HTMX + Laravel?
All four pair HTMX with a different backend. Rails brings ActiveRecord and its own Turbo/Hotwire alternative; Django brings a built-in ORM and admin panel; FastAPI brings async performance; Laravel brings Eloquent and Blade. HTMX itself works the same way on all four, so pick based on which backend fits the rest of the project.
Should I use Devise or Auth0?
Devise is the ecosystem-standard choice: registration, password reset, session management, and confirmable/lockable modules out of the box, self-hosted and free. Auth0 is worth it instead if you'd rather not run the auth logic yourself, or need enterprise features like SSO that Devise doesn't cover.
What's the cheapest way to run this stack?
Self-hosted PostgreSQL and skipping the paid addition tools cost nothing beyond hosting. Every hosting option here (Railway, Render, Hetzner, Fly.io) charges from day one for an always-on process, so expect at least about $5/mo once you're past local development.
Stacks Related to HTMX + Rails
HTMX + Go (Gin)
ProjectGin (Go) serving HTMX-enhanced templates: server-driven UI at Go's native performance.
HTMX + Laravel
ProjectLaravel Blade templates enhanced with HTMX: PHP interactivity without writing JavaScript.
Ruby on Rails Starter
ProjectRuby on Rails with PostgreSQL: convention-driven full-stack web development.
HTMX + Django
ProjectDjango views with HTMX for dynamic UIs without a JS framework.
Scores
Popularity2/5
Rails already has its own native answer to this problem (Turbo/Hotwire), which makes HTMX a smaller niche choice here than in ecosystems with no built-in alternative — capable, but not the Rails community's default reach.
Learning Curve3/5
Rails' conventions (ActiveRecord, views, routing) are well-documented, and HTMX adds only a handful of HTML attributes rather than a new templating language. The adjustment is choosing between HTMX and Rails' own Turbo/Hotwire for the same server-driven-interactivity job.
Flexibility3/5
Rails' ActiveRecord and view layer are opinionated about project structure, and HTMX itself just swaps HTML fragments without adding flexibility on top. Consistent and productive, not a highly configurable setup.
Performance3/5
HTMX's partial-page swaps avoid a full page reload for most interactions, but Rails' request-handling overhead is heavier than a leaner framework, and every interaction is still a server round-trip.
Portability3/5
Rails and HTMX are both open-source with no vendor lock-in, portable to any Ruby-capable host. The main migration cost is Rails' own ActiveRecord/view conventions — HTMX itself adds very little coupling since it's just HTML attributes.
Tools in the HTMX + Rails Stack
Frontend Frameworks
Backend Frameworks
Add-ons (optional — add any, or none)
Authentication
CI/CD
Containerization
Observability
Payments
Styling
Interactivity
Analytics
HTMX + Rails Pricing
Rails, HTMX, Tailwind CSS, Ruby and PostgreSQL are all open-source and free. HTMX adds interactivity without a separate JavaScript build or frontend host, so you only pay for one app server and a database: about $5–20/mo on Railway, Render, Fly.io or Hetzner, with managed Postgres from roughly $6–15/mo if you don't self-host.
Rails, HTMX, Tailwind CSS, Ruby and PostgreSQL are free.
A single app server on Railway, Render, Fly.io or Hetzner; free tiers for testing.
Self-host for free, or use managed Postgres from about $6–15/mo.