n8n

How to Connect n8n to GitLab: Automate Your DevOps Pipeline (2025)

Rodrigo Ferreira

— 4 min read

GitLab is where your code lives, but it's also where a huge amount of manual DevOps toil hides: pinging teammates when a merge request opens, chasing down failed pipelines, and triaging new issues by hand. n8n changes that. By connecting n8n to GitLab, you can turn every push, merge request, and pipeline event into an automated workflow that runs while you sleep. In this guide you'll learn exactly how to wire n8n to GitLab in 2025 — authentication, the GitLab Trigger node, the GitLab action node, and raw REST API v4 calls — plus three concrete flows you can build today.

Why connect n8n to GitLab?

n8n sits between GitLab and the rest of your stack. Instead of writing a bespoke CI job or a webhook microservice for every little automation, you drag nodes onto a canvas. GitLab emits an event, n8n catches it, and you fan out to Slack, Jira, email, a database, or an LLM. Because n8n can self-host next to your GitLab instance, your tokens and payloads never leave your infrastructure — a real advantage for teams on self-managed GitLab.

Step 1: Create a GitLab personal access token

All GitLab authentication in n8n runs through a Personal Access Token (PAT) or a Project Access Token. In GitLab, go to User Settings → Access Tokens, give it a name, and grant the api scope (or read_api if you only need to read). For automations that comment on merge requests or create issues, you need the full api scope.

  1. Copy the token immediately — GitLab shows it only once.
  2. In n8n, open Credentials → New → GitLab API.
  3. Set the Server to https://gitlab.com (or your self-hosted URL) and paste the token.

That single credential now powers both the GitLab node and any HTTP Request node you point at the REST API.

Step 2: Catch events with the GitLab Trigger node

The GitLab Trigger node registers a webhook on a specific project. When you activate the workflow, n8n calls the GitLab API and creates the webhook for you — no manual setup in GitLab's UI. Pick the project (e.g. my-group/my-app) and choose which events to subscribe to:

  • Push — every commit pushed to any branch.
  • Merge request — opened, updated, merged, or closed MRs.
  • Pipeline — pipeline status changes, including failed and success.
  • Issue, Note (comments), Tag push, and more.

The trigger outputs the full GitLab webhook payload, so you immediately have fields like object_attributes.state, object_attributes.url, user.name, and project.path_with_namespace to route on.

Want to skip the wiring and ship real DevOps value on day one? The Automated AI Code Review template drops into n8n and has GPT-4o read every pull request — flagging bugs, security issues, and style problems as inline comments before a human even looks. Grab the AI Code Review template →

Step 3: Act on GitLab with the GitLab node

Where the trigger listens, the regular GitLab node acts. It exposes operations grouped by resource:

  • Issue — create, edit, comment, get, or lock an issue.
  • Release — create and manage releases.
  • Repository — get files, list contributors.
  • User — look up user details.

For merge-request-specific actions the GitLab node has limited coverage, so most teams pair it with the HTTP Request node (below) to post MR comments or approve MRs. A typical pattern: the GitLab Trigger fires on a pipeline event, an IF node checks object_attributes.status === "failed", and a GitLab node creates an issue titled after the broken pipeline.

Step 4: Go beyond the node with GitLab REST API v4

Whenever the built-in node doesn't cover an endpoint, reach for the HTTP Request node against GitLab REST API v4. Point it at https://gitlab.com/api/v4/..., choose your GitLab credential for authentication (it sends the token as a PRIVATE-TOKEN header), and you have the entire API surface.

Useful endpoints:

  • POST /projects/:id/merge_requests/:iid/notes — add a comment to a merge request.
  • PUT /projects/:id/merge_requests/:iid/approve — approve an MR.
  • GET /projects/:id/merge_requests/:iid/changes — pull the full diff to send to an LLM.
  • POST /projects/:id/issues — create an issue programmatically.
  • POST /projects/:id/pipeline — trigger a new pipeline.

Remember to URL-encode the project path (my-group%2Fmy-app) when you use it as :id, or just use the numeric project ID from the webhook payload.

Three flows you can build today

1. Merge request opened → notify Slack

Use the GitLab Trigger on the Merge request event. Add an IF node to keep only object_attributes.action === "open". Then a Slack node posts a message with the MR title, author, and a link to object_attributes.url. Reviewers get pinged in the right channel within seconds — no more MRs sitting untouched for a day.

2. Pipeline failed → create a GitLab issue

Trigger on the Pipeline event, filter for status === "failed", then use the GitLab node's Issue → Create operation. Populate the title with the branch and commit SHA, and the body with the failed job's URL. Add a label like ci-failure so the team can filter them. This closes the loop where flaky pipelines otherwise get silently ignored.

3. New issue → automatic triage

Trigger on the Issue event with action open. Send the issue title and description to an AI node (OpenAI / GPT-4o), ask it to classify severity and suggest labels, then use an HTTP Request node to PUT /projects/:id/issues/:iid and apply the labels. Bug reports get sorted the moment they land, so nothing rots in an untriaged backlog.

Best practices for production

  • Use Project Access Tokens instead of personal ones for team-owned automations — they don't break when someone leaves.
  • Add a Merge / IF guard early in each workflow so you don't act on every webhook; GitLab is chatty.
  • Handle rate limits — batch HTTP Request calls and add a Wait node if you loop over many MRs.
  • Log to a database or Slack so you can audit what the automation did, especially when an LLM is posting comments.

Ready to automate? The fastest path to real ROI is putting AI on your pull requests — GPT-4o reviewing every MR for bugs and security issues, posted as inline GitLab comments, fully hands-off. Get this template on Gumroad →

Read more