Hotwire starter

The Hotwire starter is a server-rendered Rails 8.1 monolith with Supabase Auth bolted in through supabase-rails in :web mode. Sign-in, sign-up, password reset, OTP / magic-link, and GitHub OAuth all run through the gem's controllers; the browser holds an encrypted sb-session cookie, not a token. Every request through the Rails app forwards that cookie to Supabase, the gem's middleware unwraps it into Current.user, and controllers render Turbo-powered HTML.

What is it

A Rails 8.1 monolith pre-wired with the pieces a Hotwire app needs the day it ships:

• Cookie-backed auth — supabase-rails in :web mode mints an encrypted sb-session cookie (AES-GCM), refreshes the underlying Supabase access token transparently, and exposes Current.user plus a per-request RLS-scoped Supabase client to every controller.
• Hotwire — Turbo Drive, Turbo Frames, Turbo Streams, and Stimulus are all wired into the layout via Importmap; no JavaScript build step.
• ViewComponent — UI primitives (SidebarComponent, UserMenuComponent, ButtonComponent, AvatarComponent, etc.) under app/components/.
• Tailwind v4 + Railsblocks — Tailwind built via tailwindcss-rails, Railsblocks components installed via Importmap pins and CDN CSS/JS.
• Lucide icons — lucide-rails provides the icon helper used across views and components.
• Notes resource — a RLS-governed notes table plus a NotesController that demonstrates the per-request, cookie-overlaid Supabase client pattern.
• Local Supabase — a checked-in supabase/ directory with config.toml and seed migrations boots a full Auth + Postgres stack via supabase start.
• System + E2E tests — Minitest, Capybara + headless Chrome, plus an end-to-end suite under test/e2e/ that runs against a real local Supabase stack.

Who it's for

You should pick this kit when:

• You want a productive server-rendered Rails app — controllers render HTML, Hotwire turns it into a snappy SPA-feeling experience, and you don't want to stand up a separate API tier.
• You want Supabase Auth to own the identity surface (sign-up, email confirmation, OAuth, password reset, magic-link) and let your Rails app focus on domain logic.
• You're comfortable with an encrypted cookie session rather than holding tokens in JavaScript. The browser never sees an access token.
• You'd rather use RLS in Postgres than re-encode authorisation in Pundit policies — every Current.user.supabase call inherits the signed-in user's row-level policies.

If your frontend is a mobile or third-party SPA, look at the Rails API starter — JWT-only, no cookies. If you want a typed React frontend in the same Rails process, look at the Inertia + React starter — same cookie-auth model, different render layer.

What's included

What's not included

The kit deliberately stops short of the post-v1 auth surface so you can grow into it when you need it:

• MFA (TOTP + backup codes), passkeys / WebAuthn, sudo mode, identity verification. All v2 work — the matching gems (rotp, rqrcode, webauthn, bcrypt) are not in the Gemfile, and the settings sidebar has no security section.
• An ActiveRecord User model. Current.user is a value object built from the Supabase session — no shadow users table, no sync drift. Opt into a host-app users table later with bin/rails generate supabase:user_model.
• A JavaScript bundler. Importmap + Propshaft serve everything; there is no package.json, no node_modules, no Vite or esbuild. Add one if your needs outgrow Importmap.
• Background jobs. Solid Queue is configured but unused — the kit ships no jobs.
• Per-target deploy guides. Dockerfile and Kamal config are generic; turning them into a Fly/Render/Heroku flow is left to your platform.
• Production observability. Logs go to STDOUT. Wire your APM (Sentry, Datadog, OpenTelemetry) when you need it.

Next

Repository

• Source: supabase-ruby/starter-kit-hotwire
• Underlying gem: supabase-rails