Provider setup and requirements

Wizata generates an SSH keypair and shows you the public key. Where you register it depends on your provider, and the difference is not cosmetic — on two of the four, the obvious place is the wrong one.

Quick reference

Write access is required

Wizata pushes on every pipeline save. A read-only key is not a reduced-capability setup — it produces a connection that appears to work and then fails the first time someone edits a pipeline.

This is worth stating plainly because read-only is the default in more than one place:

• GitHub leaves "Allow write access" unticked when you add a deploy key.
• GitLab deploy keys are read-only unless you grant write permissions.
• Bitbucket access keys are read-only and cannot be granted write access at all.

If the connection status shows connected but saving a pipeline fails, a read-only key is the first thing to check.

GitHub

1. Repository → Settings → Deploy keys → Add deploy key
2. Paste the public key from Wizata
3. Tick "Allow write access"

Azure DevOps

Azure DevOps has no per-repository deploy keys. SSH keys are registered against a user identity, so there is nothing to attach a key to at repository level.

1. Sign in as the account that should own this connection
2. User settings → SSH public keys → New key
3. Paste the public key from Wizata

🚧

The key inherits everything that account can reach

Not just this repository. Use a dedicated service account whose permissions are limited to the project holding the repository — never a personal or administrator login.

Wizata generates an RSA key for Azure DevOps rather than ed25519. This is deliberate: the Azure DevOps SSH gateway accepts only ssh-rsa, and an ed25519 key does not fail cleanly against it — the connection hangs. Wizata selects the right algorithm automatically from the repository URL, so you do not need to configure anything.

GitLab

1. Project → Settings → Repository → Deploy keys
2. Paste the public key and grant write permissions

Two further things catch people out on GitLab:

• The default branch is protected by default. A deploy key is not a maintainer, so pushes are rejected until the protection rule allows the key, or the protection is relaxed.
• The key's owner must be a member of the project. A key that is otherwise correct is still refused if its owner has no access.

Both produce the same unhelpful message: "You are not allowed to push code to this project." If you see it, check both before assuming the key is wrong.

Bitbucket

Bitbucket has repository access keys, but they grant read-only access — in Bitbucket's own words, "Use access keys to gain read-only access to this repository." Since Wizata must push, they cannot be used.

Register the key on an account instead:

1. Sign in as the account that should own this connection
2. Settings → Personal Bitbucket settings → Security → SSH keys → Add key
3. Paste the public key from Wizata

🚧

The key inherits everything that account can reach

As with Azure DevOps, use a dedicated service account rather than a personal login.

Two Bitbucket-specific points:

• A public key can only be registered once per workspace. If you already added it as an access key, delete that first — otherwise Bitbucket rejects it as already in use. Alternatively, re-attach in Wizata to generate a fresh keypair.
• If your Bitbucket plan lapses or is not yet active, every private repository in the workspace becomes read-only and pushes fail. Bitbucket reports this as an exceeded user limit even when the workspace has one user, so the message can be misleading.

Self-hosted and other providers

Any git remote reachable over SSH will work. Choose generic as the provider type if yours is not listed.

Self-hosted instances on a non-standard SSH port are supported — give the full URL including the port, for example ssh://[email protected]:2224/team/pipelines.git.