The best Go SaaS stack in 2026: a complete reference

If you are starting a Go SaaS today, this is the stack I would pick. Every line is an opinion, and every opinion comes from actually shipping with these tools and watching what holds up at 1,000, 10,000, and 100,000 users.

You are welcome to disagree on any of them. The point is to hand you a coherent set so you can stop reading “what stack should I use” posts and start building.

TL;DR

Layer	Choice
Language	Go 1.24+
HTTP router	Standard library `net/http`
Templates	templ
Frontend interactivity	HTMX
Styling	TailwindCSS v4
UI components	templUI
Database	SQLite (production-ready, default) → Postgres (when you actually need it)
Database driver	`modernc.org/sqlite` or `pgx`
Migrations	goose with `.sql` files
ORM	none, hand-written queries with `sqlx` for struct scanning (may move to sqlc in a future release)
Auth	your own code, JWT cookie signed with HMAC (HS256)
Payments	Polar (default) or Stripe Managed Payment, flip via `PAYMENT_PROVIDER` env, more providers coming
Email	Resend (default), more providers like unosend coming
Object storage	any S3-compatible service (R2, S3, B2, DO Spaces, self-hosted MinIO), set the endpoint in env, done
Observability	slog + Sentry
Analytics	Plausible, Umami, or Google Analytics 4 (all optional, pick by env var)
Deployment	Dockerfile included, runs on any VPS (Hetzner, DigitalOcean, Vultr, Linode, Hostinger, Contabo, OVH) with Coolify or Dokploy on top. I run my products on Dokploy on Hetzner.

Pick this stack and start shipping. You can argue about the choices later, when you have a product to argue from.

Why Go in 2026

I covered this in Why I built goilerplate, but the short version:

Single binary deploys. One artifact, any deploy target (Docker, Coolify, Dokploy, Fly.io, systemd on a VPS).
Small memory footprint. Runs on a $5 VPS. You can run a dozen Go SaaS on one box without breaking a sweat.
Stable language. Code from 2018 still compiles.
Standard library that does 80% of what you need.
AI-friendly. Small surface area, fewer hallucinations.
Type safety without ceremony.

If you are coming from Python, Node, or Rails, the things you give up are smaller than you think. The ecosystem is mature for SaaS work, and you skip the 36 months of npm supply chain attacks that the JavaScript side has been dealing with. If you are already on Next.js and looking for a migration path, start here.

HTTP routing: just use the standard library

net/http got method-based pattern matching in Go 1.22. As of 2026 it is the right default for almost every web app.

mux := http.NewServeMux()
mux.HandleFunc("GET /blog/{slug}", blogHandler.Show)
mux.HandleFunc("POST /api/checkout", checkoutHandler.Create)

That is it. Wildcards, methods, conflict detection, all built in. You do not need chi, gorilla/mux, echo, fiber, or gin for an indie SaaS. The standard library is enough.

When you do need middleware, write small functions:

func Chain(handler http.Handler, middlewares ...func(http.Handler) http.Handler) http.Handler {
    for i := len(middlewares) - 1; i >= 0; i-- {
        handler = middlewares[i](handler)
    }
    return handler
}

Done. No framework lock-in.

When to break this rule: if your team is already comfortable with echo or chi, stick with what you know. The performance differences are negligible for SaaS workloads.

Templates: templ

templ is the right templating language for Go in 2026. It is type-safe, composable, IDE-friendly, and compiles to Go code.

templ Card(title string) {
    <div class="rounded-lg border p-6">
        <h2 class="text-xl font-bold">{ title }</h2>
        { children... }
    </div>
}

Alternatives I considered:

html/template (stdlib). Works, but stringly-typed, no compile-time checks. Fine for very small apps.
jet. Faster than html/template, still string-based, less mindshare.
pongo2. Django-style. Fine but not idiomatic Go.
plush, mustache, handlebars ports. All worse in 2026 than templ.

templ has won the Go templating war. Use it.

Frontend interactivity: HTMX

HTMX is a 14 KB JavaScript file that lets you do most of what an SPA does, without an SPA.

<button hx-post="/like" hx-target="this" hx-swap="outerHTML">Like</button>

That replaces a React component, a React Query hook, a fetch wrapper, a toast library, and the state management you would otherwise need.

Alternatives:

Alpine.js. Smaller scope than HTMX (purely client-side state). Pair with HTMX for the cases HTMX cannot handle alone. The combo is enough for 95% of SaaS UI.
vanilla JS. Fine for tiny apps. You will reinvent HTMX eventually.
Stimulus. Rails-flavored alternative. Smaller community in Go.
A React or Vue SPA. Overkill for most SaaS work in 2026. Reach for it when you genuinely need a deeply interactive client app.

HTMX is the floor. Add Alpine when you need client-side state without a server round trip. Skip React unless you have a real reason. For the longer case why server-rendered HTML plus HTMX is the right default in 2026, see the server is back.

Styling: Tailwind v4

TailwindCSS is the right CSS approach in 2026. Utility classes in the markup, design tokens in one config file, dark mode as a class prefix, tiny output bundle.

Tailwind v4 removed the JavaScript config in favor of CSS-only configuration:

@import "tailwindcss";

@theme {
    --color-background: white;
    --color-foreground: #18181b;
}

.dark {
    --color-background: #09090b;
    --color-foreground: #fafafa;
}

Simpler than v3. Faster build. Use it.

Alternatives:

PicoCSS. Class-light. Great for tiny apps. Outgrows you fast.
plain CSS. Fine if you are a CSS perfectionist. Most people are not.
CSS-in-JS. Does not fit the Go stack.

Tailwind for everything.

UI components: templUI

templUI is the shadcn/ui-style component library for Go. Buttons, dialogs, sheets, sidebars, badges, tables, forms, all written in templ and styled with Tailwind.

@button.Button(button.Props{Variant: button.VariantDefault}) {
    Save changes
}

Drop-in components, accessible by default, dark-mode ready, copy-paste-able.

The alternative is rolling your own. Possible, slow, error-prone on accessibility.

Database: SQLite first, Postgres when you actually need it

SQLite is production-ready for the vast majority of SaaS. Pair it with baselite.io (my own service for automated SQLite backups and a multi-database workspace) and you get the operational layer you would otherwise pay Supabase for, at a fraction of the cost.

SQLite with WAL mode handles a few thousand active users for typical CRUD workloads without breaking a sweat.
Postgres when you genuinely need multiple concurrent writers at scale, advanced JSON queries, or multi-region replication.

Drivers:

For SQLite: modernc.org/sqlite (pure Go, no CGO). Compiles to a static binary.
For Postgres: jackc/pgx (best-in-class Postgres driver). Either pgx/v5 directly or via database/sql.

Skip ORMs. Use sqlx for struct scanning and named parameters on top of database/sql. The combo is fast, simple, and transparent. You write the SQL, sqlx maps the rows into your structs, and you have no ORM layer fighting you when a query gets weird.

Migrations: goose

pressly/goose is the right migration tool in 2026.

-- migrations/20260515_add_users.sql
-- +goose Up
CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL UNIQUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- +goose Down
DROP TABLE users;

Run on startup. Idempotent. Works on sqlite and Postgres.

Alternatives:

golang-migrate/migrate. Fine. Slightly less ergonomic.
dbmate. Fine. Non-Go-specific.
Atlas. Newer, fancier, learning curve.

Pick goose, move on.

ORM: do not

Use sqlx on top of database/sql. It is a thin wrapper that adds struct scanning and named parameters. You write the SQL, sqlx maps the rows into your structs, and there is no ORM layer fighting you when a query gets weird.

type User struct {
    ID    int64  `db:"id"`
    Email string `db:"email"`
}

var user User
err := db.GetContext(ctx, &user, "SELECT id, email FROM users WHERE id = $1", userID)

The SQL is right there for inspection. There is no runtime ORM overhead. The 5% of queries that need to be hand-rolled do not need to fight against an ORM. This is what goilerplate ships today, and it has carried real products without issue.

A future release of goilerplate may move to sqlc for compile-time code generation from .sql files. The patterns are similar and the migration is mechanical. Until then, sqlx is the stable default. GORM, ent, and bun are fine if you came from a heavy-ORM background, but the thin database/sql plus sqlx path is the leanest for indie SaaS.

Auth: your code

For a SaaS web app, do not pull in a third-party auth service. Write your own. The Go ecosystem makes this easy:

Cookie-based session via JWT signed with HMAC (HS256). golang-jwt/jwt/v5 is the standard.
HttpOnly, Secure, SameSite=Lax cookies.
Password hashing with bcrypt at cost 10 to 12.
OAuth callback handlers for the providers you support (Google, GitHub).
Magic link generation and verification.
Password reset with hashed, single-use, time-limited tokens.
CSRF tokens for state-changing forms.
Rate limiting on auth endpoints.

This sounds like a lot. It is a couple of days of focused work. After that you own it forever, you understand every edge case, and you do not need to chase another library’s breaking changes.

If you want this already wired up: goilerplate ships magic-link auth, OAuth via Google and GitHub, password reset, email change verification, account deletion, CSRF middleware with token rotation, and rate limiting middleware. Out of the box.

Payments: Polar or Stripe

Both wired up in goilerplate out of the box. A single env variable (PAYMENT_PROVIDER=polar or PAYMENT_PROVIDER=stripe) flips between them. The provider interface is extensible, so more options are on the roadmap.

Polar is the current default. Merchant of Record (handles VAT and sales tax for you), modern API, clean Go SDK. Best fit for indie SaaS that wants the tax burden off the table from day one.

Stripe Managed Payment is now public (out of private beta). Same Merchant of Record model on Stripe’s infrastructure. If you are already on Stripe, this is the natural fit. I may flip goilerplate’s default here in a future release as the product matures.

Classic Stripe without Managed Payment still works if you have an accountant handling tax. Mature ecosystem, every edge case has been hit by someone before you.

LemonSqueezy (now part of Stripe) is fine if you are already on it.

Email: Resend

Resend is the current default in goilerplate. Modern API, generous free tier, good deliverability if you set up SPF, DKIM, and DMARC on a sending subdomain.

More providers are on the roadmap (likely unosend and others) via the same provider-interface pattern goilerplate uses for payments. A single env variable flips between them.

Postmark is also great if you prefer their style. Skip SendGrid for new projects. Skip Mailgun unless you already use them.

Object storage: any S3-compatible service

For user-uploaded files (avatars, attachments, exports), pick whatever S3-compatible service you want and set the endpoint in env. goilerplate uses aws-sdk-go-v2 so any of these work without code changes:

Cloudflare R2. No egress fees, generous free tier. My default in 2026.
AWS S3. Battle-tested, slightly more expensive due to egress.
Backblaze B2. Cheaper than S3, smaller ecosystem.
DigitalOcean Spaces. If you are already on DO.
MinIO self-hosted. Same Linux box, same S3 API. Useful for full self-host plays.

One S3_ENDPOINT env variable, done. No code change to switch providers.

Observability: slog + Sentry

log/slog in the standard library for structured logging. Wired up across goilerplate.
Sentry for error tracking via slog-sentry integration. Free tier is fine for most products.
Plausible, Umami, or Google Analytics 4 for product analytics. goilerplate ships all three, optional, pick by env var. Plausible and Umami are privacy-friendly; GA4 is what your marketing team already knows.

Deployment: Dockerfile + any VPS + Coolify or Dokploy

goilerplate ships a Dockerfile. From there:

Pick any plain Linux VPS: Hetzner CX22 (around 4 EUR), CAX11 (ARM, cheaper), DigitalOcean droplet, Vultr, Linode, Hostinger VPS, Contabo, OVH, whatever.
Run Coolify or Dokploy on top as a self-hosted Heroku-style PaaS. Git push, zero-downtime swap, done.
Caddy or PaaS-managed Traefik handles HTTPS and reverse proxy.

I run my own products on Dokploy on Hetzner. That combo handles thousands of users on $5 to $15 per month, and you can run a dozen Go SaaS on one $5 box without breaking a sweat. Compare to Vercel plus Supabase plus a managed Postgres plus a transactional email plan at $50 to $150 per month for similar scale.

What I left out

A few popular categories I deliberately did not pick:

Web framework (Gin, Echo, Fiber, Chi). The standard library is enough.
DI framework (uber/dig, fx). Constructors that take their dependencies as arguments is enough.
GraphQL. REST handlers and HTML responses. Skip GraphQL for SaaS unless your customers demand it.
gRPC for internal services. You do not have internal services. You have one binary.
Kubernetes. You have one binary. systemd is enough.

Each one has its place. None of them is the right default for a starting indie SaaS.

The stack in one paragraph

Go 1.24+ on the standard library, with templ for HTML and HTMX for interactivity, Tailwind v4 plus templUI for styling and components, SQLite via modernc.org/sqlite (or Postgres via pgx) with sqlx for struct scanning and goose for migrations, hand-written JWT cookie auth, Polar or Stripe for payments, Resend for email, any S3-compatible object store, slog plus Sentry for observability, Plausible or Umami or Google Analytics 4 for product analytics, deployed via the included Dockerfile to any Linux VPS with Coolify or Dokploy on top.

This stack ships fast, runs for under $15 per month, and carries you a long way before architecture becomes the bottleneck.

If you want this already assembled, goilerplate is exactly this stack: opinionated, tested, and small enough that AI coding tools (Claude Code, Cursor, Copilot) keep it in working memory and write code that follows the patterns. Starting at $99 launch (regular $199), one-time, lifetime updates. New features and blocks ship into the repo every week.

For the founder story behind this stack, see why I built goilerplate. For the head-to-head against Next.js boilerplates, see goilerplate vs supastarter vs ShipFast. For the cost math on building it yourself, see boilerplate saves you 200 hours.

Pick a stack once and stop researching. The product is the part nobody else can build for you.