Overview

Dub is a monorepo for the modern, open-source link attribution platform. At the product level, the repository presents Dub as a system for short links, conversion tracking, and affiliate programs, with the public README emphasizing that it powers high-volume link and click workloads for marketing teams. At the engineering level, the root package metadata shows a private workspace repository governed by the AGPL license, with common contributor operations routed through Turborepo and pnpm workspaces. This page orients new readers before they dive into product concepts, local development, API references, or package-level documentation.

Sources: README.md, package.json, pnpm-workspace.yaml, turbo.json

Purpose and Scope

The primary reader problem this page solves is orientation. Dub is not only a link shortener and not only a dashboard application; it is a larger attribution platform with multiple public surfaces. A marketer may approach it through short links and analytics, a developer may approach it through API clients or the CLI, and a contributor may approach it through a Next.js and TypeScript monorepo. The README establishes the product promise in plain language: Dub is an open-source link attribution platform for short links, conversion tracking, and affiliate programs. The same file points readers toward introduction, technology stack, self-hosting, and contributing material, so the repository itself treats those as first-stop themes rather than afterthoughts.

Sources: README.md

For repository index purposes, it is useful to distinguish product scope from repository scope. Product scope includes link management, analytics, conversion events, and affiliate or partner workflows. Repository scope includes the web application, workspace packages, package publishing workflows, development scripts, formatting, linting, testing, and build orchestration. The root files do not attempt to document every API route or implementation module directly; instead, they provide the entry points that explain how the codebase is organized and how a developer should operate it. Later pages in this wiki should therefore use this overview as a map, not as a substitute for dedicated API, analytics, package, or operations pages.

Sources: README.md, package.json

Relevant Source Files

• README.md — Defines Dub's public product positioning, top-level documentation links, technology stack, self-hosting pointer, contribution guidance, recommended tool versions, local troubleshooting notes, and development seed commands.
• package.json — Declares the monorepo package name, private package status, AGPL licensing posture, pnpm package manager version, root scripts, package publishing scripts, workspace dev dependencies, and dependency resolution overrides.
• pnpm-workspace.yaml — Defines the workspace membership patterns for applications, generated React Email output, first-level packages, and nested embed packages.
• turbo.json — Defines the Turborepo pipeline for build, development, cleaning, and tests, including global environment dependencies, output caching, persistent development tasks, and build dependency ordering.

Product Surfaces

Dub's first product surface is links. The README describes short links as a core pillar, and the official documentation frames Dub Links as a modern link management platform for marketing teams. In practice, links are the resource that connect a public destination, a short branded URL, and subsequent analytics or attribution. A new reader should treat link creation and management as the foundation for most other capabilities: analytics depends on link traffic, conversion tracking connects outcomes back to prior engagement, and affiliate programs rely on trackable referral links. That is why several outline pages break links into product concepts, management workflows, bulk operations, and API references rather than treating them as a single small feature.

Sources: README.md

The second surface is analytics and attribution. The README explicitly names conversion tracking as one of the three headline pillars, and the official help documentation says Dub Analytics is used to understand an audience at large event volume. In the repository map, analytics appears as a web application concern and as an infrastructure concern tied to Tinybird, which is also named in the README technology stack. At the overview level, the important idea is that analytics is not a detached reporting add-on. It is the measurement layer that makes short links useful for teams that need to know where visitors came from, which campaigns performed, and which conversion or partner activity should receive credit.

Sources: README.md

The third surface is partner and affiliate programs. The README lists affiliate programs alongside short links and conversion tracking, positioning this as a first-class area of the product rather than a separate experiment. The official SDK overview also highlights embedded dashboards and the MCP server for managing partner programs with an AI agent, which signals that partner operations span both human dashboard workflows and developer automation. Within this wiki, partner-program concepts are expanded in pages for bounties, commissions, payouts, customers, partners, and integrations. The overview should therefore set the expectation that Dub combines marketing attribution with operational workflows for rewarding partners, inviting collaborators, and measuring referrals.

Sources: README.md

Monorepo Shape and Build Model

The root package metadata identifies this repository as a private monorepo named dub-monorepo. That matters because the package is not intended to be installed as a single public library; instead, individual packages and applications live inside workspace boundaries. The pnpm workspace file includes application directories, generated React Email output, first-level packages, and nested embed packages. This layout explains why repository documentation is split across web app features, package references, integrations, and contributor workflows. A contributor usually works inside a specific app or package, while root-level commands coordinate the whole workspace when building, testing, linting, or publishing release artifacts.

Sources: package.json, pnpm-workspace.yaml

Turborepo provides the orchestration model. The root build script delegates to Turbo, and the Turbo pipeline declares that build tasks depend on upstream builds and produce framework and distribution outputs. Development tasks are marked persistent and uncached, which matches the behavior expected from long-running local servers and watchers. Cleaning is uncached, and tests depend on builds from dependency packages. The global dependency on environment files means changes to environment configuration can affect the task graph. For readers, this means command behavior is intentionally centralized: root scripts are not just shortcuts, they encode the expected execution order and caching rules for a multi-package codebase.

Sources: package.json, turbo.json

Licensing and Contribution Posture

The root package declares the repository license as AGPL-3.0-or-later, and the README includes a license badge pointing to the repository license. In practical terms, this signals an open-source posture with copyleft obligations rather than a permissive package-only license. The package is also marked private, which should not be confused with closed source; it means the monorepo root itself is not published to a package registry. Publicly publishable artifacts are handled through explicit package scripts such as the CLI, embeds, UI package, utilities package, Tailwind configuration, and related integration packages. Treat licensing questions as project-level concerns and individual package publication as release-process concerns.

Sources: README.md, package.json

Contribution guidance in the README is intentionally task-oriented. It tells contributors to open issues for bugs, follow the local development guide to prepare their environment, and submit pull requests for features, quality-of-life improvements, or fixes. It also lists recommended Node and pnpm versions, and it includes common troubleshooting steps for missing database tables and local build failures. This is important because Dub is a full application stack, not a standalone library. Local problems may come from database schema state, stale build artifacts, package manager mismatches, or cached framework output, so contributor onboarding begins with repeatable environment setup before feature work.

Sources: README.md, package.json

Root Commands and Operational Entry Points

At the root, the common commands are deliberately broad. The build, development, lint, clean, and test commands all route through Turbo, while formatting and format checking run Prettier across TypeScript, TSX, and Markdown files. There is also a package-specific build command that filters to the packages directory. These scripts define the first operational vocabulary for maintainers: build everything, run development mode, lint everything, clean generated state, format source files, and run tests. Dedicated pages should expand the exact local workflow, but the root script list already shows that the repository expects contributors to work from the monorepo root when coordinating cross-package changes.

Sources: package.json, turbo.json

pnpm install
pnpm dev
pnpm build
pnpm test
pnpm prettier-check

Publishing scripts are also visible at the root, which is a useful signal about public package surfaces. The CLI, embed core package, embed React package, Tailwind configuration, UI package, and utilities package each have explicit publish commands that build the relevant package with a Turbo filter and then run npm publish from the package directory. That pattern separates development orchestration from release mechanics: normal contributors generally use workspace scripts, while maintainers use targeted publishing scripts for artifacts that leave the monorepo. The presence of these scripts also explains why this wiki includes package reference pages in addition to product and API documentation.

Sources: package.json

System-to-Code Mapping

The mapping above is intentionally compact, but it reveals the central structure of the project. The README is the product and contributor landing page. The package metadata is the operational contract for root commands, package management, and license declaration. The workspace file defines which directories participate in the monorepo. The Turbo configuration defines how tasks are ordered and cached. When a reader asks where a behavior is implemented, this overview should help them choose the right next page: product behavior belongs in concept and guide pages, API behavior belongs in reference pages, package behavior belongs in package pages, and repository operation belongs in local development or publishing pages.

Sources: README.md, package.json, pnpm-workspace.yaml, turbo.json

Next Steps

Start with the Product Introduction if you need the user-facing model of Dub as a link attribution platform. Continue to Quickstart: API and Dashboard if you want to create links and understand the first developer workflow. Use Monorepo and Tech Stack or Local Development when preparing a contribution or self-hosted deployment. For external developer surfaces, move to API Reference Introduction, CLI Reference, Embeds, or the package pages for UI, utilities, and email. This overview is the map of the repository's public shape; the next page should be chosen by the task you are trying to complete rather than by file order.