---
title: What is our tech stack
slug: what-is-our-tech-stack
description: "A list of technologies we use."
humans: ["bu-kinoshita", "vitor-capretz", "rehan-van-der-merwe"]
updated_at: "2025-05-28"
created_at: "2024-06-04"
---

## Back-end

We use [TypeScript](https://typescriptlang.org) and [Node.js](https://nodejs.org) in all our back-end applications.
Where possible, we run them in a serverless environment, this includes using [Next.js](https://nextjs.org) API Routes on Vercel, AWS Lambda
for background jobs, and AWS ECS Fargate for APIs.

To handle spikes in traffic and keep services separate, we use queues. This setup helps us scale parts of the system
without affecting others. We limit the impact of failures by splitting responsibilities between a control plane and a
data plane. The control plane handles requests, and the data plane sends emails.

We currently use [Express](https://expressjs.com) for APIs. We are moving to [Hono](https://hono.dev) for its performance
benefits and simplicity.

## Front-end

We use [React](https://react.dev) with [Next.js](https://nextjs.org) for our dashboard and public website.

For styling we build custom components using [Tailwind CSS](https://tailwindcss.com), [Radix Primitives](https://www.radix-ui.com/primitives), and [Radix Colors](https://www.radix-ui.com/colors).

Since Next.js 15, we primarily use React Server Components to fetch data, while still using [SWR](https://swr.vercel.app) for routes that haven't been migrated yet. We also use [Zod](https://zod.dev) to parse requests and responses into strongly-typed schemas.

## Auth

We use [Supabase](https://supabase.com) for authentication, which gives us the ability to manage multiple sign-in methods including email/password, and OAuth providers.

We built our own organization model on top of Supabase to allow users to be part of multiple teams.

## Deployments

Our workloads are split between [Vercel](https://vercel.com) and [AWS](https://aws.amazon.com).

We choose the best provider for the job depending on the problem we're trying to solve. For example, using Vercel with Next.js allows us to [ship features quickly](/handbook/engineering/how-we-ship-new-features) using Preview Deployments.

## Storage

We use [Postgres](https://postgresql.org) as our main storage system, and the applications consume data using [Drizzle](https://orm.drizzle.team) as the ORM/query-builder.

For analytics purposes, we store data in [Tinybird](https://www.tinybird.co) so we can get aggregate data for various use cases.

We also have [Redis](https://redis.io), used for caching data for fast access.

## Observability

We use a combination of tools to monitor our applications:

- [Datadog](https://datadoghq.com)
- [Grafana/Prometheus](https://grafana.com)
- [AWS CloudWatch](https://aws.amazon.com/cloudwatch)

## Infrastructure

We use [AWS CDK](https://aws.amazon.com/cdk) and [Terraform](https://www.terraform.io) for infrastructure management.

Our CI/CD pipelines are powered by [GitHub Actions](https://github.com/features/actions) along with [Blacksmith](https://www.blacksmith.sh) as a runner.

## Background jobs

We have many background jobs that are triggered from different flows; the goal is to make requests faster by moving non-critical code out of the main path or to perform an action continuously based on some criteria.

Our main tool is [Inngest](https://inngest.com), which provides a great developer experience and helps us visualize and debug background jobs.

## Documentation

Our documentation is written using [Markdown](https://en.wikipedia.org/wiki/Markdown) and is powered by [Mintlify](https://mintlify.com), which lets us focus more on writing the best content we can.

## Webhooks

We use [Svix](https://svix.com) for processing webhooks to our users. It's a great tool that helps us monitor and scale webhooks with automatic retries.

## Testing

We use [Vitest](https://vitest.dev) as our testing framework for unit testing. We don't enforce a specific test coverage, and we try to be reasonable in balancing the amount of tests we write.

We use [Playwright](https://playwright.dev) for E2E testing in our dashboard, which runs automatically on deployment previews.

## Miscellaneous

- [pnpm](https://pnpm.io) as a package manager
- [TypeScript](https://typescriptlang.org) is the default. We try to be very strict about its rules
- [Winston](https://github.com/winstonjs/winston) is our logger library across the board
- [MDX](https://mdxjs.com) is how we write content
- [Biome](https://biomejs.dev) for fast linting and formatting