Documentation

Deployment Plugin Source Control

Team Playbook Version Control

Keep custom Deployment Plugins in GitHub, Bitbucket Cloud or GitLab while SSLNexus continues to validate and execute them locally. The organisation controls the repository boundary; each administrator connects their own source-control identity for repository access and attribution.

How The Connection Model Works

Source control has two layers. The organisation configures one account, workspace or group for each provider it chooses to use. Administrators then connect their own provider identities.

LayerPurpose
Organisation connectionDefines the approved GitHub account, Bitbucket workspace or GitLab group/namespace and the OAuth/App credentials used by this SSLNexus organisation.
Administrator identityEach administrator authorises their own provider identity. Pull/publish actions use that individual connection rather than a shared personal token.
Only Deployment Plugin definitions and playbooks are published. Plugin secret values remain in the protected SSLNexus secret store.

Before Configuring A Provider

  1. Open Deployment Plugins → Source control.
  2. Copy the OAuth callback URL shown in Organisation connection.
  3. Create the provider application/App using that exact callback URL.
  4. Return to SSLNexus, enter the provider details, and select Save organisation connection.
  5. Each administrator who needs repository access then selects Connect my identity.

The callback must match exactly, including scheme, hostname and path. Configure the public/admin HTTPS hostname before creating the provider application if the server is still being accessed by IP address.

GitHub

Use a GitHub App for the organisation connection. Give the App repository metadata read access and repository contents read/write access, then install it only on the account and repositories that may hold SSLNexus plugins.

  1. Create the GitHub App using the callback URL shown by SSLNexus.
  2. Enter the GitHub organisation/user login as Account.
  3. Enter the App client ID, client secret and App slug.
  4. Save the organisation connection.
  5. Select Install app and limit the installation to the required repositories.
  6. Each administrator selects Connect my identity.

Bitbucket Cloud

Create an OAuth consumer for the workspace and configure repository read/write access. Use the workspace slug as the organisation account value in SSLNexus.

  1. Create the OAuth consumer with the exact callback URL shown by SSLNexus.
  2. Enter the Bitbucket workspace slug, consumer key and consumer secret.
  3. Save the organisation connection.
  4. Each administrator selects Connect my identity and authorises their own Bitbucket account.

GitLab

Create an OAuth application with API access. GitLab.com is supported directly; for self-managed GitLab, enter its HTTPS base URL.

  1. Create the OAuth application with the callback URL shown by SSLNexus and API access.
  2. Enter the group/namespace, application ID and application secret.
  3. For self-managed GitLab, enter the HTTPS base URL.
  4. Save the connection and have each administrator connect their own identity.

Pull, Edit And Publish

Repository operations live inside the Deployment Plugins page and feed the same editor and validation pipeline used for local plugins.

  1. Select the connected provider.
  2. Select the repository and branch.
  3. Set the plugin path, for example ssl-nexus-plugins/nginx-custom.
  4. Use Pull into editor to import or refresh a repository plugin.
  5. Configure any local secret values, then run Test.
  6. Use Publish current plugin to save/validate locally and commit the portable files to the repository.
ssl-nexus-plugins/
├── nginx-custom/
│   ├── plugin.json
│   ├── test.yaml
│   ├── deploy.yaml
│   ├── verify.yaml
│   └── rollback.yaml
└── windows-custom/
    ├── plugin.json
    ├── test.yaml
    └── deploy.yaml

What Is And Is Not Published

SSLNexus publishes only the portable plugin definition:

  • plugin.json
  • test.yaml
  • deploy.yaml
  • verify.yaml
  • rollback.yaml

Secret names remain in plugin.json so another administrator or SSLNexus installation knows what local values must be configured. The actual passwords, API tokens and other secret values are never uploaded.

Never hard-code a password, API token, certificate private key or other secret directly into a playbook. Declare a Secret name and store its value in SSLNexus.

Recommended Team Workflow

Treat the repository as the collaborative source for the playbook definition and SSLNexus as the execution and secret boundary. Teams can review plugin changes in their existing repository workflow while production execution still goes through SSLNexus's Test → Deploy → Verify → Rollback lifecycle.

Changing the organisation account/client configuration requires administrators to reconnect their provider identities. Disconnecting an identity removes its locally stored OAuth token.

Deployment Plugin Guide →