---
title: "Targets and deliveries"
description: "Choose what Typeship maintains, then configure where each independently reviewed Target is delivered."
url: https://typeship.dev/docs/projects/targets
markdown: https://typeship.dev/docs/projects/targets.md
section: "Get started"
---
> ## Documentation index
> Fetch the complete documentation index at https://typeship.dev/llms.txt (every page, one line each) or the full text at https://typeship.dev/llms-full.txt.
> Append .md to any docs URL, or send Accept: text/markdown, for the markdown twin of that page.

# Targets and deliveries

Choose what Typeship maintains, then configure where each independently reviewed Target is delivered.

A **Target** is one customer-selected surface Typeship maintains from a Definition:

| Target           | Result                                |
| ---------------- | ------------------------------------- |
| `cli`            | Agent-friendly command-line interface |
| `mcp`            | Search, read, and execute MCP server  |
| `typescript-sdk` | Native TypeScript SDK                 |
| `python-sdk`     | Native Python SDK                     |
| `go-sdk`         | Native Go SDK                         |

All five are peers. A Project can be CLI-only, MCP-only, SDK-only, or any non-empty combination.

More than one Target may use the same generator. For example, public and internal TypeScript SDKs can have different identities, configuration, repositories, and release histories.

Each Target inherits `Project.config` and may store overrides. GraphQL settings remain on the Definition.

Choose a separate Target whenever consumers need a separate package identity, configuration, destination, or release decision. Do not create separate Targets merely because one package is delivered to two places. See [Choose Targets](https://typeship.dev/docs/guides/choose-targets) for concrete combinations.

## Deliveries

Targets answer **what Typeship maintains**. Deliveries answer **where it goes and under what identity**.

| Delivery setting                  | Behavior                                                      |
| --------------------------------- | ------------------------------------------------------------- |
| TypeScript or Python package name | Sets the registry identity.                                   |
| Go module path                    | Defaults to the destination repository and may be overridden. |
| Repository                        | Selects the GitHub destination.                               |
| Directory                         | Gives the Target ownership of one generated subtree.          |

Different Targets may share a repository only when their directories do not overlap. This ownership rule applies across the organization and prevents competing release pull requests from replacing each other's files.

CLI and MCP are not hidden inside a TypeScript SDK. They contain the request runtime they need, but neither selects, exposes, or bills a public TypeScript SDK. Hosted MCP is enabled with the MCP Target by default.

Turning a Target off stops future generation and its hosted service. It does not delete code already delivered or packages already published. Delivery settings remain saved so turning the Target back on does not erase its identity.

## Generator editions

Every Target pins a generator **edition**, a dated compatibility contract for the files Typeship emits.

Each Generation records the edition, engine build, configuration hashes, public-surface plan, endpoint entitlement, Definition Revision, and package version. This provenance stays in Typeship. Private source coordinates do not appear in destination repositories.

Typeship never silently upgrades a Target to a new edition. An unavailable edition returns `edition_unavailable`.

Upgrade tooling can generate and review a new edition before changing the Target. Engine fixes within an edition may change implementation details but must preserve its public contract.

## Package releases

Package versions belong to Targets, not Projects or Definitions.

* `current_version` advances only after the destination candidate merges.
* `proposed_version` is the version requested for the next candidate.
* Release readiness compares the proposal with the minimum SemVer change required by the cumulative unreleased diff.

Each merge creates an immutable `rel_*` Target Release. It records the Generation, Definition Revision, destination repository, and delivery revision that shipped.

On Pro, billing is per selected Target. Each Target includes 150 operations from the complete patched Definition, then pays for each additional operation it generates. See [Plans and limits](https://typeship.dev/docs/reference/limits).

> **For AI agents:** List Targets with `GET /projects/{project_id}/targets` and create one with `POST /projects/{project_id}/targets`. Retrieve or update one at `/targets/{target_id}`. Deliveries are nested resources on the Target, and releases live at `/targets/{target_id}/releases`. A Target's `generator` and `definition_id` are immutable.

## Sitemap

[Every page of these docs](https://typeship.dev/llms.txt)