Skip to content

Integrations

Slipway is a platform of typed providers. SCM, cloud, registry, notification, incident, issue, metric and secret providers are added as plugins that share one manifest, one config schema, one health check and one credential model, not as special cases.

Install integrations from Settings, Integrations in the app, or with IntegrationService.Install. Every integration has a health status and a Test action. Credentials are stored as encrypted secrets and never appear in logs.

Each provider page follows the same template: at a glance, what it does, set up, configuration, notes. Pages marked as stubs list the essentials and will be expanded.

Slipway never hosts your code. It connects to your SCM to discover pipelines, receive webhooks, post commit statuses and PR comments, and record deployments.

  • GitHub: Connect GitHub.com organisations and repositories through a GitHub App.
  • GitHub Enterprise: Connect GitHub Enterprise Server with a GitHub App registered on your instance.
  • GitLab: Connect GitLab SaaS or self-managed. Merge requests map to the same pull request trigger.
  • Bitbucket Cloud: Connect Bitbucket Cloud workspaces.
  • Bitbucket Data Center: Connect self-managed Bitbucket Data Center.
  • Azure Repos: Connect Azure DevOps Git repositories.
  • Gitea and Forgejo: Connect Gitea or Forgejo instances.

Registries and artifact repositories are the sources of release artifacts. Slipway lists repositories and tags to build releases and verifies digests at deploy time.

Cloud and cluster integrations give deployers somewhere to deploy to. Credentials are obtained through workload identity federation wherever the platform supports it, not stored keys.

  • AWS: Deploy to ECS, Lambda and EKS; read CloudWatch; federate with STS.
  • Google Cloud: Deploy to GKE and Cloud Run; read Cloud Monitoring; federate through Workload Identity Federation.
  • Microsoft Azure: Deploy to AKS, App Service and Container Apps; read Azure Monitor; use federated credentials.
  • DigitalOcean: Deploy to DOKS and App Platform.
  • Hetzner: Deploy to Hetzner Cloud servers and Kubernetes clusters you run there.
  • Kubernetes: Deploy manifests, Helm releases and Kustomize overlays to any cluster.
  • Helm: Install and upgrade Helm 3 releases as a deployment.
  • Kustomize: Apply Kustomize overlays per environment.
  • Argo CD: Sync an Argo CD application and read its health as part of a deployment.
  • Flux: Notify Flux and read reconciliation status.

IaC integrations run plan, approval and apply as part of a deployment so infrastructure changes get the same gates as application changes.

  • Terraform and OpenTofu: Plan, approve and apply Terraform or OpenTofu roots as a deployment.
  • Terraform Cloud: Trigger Terraform Cloud runs and wait for them.
  • Pulumi: Run pulumi preview and pulumi up as a deployment.

External secret references let Slipway resolve a value at job start without ever storing it. The reference is stored encrypted; the value is fetched with the job’s identity and masked in logs.

Notification integrations deliver Slipway events (run finished, deployment waiting for approval, canary verdict) to where your team already works.

Incident integrations record deploy markers and page the right people when a deployment fails or is rolled back.

  • PagerDuty: Change events as deploy markers and incidents on failure.
  • Opsgenie: Alerts on failed or rolled-back deployments.
  • incident.io: Deploy markers and incident creation.

Issue and change integrations link commits to tickets, generate release notes and gate production deployments on approved change requests.

Observability integrations send deploy markers and, for metric providers, feed canary verification with the signals that decide whether to continue or roll back.

Scanners run as pipeline steps; Slipway ingests their reports, shows findings on the run and can gate promotion with a policy.

Flag integrations let a deployment flip a flag as a step, so a release can ship dark and be turned on by the same pipeline.

The provider framework is the same one the built-in providers use. A provider declares a manifest (id, category, display, config JSON schema, OAuth spec, capabilities) and implements the category interface. Generic outbound webhooks cover most one-off needs without writing a provider.