Skip to main content
slipway sees the repositories you granted it at install. There is no page listing them on their own: you pick a repository where you need one, and what slipway knows about it lives on the service it deploys.

​
Deploying a repository

A repository starts deploying once it is part of a project. Press ⌘K or select New, pick a service type, then Connected repository. If your workspace spans several accounts you choose the account first, or All repositories to search across every one. slipway validates slipway.yaml along the way, so a missing or invalid spec is caught before anything builds. From then on you can deploy the tracked branch from the project, and pushes redeploy it when auto-deploy is on. Repositories you did not grant at install are invisible to slipway. Grant more with Connect a repository in the same list, which also offers the other provider. The list refreshes on its own, and Sync repositories forces it. Manual deploys and pushes are scoped to the tracked branch.

​
Commit checks

Every deploy triggered by a push reports a slipway check on the commit: a check run on GitHub, a commit status on GitLab. The check is the reliable signal for a failed push. Manual deploys do not post one, since you are already watching those.

​
Notifications

Deployment notifications are configured per project rather than per repository. See Notifications.

​
Spec source

A repository can deploy from a committed slipway.yaml, a committed Compose file, or a spec stored in slipway with no file in the repo at all. See Overview. slipway never writes to your repository.