info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type:howto, reference
---
# Deploy keys **(FREE)**
Deploy keys allow read-only or read-write access to your
repositories by importing an SSH public key into your GitLab instance.
Use deploy keys to access repositories that are hosted in GitLab. In most cases, you use deploy keys
to access a repository from an external host, like a build server or Continuous Integration (CI) server.
Deploy keys streamline interactions between your GitLab repository and another
machine. For example, setting up a deploy key allows secure cloning of your
repositories to a Continuous Integration (CI) server without setting up a fake
user account.
Depending on your needs, you might want to use a [deploy token](../deploy_tokens/) to access a repository instead.
There are two types of deploy keys:
| Attribute | Deploy key | Deploy token |
|------------------|-------------|--------------|
| Sharing | Shareable between multiple projects, even those in different groups. | Belong to a project or group. |
| Source | Public SSH key generated on an external host. | Generated on your GitLab instance, and is provided to users only at creation time. |
| Validity | Valid as long as it's registered and enabled. | Can be given an expiration date. |
| Registry access | Cannot access a package registry. | Can read from and write to a package registry. |
-[Project deploy keys](#project-deploy-keys)
-[Public deploy keys](#public-deploy-keys)
## Scope
## Key details on deploy keys
A deploy key has a defined scope when it is created:
Deploy keys allow a remote machine (VM, physical, and so on) to access a GitLab
repository with just a few steps. If you want a remote machine to interact with a GitLab
repository in automation, it's a simple solution.
-**Project deploy key:** Access is limited to the selected project.
-**Public deploy key:** Access can be granted to _any_ project in a GitLab instance. Access to each
project must be [granted](#grant-project-access-to-a-public-deploy-key) by a user with at least
the Maintainer role.
A drawback is that your repository could become vulnerable if a remote machine is compromised
by a hacker. You should limit access to the remote machine before a deploy key is
enabled on your repository. A good rule to follow is to provide access only to trusted users,
and make sure that the allowed users have at least the Maintainer role
in the GitLab project.
You cannot change a deploy key's scope after creating it.
If this security implication is a concern for your organization,
[Deploy Tokens](../deploy_tokens/index.md) works as an alternative, but with more
security control.
## Permissions
## Deploy keys permissions
A deploy key is given a permission level when it is created:
You can choose the access level of a deploy key when you enable it on a project:
-**Read-only:** A read-only deploy key can only read from the repository.
-**Read-write:** A read-write deploy key can read from, and write to, the repository.
-`read-only`: The deploy key can read a repository.
-`read-write`: The deploy key can read a repository and write to it.
You can change a deploy key's permission level after creating it. Changing a project deploy key's
permissions only applies for the current project.
Project maintainers and owners can activate and deactivate deploy keys.
They can also add their own deploy keys and enable them for this project.
When a read-write deploy key is used to push a commit, GitLab checks if the creator of the
deploy key has permission to access the resource.
When a `write-access` deploy key is used to push a commit, GitLab checks if
the **creator** of the deploy key has permission to access the resource. For example:
For example:
- When a deploy key is used to push a commit to a [protected branch](../protected_branches.md),
the **creator** of the deploy key must have access to the branch.
- When a deploy key is used to push a commit that triggers a CI/CD pipelines, the **creator** of
the deploy key must have access to the CI/CD resources (like protected environments, secret variables, and so on).
- If the **creator** of a deploy key does not have permissions to read a project's
repository, the deploy key _might_ encounter an error during the process.
the _creator_ of the deploy key must have access to the branch.
- When a deploy key is used to push a commit that triggers a CI/CD pipeline, the _creator_ of the
deploy key must have access to the CI/CD resources, including protected environments and secret
variables.
## Differences between deploy keys and deploy tokens
## View deploy keys
Both deploy keys and [deploy tokens](../deploy_tokens/index.md#deploy-tokens) can
help you access a repository, but there are some notables differences between them:
- Deploy keys are shareable between projects that are not related or don't even
belong to the same group. Deploy tokens belong to either a project or
- The owner associated to a deploy key does not have access to the protected branch.
- The owner associated to a deploy key does not have [membership](../members/index.md) to the project of the protected branch.
-**No one** is selected in [the "Allowed to push" section](../protected_branches.md#configure-a-protected-branch) of the protected branch.
-**No one** is selected in [the **Allowed to push** section](../protected_branches.md#configure-a-protected-branch) of the protected branch.
All deploy keys are associated to an account. Since the permissions for an account can change, this might lead to scenarios where a deploy key that was working is suddenly unable to push to a protected branch.