Drive all your GitLab deployments from a single screen.
Deployer gathers your GitLab repositories into one delivery workspace: one tile per environment, one-click deployment from one environment to the next, and release notes computed from your commits.
For GitLab teams, hosted or on-premise.
A multi-repo release lives in no GitLab screen.
- One tab per repository just to know what runs in pre-production.
- One merge request created by hand, per project and per environment.
- One forgotten repository and the release ships incomplete, and nothing says so.
- One tile per environment, in deployment-chain order.
- Merge requests opened towards every target in one click.
- An incomplete release is detected and blocked before going live.
The product, as it is.
Seven screens that cover the whole delivery.
What runs on each environment and what is ready to deploy, with each project’s pipeline on one line.
All merge requests of one issue, grouped across repositories. The issue is validated when everything is mergeable, never halfway.
The try-out branch carrying the main branch plus every ready feature, rebuilt on every change, to try before merging.
From a GitLab issue to hotfix merge requests: Deployer finds the commits and opens branches on every affected project.
One tag placed on all repositories in one click, its pipeline tracked to the end.
Target branches, allowed sources, variables, actions to run before going live: everything is declared here, once.
Five roles, from viewer to product owner. The GitLab token stays locked server-side.
By branch or by version: Deployer handles both.
- Deploying is pushing: master to test, then preprod, then prod.
- Each environment declares which branches are allowed in.
- The version tag is placed automatically at deployment time.
- Build once, at the tag: CI is decoupled from deployment.
- The exact same artifact is deployed from one environment to the next.
- An incomplete version, with one repo missing the tag, never goes live.
The mode is chosen at workspace creation and never changes: the entire delivery history depends on it.
The product owner validates features. The developer fixes production.
A feature often spans several repositories. Deployer groups its merge requests under the issue and reads GitLab’s verdict for each one.
A production bug, a GitLab issue. Deployer prepares the hotfix end to end. You confirm before anything is written to GitLab.
Try a feature before merging it.
Deployer assembles the main branch and every ready feature into a try-out branch, rebuilt on every change. The product owner tries the whole feature on the development environment, then merges it from the Features screen.
- A feature conflicting in a single repository is held back from all of them: nothing ships halfway.
- Rebuilt automatically on every change, green CI required; a freeze pins the branch during a try-out.
- Every held-back feature says why, and the developer is notified on their merge request.
The assembled branch can never be deployed: neither source nor target of a release or a hotfix. It exists to try, never to ship.
The release note is computed. Then it is written.
Twelve repositories, dozens of tickets, several teams: Deployer compares refs and produces the note in one pass: one line per ticket, grouped by team, exportable to Markdown or Excel.
- One line per ticket, with its commits and projects.
- Commits without a ticket reference are counted, not hidden.
- Markdown or Excel export, ready to share.
- AI drops technical noise and writes for the reader: technical, product or customer.
- A dozen readable entries, not forty lines of commits.
- The computed note stays underneath, as the reference.
The written note can say less than the computed one, never something else: an invented ticket reference blocks saving.
Deployer plugs into your GitLab, it does not replace it.
A server that decides, your GitLab that does the work. Deployer never runs Git: when repositories have to be cloned and pushed, a dedicated GitLab project, the orchestrator, does it on your side.
Hosted or on-premise. A GitLab API client: it runs no Git, it holds no repository. The workspace token stays on the server, never in the browser.
- reads and writes : branches, MRs, tags
- webhooks : what moves on your side
- triggers a pipeline : with the manifest
- report : what was assembled
Your repositories: branches, merge requests, pipelines, tags. The grid reads these.
The reference that ties together the merge requests of one feature, across every repo.
- pushes the assembled branch
A dedicated GitLab project, set up in two minutes from the template we ship. It clones, simulates the merges, and pushes the assembled branch. The clone token lives here, as a masked variable, set by Deployer.
Nothing to install in your sixteen repositories: one project to set up, from a template that is the same for everyone. The orchestrator is not a linked project: it shows up neither in the deployment grid nor among the repositories being assembled.
Three steps to a working workspace.
Let’s talk about your delivery chain.
A thirty-minute demo, on your repositories, no installation required.