> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shipways.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Source control and Composer

> Connecting an account, and the logins Composer needs for paid packages.

## Connecting an account

Sites deploy over SSH with [their own deploy key](/sites/deployments#the-deploy-key)
whether or not you connect an account. Connecting one lets Shipways list your
repositories and install those keys for you, and register the webhook that
makes [deploy on push](/sites/deployments#triggering-a-deploy) work.

| Provider      | Token needs                                 | Where to make one                      |
| ------------- | ------------------------------------------- | -------------------------------------- |
| **GitHub**    | `repo`                                      | Settings → Developer settings → Tokens |
| **GitLab**    | `api`                                       | User settings → Access tokens          |
| **Bitbucket** | Read and write on repositories and webhooks | Atlassian API tokens                   |

The token is **checked before it is saved**, so you find out now rather than at
your first deployment.

Connect as many accounts as you need — a personal one and a client's, or two
organizations.

## Self-hosted instances

GitHub Enterprise and self-hosted GitLab are supported: give the base URL of
your instance and both the API and the SSH host are worked out from it.

Bitbucket Data Center is not. It speaks a different API from Bitbucket Cloud,
so accepting a base URL for it would promise something Shipways cannot do.

## The provider cannot change

A token is issued by one host and means nothing to another, so an existing
credential's provider is fixed. Connect a second account for a different one.

Editing a credential and leaving the token box empty keeps the token you
already have. A new one is checked before it replaces it.

## What the token reaches

Everything the account behind it can see, including repositories Shipways knows
nothing about. That is why
[managing source control credentials](/organizations#roles) is held higher than
managing sites — using a credential that already exists comes with permission
to create a site.

## Composer credentials

Nova, Spark and a private Satis all need a login before Composer will download
them. Without one, a deployment stops at `composer install` with a 403.

Add them under **Composer**. They are written to **every server this
organization owns**, because a licence is bought once and used everywhere.

They are encrypted here, written to each server readable only by the account
that deploys, and never shown again.

Removing one means Composer can no longer download from that host on any server
here, so a deployment needing it will fail.

Public packages need none of this.

## npm tokens

The same thing for JavaScript packages, under **npm**. A private package
without a token fails at `npm ci` with a **404 rather than a 401**, so the error
says the package does not exist when it means you are not allowed it.

A token needs the **registry** host it authenticates against, such as
`registry.npmjs.org`. Add the **scope** as well — `@acme`, including the `@` —
for a registry that only serves one, such as GitHub Packages. Without the scope
npm asks the public registry for `@acme/thing`, is told there is no such
package, and never consults your registry at all.

Tokens are written to `~/.npmrc` on every server this organization owns,
readable only by the account that deploys. They are encrypted here and never
shown again. A read-only token is enough to install; anything more also lets a
build publish.

Shipways keeps these rather than reading them off a machine, so that a server
added later arrives with the token already on it instead of failing its first
deployment. Transferring a server rewrites the file from the new owner's
tokens, and the old organization's come off it.