Herald: an open-source (Apache-2.0), self-hosted foundation that ships all of it connected in one codebase: • Multi-tenant auth (OAuth, passkeys, RBAC, cross-app SSO) • Billing via Stripe & Creem — a purchase grants access and credits, a refund or churn revokes them • A credits system built for AI/metered pricing: top-ups, expiry, per-user ledgers, rolling quota windows • An admin console, audit trails, white-labeling, custom domains
Hey Product Hunt 👋
I'm Tim, the solo developer behind Herald.
I kept running into the same problem while building AI products: before writing a single line of the actual product, I'd spend weeks stitching together auth, multi-tenancy, Stripe webhooks, entitlements, usage credits, and an admin console. Every AI product needs them, none of them are what users pay for.
So I built Herald: an open-source (Apache-2.0), self-hosted foundation that ships all of it connected in one codebase:
• Multi-tenant auth (OAuth, passkeys, RBAC, cross-app SSO)
• Billing via Stripe & Creem — a purchase grants access and credits,
a refund or churn revokes them
• A credits system built for AI/metered pricing: top-ups, expiry,
per-user ledgers, rolling quota windows
• An admin console, audit trails, white-labeling, custom domains
The whole codebase is meant to be modified — it's designed as a starting point for AI-assisted iteration, not another black-box auth API.
Honest status: Herald is early-stage (v0.5.1) and looking for its first real-world users. There's a live demo at auth.fornetcode.com and a one-command quick start on GitHub. I'd genuinely love your feedback — especially if you're building an AI product and have fought this infrastructure battle yourself.
What would you need to see before trusting a project like this with your auth and billing?