Go SaaS boilerplates in 2026: the honest list

September 6, 2026

Search "Go SaaS boilerplate" and you get directory pages that list three Next.js kits and a Laravel one, because the Go entries do not exist or are buried. This is the list I wanted when I started: what runs in Go today, what each kit really includes, and what it commits you to. We sell one of them (GoVueKit), so it sits in the same table under the same questions, and the links go to every project's own page so you can check.

What counts

A SaaS boilerplate is not "a Go web starter". A starter gives you a router, a template layer and a session cookie. A SaaS foundation gives you the five things every product rewrites and nobody wants to: accounts (with the unglamorous flows — reset, verification, two-factor, revocation), organizations (roles and tenant isolation), billing (a webhook handler you can bill through), transactional email (durable, not fire-and-forget) and an admin surface. Kits below are judged on those five, plus the questions that matter in month six: which database, which licence, how it deploys.

Excluded on purpose: go-blueprint and gowebly (generators for a project skeleton, excellent, not SaaS kits), PocketBase (a backend-in-one-file you build a SaaS on, not a SaaS), and the dozens of "Go + HTMX + templ starter" repositories that stop at a login form.

The table

Cells say what each project advertises. Where a page did not say, the cell says so rather than guessing; every name links to the source.

One paragraph each

goilerplate is the most polished of the server-rendered kits, from the author of templUI, and the free tier is genuinely usable: Go, templ, SQLite, SMTP, auth, security headers, tests and CI. The paid tier adds the SaaS parts (subscriptions through Polar or Stripe, S3 uploads, analytics, legal pages). If you want no JavaScript build step and are happy with HTMX or Datastar as your interactivity model, start here. What to check before paying: how organizations and roles are modelled, because "SaaS" on the landing mostly means "individual subscriptions".

Pagoda is a starter kit, and says so: "not a framework". Echo, Ent, type-safe HTML in Go, HTMX, a task queue with a monitoring UI, an admin panel generated from your entities, caching, CSRF, sessions. No payments, and email is a skeleton you finish. It has the largest community of the list (over 3 000 GitHub stars) and the cleanest code to learn from. Pick it when you want to build your SaaS layer yourself on good foundations.

LastSaaS is the newest and the most feature-dense: multi-tenant RBAC, Stripe with per-seat pricing and credit bundles, outgoing webhooks, API keys, white-label theming, an analytics dashboard, even an MCP server for AI-driven admin — MIT-licensed, deployed as one small container on Fly.io. Two things to weigh: the database is MongoDB (fine, but it is the one non-relational choice on this list, and multi-tenant reporting in SQL is a different life), and the README states it was built entirely through conversation with Claude Code. That is not a criticism; it means you should read the tenancy and webhook code before you bill through it, which is true of every kit here.

SaaS Boost Kit pairs a Go API with SvelteKit and PocketBase for the database and admin, with Stripe subscriptions, webhooks and a guest checkout for one-off sales, unit and Playwright tests, and a configurable landing. It is commercial (pricing on the site). The PocketBase choice gives you an admin UI for free and a SQLite file for a database; it also means part of your backend is a framework you extend by hooks rather than code you own.

Go SaaS Startup Kit is the veteran: a set of libraries and a working multi-tenant example aimed at AWS (SES, ECS). It is open source and complete for its era, but check the commit history before committing your own; it predates most of what the Go ecosystem now takes for granted.

go-saas/kit is the outlier: a microservice architecture (Kratos-style) with tenant management, Stripe plans and a React/Ant Design admin. If you already run services and need a SaaS control plane, it is the only kit on the list shaped for that. For a product team of one to five, it is an architecture to grow into, not start from.

GoVueKit — ours — is the only one of the list built around a real SPA embedded in the binary: Vue 3 with TypeScript, Pinia and a typed fetch client, compiled by Vite and served with go:embed, prerendered to static HTML for the public pages so SEO does not need SSR. Go with chi and sqlc on the back, no ORM. Accounts include argon2id, magic links, OAuth/OIDC and TOTP; organizations have owner/admin/member roles and row-level tenancy (non-members get a 404, and a Playwright test proves it cross-tenant); Stripe covers subscriptions and one-time products with idempotent webhooks, refunds and chargebacks; email is a durable queue with French and English templates; the backoffice computes MRR, ARPU and churn from your own tables. Both PostgreSQL and SQLite are first-class: one migration file, the same generated queries, both engines in CI. It is commercial (€199 one-time, perpetual, unlimited projects) and it is a core: a blog, a code generator and a second payment provider were built and then removed, and DECISIONS.md says why.

How to choose

By frontend philosophy. This is the real fork in the Go world. HTMX and templ (goilerplate, Pagoda) give you one language, no Node in the build, and pages that are HTML first; the cost is that anything app-like (an editor, a dashboard with live filters, offline) gets awkward. An SPA (LastSaaS with React, GoVueKit with Vue) costs a second toolchain and gives you a typed contract between front and back and a frontend team can work in. Nobody is wrong here; be honest about what your product's screens look like in year two.

By database. If you may ever want SQLite in production (single-node SaaS, on-prem installs, a customer who wants "just a binary and a file"), only goilerplate and GoVueKit treat it as a target rather than a dev convenience, and only GoVueKit runs the whole test suite on both. If your world is PostgreSQL forever, that stops mattering.

By licence. MIT (Pagoda, LastSaaS) means you can fork and never pay, and also that nobody owes you the next security fix. Commercial with source delivered (goilerplate paid tier, SaaS Boost Kit, GoVueKit) means you pay once and own a repository, with updates for as long as the vendor lasts. Read the restrictions clause: the one that matters is whether client work is allowed.

By what you must read. Count the lines you will own. A kit is not "more" when it contains more; it is more when you can hold it in your head. Ask each vendor for the line count and the migration count; the honest ones will tell you.

Try before you decide

The fastest way to compare is to run them. Pagoda and LastSaaS clone and start in minutes. goilerplate's free tier is a GitHub sign-in away. GoVueKit runs its entire stack from one file, no account, no licence:

curl -fsSLO https://govuekit.dev/labs/docker-compose.yml
docker compose up -d      # app + PostgreSQL + Dex (SSO) + MinIO + stripe-mock + Mailpit

Sign in through SSO, create an organization, invite a teammate, read the invitation in the inbox, open the backoffice. Then read the code of whichever kit you liked — that is the only review that counts.

Corrections welcome: if a cell above is wrong about your project, open an issue on github.com/kOlapsis/govuekit and it will be fixed with attribution.