Skip to main content

Best Go + HTMX SaaS Starter Kits 2026

·StarterPick Team
golanghtmxsaas-starterboilerplate

The Go + HTMX stack is not a trend. It is a deliberate architectural choice made by developers who have grown tired of JavaScript build complexity, heavy client-side bundles, and the operational overhead of Node.js servers in production. In 2026, a growing number of SaaS founders are choosing Go as the backend and HTMX as the interactivity layer — and the boilerplate ecosystem has caught up. This guide covers the best Go + HTMX SaaS starter kits, what distinguishes them, and when the stack makes sense compared to Next.js boilerplates.

Why Go + HTMX for SaaS

Tiny Binaries, Simple Deployment

A Go application compiles to a single self-contained binary with no runtime dependencies. No Node.js version management, no node_modules, no package.json. Deploy by copying a 10–20 MB executable to a VPS. Run it behind Caddy or nginx. Done.

This simplicity has real operational value at small team scale. When there is no deployment pipeline and no infrastructure team, the binary-drop deployment model is genuinely faster to manage.

No JavaScript Framework Overhead

HTMX is a 14 KB (minified and gzipped) JavaScript library. It extends HTML with attributes like hx-get, hx-post, hx-target, and hx-swap that make HTML elements trigger HTTP requests and replace parts of the DOM with the server's HTML response. There is no virtual DOM, no component lifecycle, no build step for the frontend.

For SaaS UIs that are primarily form-driven — CRUD interfaces, dashboards, settings pages — HTMX delivers a snappy user experience without the complexity of a React or Vue SPA.

Sub-100ms Response Times

Go's concurrency model and compiled performance mean that a typical HTMX partial update round-trip — the HTTP request, the template render, the response — completes in 10–30ms on a regional VPS. Users perceive this as instant, with no loading state required for most interactions.

Compare this to a Next.js API route on a cold Vercel serverless function, which can take 200–600ms on the first request. The Go + HTMX stack has fundamentally different latency characteristics, especially at low request volumes.

Lower Hosting Cost

A Go binary running on a $6/month Hetzner or DigitalOcean VPS handles significant traffic. The same workload on Vercel Pro or a managed Next.js platform costs 5–10x more once you account for function invocations and bandwidth. For bootstrapped founders optimizing for low fixed costs, this difference matters.

The Standard Go + HTMX Stack

Most Go + HTMX SaaS starters share a common set of components:

HTTP Router/Framework: Echo, Fiber, or Chi are the most common choices. Echo and Fiber provide middleware, routing groups, and request binding. Chi is more minimal and closer to the standard library.

Templating: The templ library has become the de facto standard for Go server-side rendering with HTMX. templ compiles Go-flavored HTML templates to Go functions with full type safety. This is a significant improvement over html/template for complex UIs.

Frontend interactivity: HTMX for AJAX requests and DOM swaps. Alpine.js for lightweight client-side state (dropdowns, toggles, modal open/close) that does not need a server round-trip.

Database: PostgreSQL via pgx or sqlc, or SQLite for simpler deployments. sqlc generates type-safe Go code from SQL queries.

CSS: Tailwind CSS, compiled at build time and referenced as a static asset.

Top Go + HTMX SaaS Starter Kits

go-htmx-template (Open Source)

GitHub: github.com/Piszmog/go-htmx-template

An opinionated template for building web applications with Go and HTMX. The stack:

  • Go with templ for server-side rendering
  • HTMX for dynamic partial updates
  • SQLite via sqlc with type-safe query generation
  • Tailwind CSS for styling
  • Playwright for end-to-end testing

This starter is clean and minimal. It does not include auth or payments — it is a structural foundation you build SaaS features on top of. The Playwright E2E setup is a notable addition that most Go + HTMX starters omit.

Best for: Developers who want a clean, minimal starting point without pre-wired auth or payments.

gothstarter (Open Source)

GitHub: github.com/anthdm/gothstarter

Named for the Go + HTMX + Tailwind combination, gothstarter is one of the most-forked Go + HTMX templates. Created by Anthony GG (a popular Go educator on YouTube), the starter provides:

  • Go with templ
  • HTMX + Alpine.js
  • Tailwind CSS
  • Echo HTTP framework

It is intentionally minimal — a structural skeleton rather than a full SaaS kit. The value is in the wiring: templ components that emit HTMX-friendly HTML, an Echo server that handles partial requests, and a Tailwind setup that works with server-rendered pages.

Best for: Developers learning the Go + HTMX + templ stack who want a clean reference implementation.

go-echo-templ-htmx (Open Source)

GitHub: github.com/emarifer/go-echo-templ-htmx

A full-stack application demonstrating user session management and CRUD with SQLite via HTMX and templ. More complete than gothstarter for SaaS patterns:

  • Echo HTTP framework
  • templ templating
  • HTMX for all UI interactions
  • SQLite for local development
  • User session management (cookie-based)
  • CRUD operations with HTMX partial updates

The session management implementation makes this a more practical starting point for SaaS applications that need user accounts. It is not production-hardened (no OAuth, no Stripe) but the patterns are clear and easy to extend.

Best for: Teams that want working auth patterns and CRUD HTMX interactions to learn from.

go-templ-htmx-template (Open Source)

GitHub: github.com/HoneySinghDev/go-templ-htmx-template

A production-oriented template that integrates Echo, templ, HTMX, SQLC, Tailwind, and Alpine.js. More opinionated about the database layer than other starters — it uses sqlc to generate type-safe Go from SQL migrations, which is a better production pattern than raw query strings.

// Example sqlc generated query
func (q *Queries) GetUserByEmail(ctx context.Context, email string) (User, error) {
    row := q.db.QueryRowContext(ctx, getUserByEmail, email)
    var i User
    err := row.Scan(
        &i.ID,
        &i.Email,
        &i.CreatedAt,
    )
    return i, err
}

Best for: Teams who want type-safe database access and Alpine.js for client-side state.

golang-saas-starter-kit (Open Source)

GitHub: github.com/raseels-repos/golang-saas-starter-kit

The most feature-complete Go SaaS starter, though it predates the HTMX wave and uses standard Go templates rather than templ. Includes:

  • PostgreSQL with GORM
  • Role-based access control (RBAC)
  • Account signup and user management
  • Stripe subscription billing
  • Email notifications

This starter fills the gap for teams that need Stripe billing and RBAC out of the box. The tradeoff is that it uses GORM rather than sqlc, which is less type-safe, and does not use templ or HTMX in the modern sense. Worth studying for the Stripe integration patterns.

Best for: Teams that need Stripe billing and RBAC pre-wired and can accept older Go patterns.

saaskit-go (Community)

Several developers have published saaskit-go variants on GitHub that combine:

  • Fiber or Chi for routing
  • templ for server-side rendering
  • HTMX + Alpine.js for interactivity
  • PostgreSQL via pgx
  • goth for OAuth (Google, GitHub)
  • Stripe for billing

Search for saaskit-go on GitHub to find the most recently maintained version. The ecosystem is fragmented — no single saaskit-go has emerged as the canonical reference, but several are production-ready starting points.

Auth Options for Go + HTMX

The main authentication approaches in Go + HTMX SaaS projects:

goth (recommended for OAuth): github.com/markbates/goth provides OAuth 2.0 and OpenID Connect for 75+ providers. It handles the OAuth flow and gives you a structured user object after authentication.

gothic.BeginAuthHandler(w, r) // redirect to provider
// callback
user, err := gothic.CompleteUserAuth(w, r)
if err != nil {
  http.Error(w, err.Error(), http.StatusInternalServerError)
  return
}
// user.Email, user.Name, user.Provider are available

Custom JWT: For email/password auth, implement JWT yourself with golang-jwt/jwt. It is less work than it sounds and gives you full control over the token structure.

Session cookies: The most HTMX-natural auth approach. Server sets an HTTP-only cookie after authentication. Every subsequent HTMX request includes the cookie automatically. No JWT parsing on the client, no token storage.

Comparison: Go + HTMX vs Next.js Boilerplates

FactorGo + HTMXNext.js Boilerplate
Cold start latencyNone (long-running process)200–600ms (serverless)
Response time (P50)10–30ms50–150ms
Hosting cost$6–20/mo (VPS)$20–100/mo (Vercel/managed)
Binary size10–20 MBN/A (Node.js runtime)
Frontend complexityMinimal (HTMX)High (React/RSC)
Developer poolSmaller (Go)Larger (JavaScript)
TypeScriptNoYes
Available boilerplates~20100+
Offline supportNoPartial (RSC)

The Go + HTMX stack wins on performance, hosting cost, and operational simplicity. Next.js wins on ecosystem size, TypeScript, and available SaaS boilerplates. For more on the Next.js side of this comparison, see the best Next.js boilerplates guide.

When Go + HTMX Makes Sense for SaaS

Choose Go + HTMX when:

  • You or your team knows Go and prefers it to JavaScript
  • Your SaaS UI is form-heavy and CRUD-oriented (dashboards, admin tools, internal SaaS)
  • You are optimizing for low fixed costs on a bootstrapped project
  • You want a single binary deployment without managing a Node.js runtime
  • You are building something where server response time is a product feature

Stick with Next.js boilerplates when:

  • Your team is JavaScript/TypeScript-only
  • You need rich client-side interactivity (drag-and-drop, real-time collaborative editing, complex UI state)
  • You need the larger ecosystem of available SaaS starters and plugins
  • You are building consumer-facing apps where the broader JavaScript hiring pool matters

The best Go web boilerplates guide covers the broader Go web ecosystem beyond HTMX if you want to compare routing frameworks and full-stack Go patterns. For Django + HTMX comparisons (Python world equivalent), see best Django HTMX SaaS frameworks.

A Minimal Go + HTMX SaaS Pattern

Here is the core pattern that most Go + HTMX SaaS applications use for an HTMX-powered list with inline add:

// handler: render the list partial
func (h *Handler) ListItems(c echo.Context) error {
    items, err := h.db.GetItems(c.Request().Context())
    if err != nil {
        return err
    }
    return components.ItemList(items).Render(c.Request().Context(), c.Response())
}

// handler: add item, return updated list
func (h *Handler) AddItem(c echo.Context) error {
    name := c.FormValue("name")
    if err := h.db.CreateItem(c.Request().Context(), name); err != nil {
        return err
    }
    items, err := h.db.GetItems(c.Request().Context())
    if err != nil {
        return err
    }
    return components.ItemList(items).Render(c.Request().Context(), c.Response())
}
<!-- templ component -->
<div id="item-list">
  for _, item := range items {
    <div class="item">{ item.Name }</div>
  }
</div>

<form hx-post="/items" hx-target="#item-list" hx-swap="outerHTML">
  <input name="name" type="text" placeholder="Item name" />
  <button type="submit">Add</button>
</form>

The form posts to /items, the handler returns the updated ItemList component HTML, and HTMX swaps it into #item-list. No JavaScript, no state management, no client-side router.

Final Recommendation

For 2026, go-htmx-template is the cleanest minimal starting point for learning the stack. For production Go + HTMX SaaS, extend it with goth for OAuth, sqlc for type-safe database access, and Stripe's official Go SDK for billing. The golang-saas-starter-kit is the best reference for the billing and RBAC patterns, even though it predates the templ/HTMX era.

The Go + HTMX boilerplate ecosystem is smaller than the JavaScript world, but the starters that exist are genuinely production-suitable for the right use cases. If you are already proficient in Go and building a form-heavy SaaS tool, the stack will serve you better than fighting a JavaScript framework you did not choose.

Comments