Product Introduction

Purpose and Scope

Dub is a modern open-source link attribution platform: it starts with short links, then connects those links to conversion tracking, analytics, and affiliate-program workflows. In practical terms, a team uses Dub to turn destination URLs into branded, trackable short links; distribute those links across campaigns or partners; and understand what happens after the click. The supplied docs describe links as the bread and butter of Dub, and that framing is important: everything else in the product depends on a durable link resource that can be created in a dashboard, managed programmatically, and measured over time.

The repository is organized as a monorepo for the hosted product, public developer tooling, and shared packages. The root package manifest identifies the repository as private, uses pnpm workspaces through the package manager declaration, and exposes Turborepo scripts for build, development, linting, package publishing, and tests. It also declares an AGPL-3.0-or-later license at the monorepo level, while the separately published CLI package is MIT licensed. That distinction helps readers separate the open-source application posture from a public npm tool intended to be installed and used independently. Sources: package.json, packages/cli/package.json

The product is not only a URL shortener. A short link is the entry point for attribution: it contains the destination URL, a public short URL, a domain, and a key or slug. From there, Dub can support higher-level features such as custom link previews, conversion tracking, and affiliate programs. The official docs also describe using Dub on subpaths through rewrites, which reinforces the platform goal: Dub is designed to fit into a company’s existing web presence rather than forcing every campaign onto an unrelated domain.

Relevant Source Files

• package.json: Defines the monorepo name, AGPL license, pnpm version, Turborepo scripts, and package publishing commands that frame Dub as a multi-package product repository.
• packages/cli/src/index.ts: Defines the public dub command, its description, version flag, and top-level command groups for login, config, domains, shortening, and links.
• packages/email/src/index.ts: Exposes email sending primitives that choose Resend when configured and fall back to SMTP through nodemailer when available.
• packages/ui/src/index.tsx: Exports the shared UI component, hook, layout, content, icon, and miscellaneous building blocks used to present the product experience.
• packages/utils/src/index.ts: Re-exports shared constants and utility functions as a central utility package entry point.
• packages/cli/package.json: Defines the published dub-cli package, the dub binary, package metadata, npm export shape, runtime dependencies, and MIT license.

Core Product Primitives

The first primitive is the link. In the official product docs, the minimum field needed to create a short link is the destination url; the returned model includes identifiers and public routing fields such as id, shortLink, domain, and key. Those fields explain why links are the center of the system: they are both a user-facing campaign asset and a programmatic object that can be created, listed, updated, and deleted at scale. A marketer may think in terms of branded links, while an engineer sees a resource that can be managed through API and CLI workflows.

The second primitive is attribution. Attribution means connecting user actions back to the link or campaign that influenced them. Dub’s product positioning combines short links with conversion tracking, so the link is not the end of the workflow. After distribution, downstream events such as leads, sales, opens, and partner activity can be connected to the original link. That relationship lets teams compare channels, partners, and campaigns using something more meaningful than raw clicks. It also explains why analytics, API schemas, and notification packages are first-class parts of the repository rather than optional add-ons.

The third primitive is the workspace-facing product surface. The shared UI package exports components such as buttons, forms, tables, modals, filters, pagination controls, inputs, date pickers, status badges, link previews, UTM builders, and advanced-link-feature tooltips. Those exports indicate that the product presents links and attribution workflows through a rich dashboard, not only through API calls. The UI package is also broad enough to cover operational screens, analytics surfaces, content blocks, navigation, and feedback states, which are all needed when users manage many links or collaborate across teams. Sources: packages/ui/src/index.tsx

Developer and User Entry Points

Dub exposes a public CLI for users who want to work from the terminal. The CLI entry point creates a Commander program named dub and describes it as a CLI for shortening links with the Dub API. It wires in top-level command groups for login, config, domains, shorten, and links, which maps directly to common first-run tasks: authenticate, choose or inspect configuration, manage domains, create a short URL quickly, and perform broader link management. The command also supports a version flag sourced from package metadata. Sources: packages/cli/src/index.ts

dub --version
dub login
dub config
dub domains
dub shorten https://example.com
dub links

The CLI package manifest shows how that terminal surface is distributed. The npm package is named dub-cli, publishes a dub binary from dist/index.js, exports built JavaScript and type declarations, and marks itself as preferably global. Its runtime dependencies include commander for command structure, configstore for local configuration, dub for API access, open and OAuth support for login flows, prompts for interactive input, and zod for validation. This package-level contract matters because it turns Dub’s API into a convenient workflow for developers, growth teams, and automation scripts. Sources: packages/cli/package.json

The repository also exposes shared packages that support product consistency. @dub/utils is represented by a narrow entry point that re-exports constants and functions, which gives application and package code a shared place for cross-cutting behavior. The email package exposes sendEmail and sendBatchEmail, and these functions choose Resend when configured, otherwise fall back to SMTP when SMTP_HOST and SMTP_PORT exist. In product terms, that supports operational communications such as import results, payout notices, partner-program updates, or other transactional notifications without hard-coding a single provider. Sources: packages/utils/src/index.ts, packages/email/src/index.ts

System-to-Code Mapping

This mapping is useful because Dub’s product scope spans more than one interface. A new user might begin in the dashboard, an engineer might create links through the API, and a power user might install the CLI. All three paths still share the same conceptual model: a link is created, configured, distributed, and measured. The monorepo layout mirrors that model by keeping public tooling, reusable UI, shared utilities, and communication infrastructure in dedicated packages while the root scripts coordinate builds and releases across the workspace.

Product Workflow

A typical Dub workflow starts by deciding where a link should send traffic. The destination URL is the essential input, and Dub turns it into a short link with a domain and key. If a company needs branded distribution, it can use custom domains or even route a subpath from an existing site to a Dub-managed subdomain through framework rewrites. If a campaign needs better social performance, the docs describe custom link previews with image, title, and description fields. These features keep the link useful in real marketing contexts, where trust, branding, and presentation affect click-through rates.

Once links are live, the workflow shifts from creation to measurement. Because Dub is positioned around link attribution, the value of a link is not only whether it redirected successfully; it is whether it helps explain campaign outcomes. Conversion tracking and affiliate-program concepts extend the link model into relationships between clicks, events, partners, commissions, and payouts. The email package’s delivery abstraction supports that operational side by allowing product workflows to notify users through Resend or SMTP depending on deployment configuration. Sources: packages/email/src/index.ts

For developers, the CLI and package scripts make the product approachable from automation environments. The root manifest includes publish commands for the CLI, embed packages, UI, Tailwind config, and utils, which shows that Dub intentionally maintains public packages around the core application. The CLI’s command groups then provide a task-oriented bridge to the hosted API: authenticate once, configure the environment, choose domains, and manage links. This complements SDK-based usage from the official docs, where code can create links programmatically using an API token. Sources: package.json, packages/cli/src/index.ts, packages/cli/package.json

Next Steps

Start with the link model when learning Dub: understand the destination URL, short URL, domain, and key before moving into analytics or partner workflows. Then choose the interface that matches your task. Use the dashboard and shared UI-driven workflows for collaborative campaign management, the API or SDKs for bulk automation, and the dub CLI for terminal-first shortening and configuration. After that, read the pages on links, conversion tracking events, analytics, custom domains, partner programs, and CLI workflows to see how each product surface builds on the same attribution foundation.