# Connecting a repository

Ground your Specs in the code your team actually has. Read-only, GitHub, GitLab and Bitbucket.



Connecting a repository lets the planning agent read your code while it plans, so the Specs it
writes match the stack, the patterns and the naming you already use.

<Callout>
  **Connecting is read-only.** Plansmith reads your repository to understand it. It never opens a
  pull request, never pushes a commit, and never writes anything back.
</Callout>

## The code connectors [#the-code-connectors]

<Cards>
  <Card title="GitHub">
    github.com and GitHub Enterprise Server.
  </Card>

  <Card title="GitLab">
    gitlab.com and self-managed GitLab.
  </Card>

  <Card title="Bitbucket">
    Bitbucket Cloud and Bitbucket Data Center.
  </Card>
</Cards>

These are **not** push destinations. Nothing from a plan is written to them. For where a finished
plan goes, see [Push to your issue tracker](/docs/push-to-your-issue-tracker).

## Connecting [#connecting]

Open **Settings → Connectors** in your project and authorize the provider. Connections are made
with OAuth, per person, and the agent reaches a repository as the person who connected it.

Once a repository is linked to a project, anyone planning in that project can ground against it.

## Self-hosted servers [#self-hosted-servers]

A GitHub Enterprise, self-managed GitLab or Bitbucket Data Center instance connects the same way,
with two conditions:

* **It is a Team plan capability.** Registering a self-hosted server requires the Team or
  Enterprise plan, and an owner.
* **It must be reachable over public HTTPS.** Plansmith refuses private and internal addresses on
  purpose.

If your server only answers inside your network, that is what the
[self-hosted Git broker](/docs/developers/broker) is for: a small container you run, which dials
out to Plansmith and relays a fixed list of read-only requests. Nothing inbound, and your Git
credential never leaves your network.