Open-sourcing Quasar Core Engine: Why we cut 53% of dependencies for Community Edition

Hey Product Hunt community! 👋

We’re currently deep in the process of open-sourcing the Quasar Engine under the Apache 2.0 license as Quasar Community Edition.

Quasar is designed as a high-performance, durable tracking layer for multi-chain Web3 transactions across EVM and Solana. As part of our Build-in-Public journey, we wanted to share our approach to decoupling a private SaaS into a lean, self-hosted community node:

1. De-bloating the Stack (77 → 36 dependencies):

We audited our dashboard dependencies and eliminated 41 third-party packages. By stripping away commercial billing, vendor email SDKs, and custom dashboard bloat, we left only the essentials: Payload CMS, Viem, Drizzle ORM, Tailwind v4, and the core TUWA SDK.

2. Pure Infrastructure Utility:

In the TUWA ecosystem, Quasar acts as an L5 storage engine, while end-user UX (modals, lifecycle toasts) lives entirely on the frontend via Nova UI Kit and Pulsar. Community builders don't need SaaS invite flows or paywalls—they just need reliable state ingestion, direct RPC provider ownership, and deterministic webhook delivery.

3. Zero Compromise on Reliability:

We preserved 100% of our core tracking pipeline. 6 out of 8 BullMQ queues remain intact (fast/lazy tracking, webhook delivery, retries), and data integrity is strictly locked against manual mutations in the admin panel.

Next milestone: We're shipping `docker-compose.minimal.yml` (standalone Redis + Postgres) so developers can boot up a complete local Web3 tracking node in under 60 seconds.

Would love to hear thoughts from other devtools builders: when self-hosting developer infrastructure, do you prefer a lightweight, headless node or an all-in-one suite with a built-in UI?