Skip to main content

​
Connecting an account

Sites deploy over SSH with their own 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 work. 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 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.