Getting started with Deployer
What Deployer does, how to create an account and sign in, the vocabulary of the screens and the five roles of a workspace.
Checked in the application on September 5, 2026
What Deployer does
Deployer drives the delivery of an application spread across several GitLab repositories. From a single screen you see what runs on each environment, you deploy a branch or a release to every project in one click, you carry the fix for an issue onto the branches that need it, and you follow the merge requests of a feature across all repositories.
Deployer does not replace your CI. It pushes code, creates tags and starts pipelines; your GitLab pipelines build and deploy. Nothing happens outside GitLab, and everything Deployer does can be found there.
Everything lives in a workspace: a set of GitLab projects, environments, and a team with roles. An organisation can have several, one per product or per team.
Create an account and sign in
- Sign up
On the sign-in screen, follow the sign-up link. The form asks for a first name, a last name, an email address and a password, then “Create account”. A verification email is sent: its link is valid for 72 hours, and you can request a new one from your profile.
- Sign in with a password
Email address, password, “Sign in”. The “Forgot password?” link sends a reset email, valid for one hour, provided you typed the address in the field first.
- Sign in with Microsoft or Google
When the installation has configured it, “Continue with Microsoft” and “Continue with Google” open your provider’s page, then bring you back signed in. If you have no Deployer account yet, it is created at that moment, without a password. If an account already exists with the same address, it is linked automatically when the provider certifies the address.
When signing in with a provider fails, the screen explains why under “Sign-in failed”:
| The message | What it means | What to do |
|---|---|---|
| You declined the authorization. | You closed or refused the provider’s page. | Start again, and accept. |
| The request expired. | Too much time passed between the click and the return. | Start the sign-in again from the screen. |
| The provider could not confirm your identity. | A passing error at the provider or on the network. | Try again in a moment. |
| An account already exists with this address, and your provider does not certify that it belongs to you. | Deployer refuses to link an identity to an existing account automatically without proof on the address. | Sign in with your password, then link the provider from your profile. |
| Your provider did not return an email address. | The provider account has no visible address. | Check with your organisation’s administrator. |
| This sign-in method is not enabled on this installation. | The provider was disabled in the meantime. | Use your password, or the other provider. |
Your profile
Your avatar’s menu, top right, opens “My profile…”. The page is the same in every workspace: it describes your account, not your role.
- Personal information: first name, last name, communication language (the one Deployer uses for the emails it sends you), address and its state, verified or not. “Edit…” opens the form; “Resend verification email” does what it says.
- Security: “Change password…” asks for the old one, then the new one. An account created through Microsoft or Google has no password, and the section says so: “This account signs in with an identity provider, without a password.”
- Sign-in: the providers linked to your account. “Link Microsoft” or “Link Google” opens the provider’s page and returns to the profile; “Unlink” removes the identity. When it is your only way to sign in, the button is disabled with the explanation: you would have no access left.
- Active sessions: the connected devices, with their expiry date. “Revoke…” signs out the device concerned.
- Danger zone: “Delete my account”, irreversible.
Home: your workspaces
Once signed in, the home page lists the workspaces you are a member of. Each card carries the name, the description and the creation date; the “SHARED” ribbon marks a workspace created by someone else. A card’s menu offers “Configuration…” and “Delete…” depending on your role.
The dashed card at the end of the grid, or the “Create a workspace…” button when you have none yet, opens the creation dialog: that is the next page, Create a workspace.
Finding your way in a workspace
Inside a workspace, a row of tabs opens the working screens. Which tabs are present depends on the enabled modules and on your role.
| Tab | What it shows |
|---|---|
| Deployments | What runs on each environment, and the action to deploy. |
| Features | The open merge requests, grouped by issue. Can be switched off in the configuration. |
| Assembly | The trial branch carrying the main branch and the validated features. A module to enable. |
| Hotfix | Carry the commits of an issue onto other branches. |
| History | A menu: Versions, Fixes (the hotfix history), Actions, and Assemblies when the module is enabled. |
| Configuration | The workspace settings, administrators only. Until GitLab is connected, the tab is called “Setup”. |
The “Menu” button, right of the row, gathers what does not fit in a tab: “My GitLab account” (link your personal GitLab account, so your hotfixes carry your name), and for a manager or an administrator, “Members…”.
The vocabulary
The same words come back on every screen. Here is the short list; each page of the guide details its own.
| Word | What it is |
|---|---|
| Workspace | A set of GitLab projects driven together, with their environments and their team. |
| Linked project | A GitLab repository the workspace drives: the one Deployer pushes to, tags and opens merge requests on. |
| Main branch | The source of truth for the code, set when the workspace is created. Never a deployment target. |
| Tracked branch | A branch Deployer knows in every linked project: it can become an environment. |
| Environment | A deployment target, in promotion order: qualification, acceptance, production. |
| Deployment mode | The workspace’s final choice: branch-based or tag-based. See below. |
| Release | A tag created on every linked project in one click, with its pipeline. |
| Hotfix | The commits of an issue, found and then carried onto other branches through merge requests. |
| Feature | The merge requests of a single issue, across all projects, validated together. |
| Assembly | A trial branch rebuilt from the main branch and the validated features, to test before merging. |
| Release notes | The list of issues delivered between two releases, computed from the commits, then written up. |
The two deployment modes
The mode is chosen when the workspace is created and never changes. It decides what an environment is and how code gets there.
Whichever mode you pick, the Features, Assembly and Actions screens work the same way.
The roles
Every member of a workspace has a role, given by the person who invites them (see Members and their roles). Five roles, from the narrowest to the widest:
| Role | In a word | What it adds |
|---|---|---|
| Viewer | Read only | View linked projects, tracked branches and every screen. |
| Product owner | Validates features | Validate the merge requests of an issue, rebuild the assembled branch, write and share the release notes, set their validation convention. |
| Developer | Deploys and fixes | Everything a product owner does, plus deploy a version and create releases, carry a fix and merge its merge requests, run an environment action. |
| Manager | Manages members | Everything a developer does, plus invite and manage members. |
| Administrator | Full control | Everything, plus configure GitLab, projects and branches, rename or delete the workspace. |
Three details that avoid a surprise:
- A product owner does not deploy. They validate; a developer delivers.
- If the Features screen is switched off in the workspace, the product owner can no longer validate anything: writing release notes is what remains.
- Only an administrator can appoint another administrator.
Who can Installation administrator
The installation itself has its own administrator, distinct from the workspace roles. They manage accounts, see every workspace and can enter any of them as an administrator, without an invitation. They are the one who configures Microsoft or Google sign-in, from the “Administration” menu of their avatar.