Your agency has asked for access to GitLab. You don't need to share your password for it. GitLab lets you add them with their own login, choose exactly what they can do, and remove them when the project ends. These are the clicks, checked against GitLab's own help pages in October 2026.
Which role to choose
Pick the narrowest role that lets your agency do the work. Developer is usually the right one.
| Role | What it allows | For an agency |
|---|---|---|
| Developer | Pushes code, opens merge requests and runs pipelines. Cannot change project settings. | Usually the right one |
| Maintainer | Developer, plus branches, CI/CD settings and members. Cannot delete the project. | If the work needs it |
| Reporter | Reads code and works on issues. Cannot push code. | If the work needs it |
Add your agency to GitLab
- Open your project on GitLab.
- In the left sidebar, select Manage, then Members, then Invite members.
- Enter your agency's email address, choose the Developer role and select Invite.
How you both know it worked
GitLab emails your agency an invitation from gitlab.com. Once they accept it, they show in your GitLab account's list of people with access, where you can see or change their role at any time.
Remove access when the project ends
- Open your project on GitLab and select Manage, then Members.
- Next to the account your agency used, select Remove member, then Remove member again to confirm.
- Remove any deploy keys or access tokens your agency added.
Do you have to share your password?
No. Every step above uses GitLab's own invite, so your agency signs in with their own account, your two-step verification stays on, and anything they change is recorded under their name. How to give a developer access without sharing your password covers the other accounts agencies usually ask for.
Doing this for every client?
Agencies can send each client one Get Set Keys link instead of a page like this. It walks the client through GitLab and the other platforms the project needs, and checks that each step is done.