moh_quz

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

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

I really appreciate your comment, never hesitate to reach out to me if you have any concerns, you can find my info in the repo.

This was extracted from my production apps including (apflow.co).

I stripped out the business logic and keys, then pushed it as a clean starting point.

The "in production you would" comments are guides for where to add your own config.

Single commit because I didn't want my app's git history in an open source repo.

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.

Fair question. The difference for me: Supabase lock-in is deep (their Postgres extensions, auth hooks, edge functions all intertwined).

Stytch lock-in is shallow (just an API behind a ~200 line adapter).

If I swap Stytch for Ory or Auth0, I rewrite one file. The rest of the app doesn't know the difference.

You're not doing it wrong.

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.

Hi HN,

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!

the part about "shifting left" is spot on. feels like we just dumped all the ops complexity onto devs who just want to write code.

honestly unless you're massive, k8s is just overhead. a boring docker compose setup usually solves the problem without the yaml nightmare.

nice to see more go tooling. curious how you handled the lock-free part - was it mostly atomics or just clever channel usage?

always found backpressure tricky to handle without locks.

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?

Good luck with the launch

Really appreciate the transparency here. Post-mortems like this are vital for the industry.

I'm curious was the exfiltration traffic distinguishable from normal developer traffic?

We've been looking into stricter egress filtering for our dev environments, but it's always a battle between security and breaking npm install