peasy’s tech stack
like all software projects, developing a simple analytics tool seems like an easy-peasy weekend project — but trust us, it’s not. it has taken us around seven long months to reach this point, and it’s been a battle given the nature of the project. everything must work smoothly from the user's perspective — fast dashboards, intuitive interfaces, and reliable event ingestion that can scale to tens of millions of events as needed. we’d like to share a few words about the tech stack that helps us achieve this.
backend
our backend uses Golang, a blazingly fast language from Google, and runs on AWS EC2. For CI/CD, we use a combination of Kamal and GitHub Actions. Kamal has been fantastic — helping us avoid most headaches involved with setting up production Docker environments.
our primary database is PostgeSQL. instead of using a managed solution like RDS, we chose to self-host PostgreSQL on EC2 instances to minimize cost. while this required more setup effort, we believe we’ve done it well — our database runs with a read replica on standby for redundancy and reliability. managing it ourselves gives us more control over performance tuning and scaling, though it does come with its own challenges, such as handling backups, which we store in an S3 bucket.
we follow the same setup for our events database, ClickHouse, which stores event data like visitors, their visits, and the actions they take. to power all of this, our Golang application runs on Go-Fiber — not for any particular reason other than that we like how it feels — as our framework of choice, along with Go-Ent as our ORM.
While ORMs aren't exactly a hot topic in the Golang community — and mentioning them can feel almost taboo — Ent has helped us speed up development significantly. Since Go-Ent doesn’t support ClickHouse, we write raw SQL queries for that part.
frontend
our frontend — which we've been getting a lot of praise for, I might add — is built on top of Svelte, TailwindCSS, and the lovely Shadcn-Svelte by Huntabyte. our goal was to build a unique and minimal frontend without compromising on speed, and Svelte looked like a great fit. spoiler alert: it was! the compiled nature of Svelte allowed us to build a product that we were confident would be fast at every turn. for hosting, we use Deno Deploy for the app and Cloudflare Pages for the marketing site. Cloudflare Pages is a great solution, and we could have used it for everything, but since we rely on SSR, Cloudflare Workers weren’t quite up to the task — particularly due to this issue with running SSR frameworks like SvelteKit on Cloudflare Workers. Deno Deploy, on the other hand, provides a globally distributed, edge-optimized runtime that fits our needs perfectly.
other honorable mentions include the classic Chart.js as our charting library, Lucide for icons, and Luxon for working with time.
monitoring
then monitoring. we use OpenTelemetry for, well, everything. every machine runs an open-telemetry collector to track system metrics—CPU, memory, disk—the usual suspects. Our API is wrapped in tracer providers to keep an eye on critical services and make sure things move as they should.
our metrics then go to SigNoz. for uptime monitoring on the API, marketing site, and app, we use BetterStack — it keeps an eye on things and emails us when something isn’t quite right.
and contrary to popular modern DevOps wisdom, we don’t ship logs off to some fancy dashboard or convert them into JSON. we keep it simple — plain text logs and grep, and honestly, it works just fine.
this should cover the main technologies that we are using. feel free to try Peasy to see how this all comes together, or contact us if you’d like to learn more details.