Thanks and appreciate your compliment!

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

You are welcome hope it benefits you!

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

Honestly just because its the most popular so more people can pick it up easily.

But the frontend and backend arent tightly coupled at all.

You can swap Next for Vite, Nuxt, whatever you want and connect it to the same Go backend.

Only thing you'd need to copy over is some auth and billing related stuff on the frontend side

Just checked yours, it is really helpful for those who want to start quickly, some people won't use mine because it is too much for their use case.

Thanks for your feedback, and I am always open for any questions!

Tbh not yet, I heard that it’s more user friendly, but I go with gin because it has larger community and support!

Would love to explore different libraries

Thanks man, really appreciate 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

Fair point. For what its worth I did add a script that runs tests and checks coverage. But yeah the coverage itself could be better, working on it

PRs welcome if anyone wants to help out

Eh, don’t let other people define what is acceptable for production. Tests are nice but for most boilerplate type things nobody (and I mean NOBODY) writes unit or even integration tests. If you are deploying with the tolerance that you need this stuff to be automatically verified then you’re probably going to be running automated e2e UI tests anyway, and those will naturally uncover regressions and other issues with your auth backbone and other basics.

Source: self, from “shipping to production” for multiple decades

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?

You are more than welcome!

If you need anything don’t hesitate to reach out, you can find my info in the repo