Automate GitLab With n8n: 18 Operations, 12 Trigger Events

Why automate

Why build a GitLab n8n integration?

A GitLab n8n integration wires your repositories to everything that sits around them. The GitLab node calls the GitLab API for you, so a workflow can read a file, open an issue or cut a release without anyone opening the interface. The GitLab Trigger works the other way round: it registers a webhook, an n8n URL that GitLab calls the moment something happens in the project.

Start with release notes that write themselves. A tag lands, the trigger fires on tag_push, the node runs release.create with that tag and a description assembled upstream, and the announcement reaches Slack before anyone refreshes a page.

Next, issue triage that does not depend on someone watching the board. repository.getIssues pulls open issues each morning, filters them on a label, and drops the list into Google Sheets for the weekly review. Pair it with issue.edit and stale tickets get closed on a rule instead of a mood.

Then the repository as a config store. file.get reads a JSON file from the default branch, the workflow uses those values, and file.create writes the result back with a commit message that says where it came from. Teams that also mirror work to GitHub run the same shape on both platforms.

Reach for the HTTP Request node when an operation is missing. The GitLab node covers files, issues, releases, repositories and users. Anything else in the GitLab API still works: HTTP Request calls the endpoint directly and reuses the same GitLab credential through predefined authentication, so you do not manage a second token.

Two limits are worth knowing before you build. The release operations ask for a Project ID, the ID or URL encoded path of the project, while file and issue operations ask for Project Owner, so a single workflow mixes both conventions. And listings come back paginated: leave Return All off and n8n stops at Limit. If the platform choice is still open, the n8n review covers it, and the n8n training goes deeper on expressions.

Connect

How do you connect GitLab to n8n?

01
Create a GitLab access token
In GitLab, select your avatar, then Edit profile, then Access tokens in the left sidebar, then Add new token. Give it a Name such as n8n integration, set an expiry date, and pick your Scopes. The api scope grants everything the node does in one go; narrower scopes work once you know which operations you actually run.
02
Enter the credential in n8n
Open the Credentials menu in n8n and create a GitLab credential. Paste the token into Access Token, then fill GitLab Server with the URL of your instance, which matters when the team self hosts rather than using gitlab.com. A credential is created once and reused everywhere: the GitLab node and the GitLab Trigger both pick it from a dropdown.
03
Or register an OAuth2 application
OAuth2 is the recommended method. In GitLab, go to Edit profile, then Applications, then Add new application. Copy the OAuth Redirect URL that n8n shows into the GitLab Redirect URI field, tick the same Scopes, and save. GitLab returns an Application ID and a Secret, which become Client ID and Client Secret in n8n.

Triggers

What GitLab events can start a workflow?

GitLab Trigger is the node that starts a workflow when something happens in GitLab. It listens to 12 events, listed below by family. Pick one or several, activate the workflow: n8n registers the webhook on your GitLab account.

What you see in n8n

Every event, by family

One row per object, one chip per action. The event to tick in the node is object.action; hover a chip to read exactly when it fires.

confidential_issues.*1

confidential_issues.
- confidential_issues

confidential_note.*1

confidential_note.
- confidential_note

deployment.*1

deployment.
- deployment

issues.*1

issues.
- issues

job.*1

job.
- job

merge_requests.*1

merge_requests.
- merge_requests

note.*1

note.
- note

pipeline.*1

pipeline.
- pipeline

push.*1

push.
- push

releases.*1

releases.
- releases

tag_push.*1

tag_push.
- tag_push

wiki_page.*1

wiki_page.
- wiki_page

The trigger also accepts * (any event). Handy for logging, dangerous in production.

Configuration notes

01Configure the GitLab TriggerThe trigger needs to know which project to watch and what to listen for. Nothing else.

The trigger needs to know which project to watch and what to listen for. Nothing else.

Key parameters

Repository Owner: the user, group or namespace the project belongs to.
Repository Name: the name of the repository itself.
Events: the list you tick. A wildcard entry, *, subscribes to every event at once, which helps while you are still deciding what matters.

When to use it

activate the workflow and n8n registers a webhook with GitLab, meaning GitLab calls an n8n URL each time the event happens. The payload arrives within seconds, with no polling and no interval to tune. Start with the wildcard on a test project, look at what actually lands, then narrow the list down to the two or three events you keep.

02Push, Tag and Merge Request eventsThese three carry the day to day movement of the code.

These three carry the day to day movement of the code.

Key parameters

Push (push): fires when you push to the repository, except when the push is a tag.
Tag (tag_push): fires when you create or delete tags, which is the clean hook for anything version shaped.
Merge Request (merge_requests): fires when a merge request is created, updated, merged or closed, and also when a commit is added to the source branch.

When to use it

a merge into the default branch is the moment most teams want a side effect, whether that is closing the linked issue with issue.edit or posting a summary to the channel where the reviewers hang out. Because push stays quiet on tags, you can treat commits and versions with two separate workflows.

03Pipeline, Job and Deployment eventsThe CI side of GitLab reports its own progress here.

The CI side of GitLab reports its own progress here.

Key parameters

Pipeline (pipeline): fires on a status change of a pipeline.
Job (job): fires on a status change of a job, so one pipeline produces several of them.
Deployments (deployment): fires when a deployment starts, succeeds, fails or is cancelled.
Release (releases): fires when a release is created or updated.

When to use it

a failed nightly build that nobody reads is a failed build that ships. Listen to pipeline, filter on the status in the payload, and send the failures where people already look. Keep job for the cases where you need the failing step by name, because it is noisier than the pipeline it belongs to. deployment is the one to pick when the question is environment shaped rather than build shaped, since it reports the cancellations too.

04Issue, Comment and Wiki Page eventsEverything humans write around the code has its own event.

Everything humans write around the code has its own event.

Key parameters

Issue (issues): fires when an issue is created, updated, closed or reopened.
Comment (note): fires on a new comment on commits, merge requests, issues and code snippets.
Confidential Issues and Confidential Comments (confidential_issues, confidential_note): the same two signals for confidential content, kept separate on purpose.
Wiki Page (wiki_page): fires when a wiki page is created, updated or deleted.

When to use it

support teams live on issues, because a new ticket is the start of a process that continues far outside GitLab. Subscribe to the confidential variants only when the workflow is allowed to handle that content, since they are not covered by the standard events. And wiki_page is the quiet one worth keeping: documentation that changes without anyone announcing it is how a runbook goes stale.

Actions

What can the GitLab node do?

The GitLab node exposes 18 operations across 5 resources. For each one: the node as you configure it in n8n, the required fields, and our field notes.

Resources × operations matrix
Resource	Create	Get	Get Many	Update	Delete	Create Comment	Edit	Get Issues	Get Repositories	List	Lock
File	✓	✓			✓		✓			✓
Issue	✓	✓				✓	✓				✓
Release	✓	✓	✓	✓	✓
Repository		✓						✓
User									✓

File

5 operations

01

Create a file

file.create

What you see in n8n

Notes & use cases

Commits a new file into the repository, on the branch you name, exactly as a developer would.

Key parameters

Project Owner: the user, group or namespace of the project, for example n8n-io.
Binary File: off, n8n writes the text you put in File Content; on, it takes the file from Input Binary Field, the incoming binary field by name.
Commit Message and Branch: the message recorded with the commit, and the branch that receives it.
File Path: the full path such as docs/README.md, or empty for the root folder.

Use cases

write a generated changelog back into the repo at the end of a release workflow.

02

Delete a file

file.delete

What you see in n8n

Notes & use cases

Removes a file and records the removal as a commit, so the history keeps the trace.

Key parameters

File Path: the full path of the file to remove, or empty to target the root folder.
Branch: the branch the deletion commit is added to.
Commit Message: what the history will show, which is the only explanation a reviewer gets six months later.
Project Owner: the user, group or namespace of the project.

Use cases

clear temporary export files that a scheduled workflow wrote into the repository the week before.

03

Edit a file

file.edit

What you see in n8n

Notes & use cases

Replaces the content of a file that already exists and commits the new version.

Key parameters

File Content: the new text, which overwrites the old one rather than appending to it.
Binary File: switch it on to push the file from Input Binary Field instead of typed text.
File Path, Branch and Commit Message: which file changes, where, and under what message.
Project Owner: the user, group or namespace of the project.

Use cases

keep a versions file in sync after a deploy, without a human editing a line by hand.

04

Get a file

file.get

What you see in n8n

Notes & use cases

Reads one file back out of the repository so the rest of the workflow can use its content.

Key parameters

Put Output File in Field: the name of the output binary field n8n drops the file into.
As Binary Property: on, you get a binary field; off, you get the raw API response instead.
Reference, under Additional Parameters: the commit, branch or tag to read from, such as main. Left empty, GitLab uses the default branch of the repository.

Use cases

load a JSON settings file from the repo and drive the branching of the workflow with it.

05

List files

file.list

What you see in n8n

Notes & use cases

Lists what a folder of the repository contains, one item per entry found.

Key parameters

File Path: the folder to list, empty for the root.
Return All: on, n8n walks every page of results; off, it stops at Limit, and Page lets you fetch a specific page on its own.
Recursive, under Additional Parameters: on, you get the whole tree below the path instead of one level.
Reference: the commit, branch or tag to list from.

Use cases

audit which documents exist under a docs folder before generating an index.

Issue

5 operations

06

Create an issue

issue.create

What you see in n8n

Notes & use cases

Opens a new issue in the project and returns it, number included, for the nodes that follow.

Key parameters

Title: the title of the issue, the one required field beyond the project.
Body: the description, often built from the incoming item with something like {{ $json.message }}.
Due Date and Assignees: a deadline, and the people who own it.
Label and Assignee, in the Labels collection: a label to add, and a user ID to assign the issue to.

Use cases

turn a support form submission into a tracked bug, with the reporter email in the body.

07

Create a comment on an issue

issue.createComment

What you see in n8n

Notes & use cases

Adds a comment to an existing issue, which keeps the conversation where the team already reads it.

Key parameters

Issue Number: the number of the issue receiving the comment, typically carried over as {{ $json.iid }} from a previous node.
Body: the text of the comment itself.
Project Owner: the user, group or namespace of the project.

Use cases

post the result of a deployment on the issue that triggered it, so the thread carries the outcome and not just the request.

08

Edit an issue

issue.edit

What you see in n8n

Notes & use cases

Updates an issue that already exists, changing only the fields you add to the collection.

Key parameters

Issue Number: which issue gets edited.
State, in Edit Fields: closed or open, which is how a workflow closes a ticket on its own.
Title, Body, Labels, Assignees and Due Date: everything else the collection lets you rewrite.

Use cases

close the linked issue automatically when the merge request that fixes it is merged into the default branch.

09

Get an issue

issue.get

What you see in n8n

Notes & use cases

Fetches a single issue and returns its data, without changing anything in GitLab.

Key parameters

Issue Number: the number of the issue to read.
Project Owner: the user, group or namespace of the project.

Use cases

enrich an alert before sending it. The trigger gives you a number, this operation gives you the title, the state, the labels and the assignees, and the message that goes out to the team finally says something useful instead of pointing at an ID.

10

Lock an issue

issue.lock

What you see in n8n

Notes & use cases

Locks the discussion on an issue, so no new comment can be added to the thread.

Key parameters

Issue Number: the issue to lock.
Lock Reason: one of off-topic, too heated, resolved or spam, which records why the thread was frozen.

Use cases

a public project attracts comments on issues that were settled long ago. A scheduled workflow reads the closed issues, locks them with resolved, and the maintainers stop answering the same question.

Release

5 operations

11

Create a release

release.create

What you see in n8n

Notes & use cases

Publishes a release on the project, attached to a tag, and returns it.

Key parameters

Tag: the tag of the release, the only field required beyond the project.
Ref, in Additional Fields: if the tag does not exist yet, GitLab creates the release from this reference, a commit SHA, another tag name or a branch name.
Name and Description: the display name of the release and its notes.

Use cases

cut the release from the workflow that already built the artifact, with notes assembled from the merged issues.

12

Delete a release

release.delete

What you see in n8n

Notes & use cases

Deletes a release from the project. The Git tag itself is a separate object from the release.

Key parameters

Project ID: the ID or the URL encoded path of the project, which the release operations use instead of a plain owner.
Tag Name: the Git tag the release is associated with.
Project Owner: the user, group or namespace of the project.

Use cases

roll back a release that a pipeline published from the wrong branch, before anyone downloads it.

13

Get a release

release.get

What you see in n8n

Notes & use cases

Returns one release, identified by its tag, with its data as GitLab stores it.

Key parameters

Tag Name: the Git tag the release is associated with.
Project ID: the ID or URL encoded path of the project.
Project Owner: the user, group or namespace of the project.

Use cases

check that the release exists before a deployment workflow continues, and stop the run cleanly rather than pushing a version that was never published.

14

Get many releases

release.getAll

What you see in n8n

Notes & use cases

Returns the releases of a project as a list, one item per release.

Key parameters

Return All: on, n8n pages through the full history; off, it stops at Limit.
Order By, in Additional Fields: created_at or released_at, which are not the same date when a release is prepared ahead of time.
Sort: asc or desc for the direction.

Use cases

build a shipping history for the quarter, sorted on the released date, and push it to the sheet the product team reviews.

15

Update a release

release.update

What you see in n8n

Notes & use cases

Edits a release that is already published, leaving the tag it points to untouched.

Key parameters

Tag Name: which release gets updated.
Description, in Additional Fields: the notes of the release, where Markdown is allowed.
Milestones: the title of each milestone to associate, as a list of titles separated with a comma.
Released At: the date the release is or was ready.
Name: the release name.

Use cases

append the migration notes to a release once the ops team has confirmed them.

Repository

2 operations

16

Get a repository

repository.get

What you see in n8n

Notes & use cases

Returns the data of a single repository, and asks for nothing beyond the project itself.

Key parameters

Project Owner: the user, group or namespace of the project, for instance n8n-io.

Use cases

resolve a repository before the rest of the run. One node gives you the identifiers and the default branch, and the downstream operations stop guessing which branch they should be writing to.

17

Get issues of a repository

repository.getIssues

What you see in n8n

Notes & use cases

Returns the issues of a repository, filtered server side rather than in a later node.

Key parameters

State, in Filters: opened, closed, or empty for any state.
Labels, Assignee, Creator and Search: narrow by label list, by username, or against the title and description.
Updated After: only issues touched at or after a date, which is how you build a daily digest.
Return All and Limit: the whole list, or a capped one.

Use cases

every Monday, list the issues updated in the last 7 days and post the digest.

User

1 operation

18

Get a user's repositories

user.getRepositories

What you see in n8n

Notes & use cases

Returns the repositories belonging to a user, group or namespace, one item per repository.

Key parameters

Project Owner: the user, group or namespace whose repositories you want, such as n8n-io.

Use cases

drive a loop with it. List the repositories of the team namespace, then run the same file or issue operation on each one, and a policy applies across the whole namespace instead of the repo someone remembered.

Need help

Need help automating GitLab with n8n?

A person reads every message.

FAQ

GitLab and n8n: the questions that come next

01Is the GitLab integration free in n8n?

Yes. The GitLab node and the GitLab Trigger ship with n8n, so there is nothing to install and nothing extra to pay on the n8n side. That holds on n8n Cloud, the hosted offer, and on a self hosted instance running the Community Edition under the Sustainable Use licence. A workflow behaves identically in both places, so you can prototype on one and run it on the other. What GitLab itself costs depends on your own plan and sits outside n8n. The only thing automation adds is the execution time of the workflows you decide to run.

02What credentials or permissions does the GitLab node need?

Two methods work, and both authenticate the node and the trigger. The first is an API access token: create it under Edit profile, then Access tokens, and enter it in n8n along with the URL of your GitLab Server, which matters on a self hosted instance. The second is OAuth2, the recommended one: register an application in GitLab, paste the OAuth Redirect URL that n8n shows into the Redirect URI field, and copy the Application ID and Secret into Client ID and Client Secret. On scopes, the api scope covers every operation the node exposes; pick narrower ones if you know exactly what you run.

03What are the limits of a GitLab n8n integration?

The node covers 5 resources: files, issues, releases, repositories and users, for 18 operations in total. Anything outside that list, and the GitLab API is much wider, goes through the HTTP Request node, which calls the endpoint directly while reusing the same GitLab credential. Two details catch people out. Listings are paginated, so without Return All the node stops at Limit and you silently miss rows. And the release operations identify the project through Project ID, the ID or URL encoded path, while file and issue operations use Project Owner, so a workflow often carries both values.

04Does the GitLab Trigger react in real time?

Yes, it works by webhook. When you activate the workflow, n8n registers a webhook URL with GitLab, and GitLab calls that URL each time a subscribed event happens, so the payload lands in n8n within seconds. There is no polling loop and no interval to configure, which also means an inactive workflow receives nothing. You choose what arrives through the Events parameter, among 12 event types covering pushes, tags, merge requests, pipelines, jobs, deployments, releases, issues, comments and wiki pages. A wildcard entry subscribes to all of them at once, which is handy while you explore the payloads.

05n8n or Make for GitLab automation?

It depends on where your constraints sit. Make is hosted only and billed per operation, which is predictable at low volume and grows with every extra step in a scenario. n8n runs on its own Cloud or on your servers, so a repository workflow that touches source code can stay inside your own network, and the cost follows the instance rather than the number of operations. Make has a visual editor many teams find faster to read at a glance. For GitLab specifically, the deciding factor is usually data control: code, issues and release notes are rarely the first thing a team wants to route through a third party.

Create a GitLab access token

Enter the credential in n8n

Or register an OAuth2 application

Every event, by family

Configuration notes

Need help automating GitLab with n8n?