This is really helpful context, thanks for writing it out.
You’re right that Next wants to be your backend and thats exactly why I kept the real backend separate in Go.
The Go backend handles all auth, billing, database, everything.
Next is just a frontend that calls the API. So if Next keeps changing things or pushes too hard toward Vercel, you swap it out. The backend doesnt care.
The white-label / custom domain point is interesting, hadnt thought about that edge case. Good to keep in mind.
Honestly the backend is the important part here. The frontend is just one way to consume it
ConnectRPC looks interesting actually, proper API schema with generated TS client is nice. And that Nuxt dashboard template is clean, hadnt seen that before.
If you spot anything in the repo or have ideas, feel free to open a PR. Or just reach out directly if you wanna chat about the stack. Always down to learn from someone building similar stuff
Thanks! That's exactly why I open-sourced it. Instead of this living in my private repo getting occasional updates, now the community can push it forward. Improvements flow back to everyone, including me. Win-win.
Your IAM separation idea is interesting. Separate origin for auth would tighten the CSP significantly. The backend is already modular, so spinning the auth service into its own container with a stricter policy is doable. Worth exploring. Would you mind opening an issue on the repo so I don't lose track of this?
Totally valid. The Go backend is just a REST API with no Next.js coupling. You could swap the frontend for Go templates + htmx without changing the backend at all.
And yeah, Polar.sh has been great. Merchant of Record means I don't think about tax compliance.
For most CRUD apps, Next.js + tRPC is the right call.
My tipping point was long-running tasks (OCR, AI processing that takes 30+ seconds) and wanting to scale backend compute separately from frontend serving.
If you don't have those needs, stick with what you have.
I realized I was spending the first 3 weeks of every new B2B project just wiring up "boring" infrastructure like Authentication, Team Invites, and Billing webhooks.
I decided to open-source my internal kit (MIT Licensed) to fix this.
The Goal: Help founders skip the plumbing and start building their unique business logic on Day 1.
The Stack:
Backend: Go 1.23 (Modular Monolith with sqlc).
Frontend: Next.js 15 (App Router).
Included: Pre-configured RBAC, Multi-tenancy, Billing (Polar), and a pgvector RAG pipeline.
It’s opinionated, but it saves you from "Decision Fatigue" when launching a new product. Happy to answer questions!
That definitely helps, but I don't think it solves the compromised machine scenario.
If the attacker has shell access to the dev's laptop, they are likely just running commands directly from that machine (or proxying through it). So to GitHub, the traffic still looks like it's coming from the allowed IP.
Allowlists are mostly for stopping usage of a token that got stolen and taken off-device.
This looks useful. I've been exploring similar durable execution patterns in Go recently to avoid the complexity of Temporal for smaller workflows.
How does stepped_actions handle the state between steps? Does it persist to the DB after every single action to handle crash recovery, or is it more optimistic?
The deployment process for this repo has been really smooth for me. I use only docker compose, and traefik for web server.
ngl I ran claude code to help me for deployment, and then I wrote scripts automating deployment of frontend and backend.
All of this I used it for my product apflow.co
If you need to know more, please you can contact me, you will find my info in the repo