When we opened the early access waitlist in October 2025, we asked a single question: which SCM platform does your team use? Roughly half answered GitLab before GitHub. We built GitHub first because it was what we knew and what our own codebase used. But the waitlist made it clear that launching GitLab was not optional if we wanted Codepylon to be useful to the teams that actually need it most.
GitLab support is live today. Here is what it covers, where it differs from the GitHub integration, and what is still coming.
What is supported
All four agents, Pylon-Patch, Pylon-Refactor, Pylon-Test, and Pylon-Migrate, work with GitLab repositories. The core job flow is the same: Pylon reads the repo, builds a context graph, runs the job, opens a merge request (GitLab terminology for a pull request), and posts a provenance block and review checklist in the MR description.
GitLab CI integration is supported. If you use GitLab CI for your test suite, Pylon reads the pipeline configuration and runs the appropriate test jobs in a sandboxed environment before opening an MR. The test result from the sandbox run appears in the MR description, the same as with GitHub Actions on the GitHub side.
GitLab issues integration is supported for job initiation. Assigning a GitLab issue to the Pylon service user triggers a job. The issue title and description become the job brief. When the MR is opened, it is linked to the originating issue and marks it as in-progress. When the MR merges, the issue is automatically closed. This mirrors how the GitHub Issues integration works.
The Codepylon web UI shows GitLab repositories alongside GitHub repositories in the same job queue view. You do not need a separate dashboard for each platform.
What is different from the GitHub integration
A few things work differently on GitLab, and you should know about them before you start.
The authentication model is different. GitHub uses an OAuth App or GitHub App with granular permission scopes. GitLab uses personal access tokens or group access tokens with role-based permissions. We use a GitLab service account with Reporter access for read operations and Developer access for MR creation. The permission requirements are documented in the GitLab setup guide in our docs. We request the minimum access level needed for each operation.
GitLab's approval rules interact with Pylon MRs in a way you should configure deliberately. If your project requires approvals from Code Owners and you have CODEOWNERS configured, Pylon-generated MRs will correctly request review from the code owners of the files they modify. This is the right behavior. One thing to check: if you have required approvals set to "minimum 1 approval from code owner," verify that the CODEOWNERS file reflects your current team. We have seen cases where CODEOWNERS was out of date and Pylon MRs were routing review requests to former team members.
GitLab's protected branch configuration interacts with Pylon's branch creation. Pylon creates branches matching the pattern pylon/[agent-type]/[ticket-id]. If your protected branch rules prevent non-maintainer users from creating branches, you will need to add an exception for the Pylon service account. The setup guide covers this.
Self-managed GitLab instances are supported. We route API calls through your instance's domain. If your self-managed instance is behind a corporate firewall, you will need to add Codepylon's egress IP range to your allowlist. The IP range is published in our security documentation and does not change without 30 days advance notice.
GitLab CI versus GitHub Actions: what differs for Pylon
The largest practical difference between the two integrations is how test pipelines are structured. GitHub Actions uses workflow YAML files per workflow. GitLab CI uses a single .gitlab-ci.yml with stages and jobs, and it supports include directives that pull in configuration from other files or project templates.
Pylon reads the full resolved pipeline configuration, following include directives to get the complete set of jobs. When the job description specifies which test stage to run (or Pylon infers it from the file paths in the diff), it runs only the relevant jobs in the sandbox, not the full pipeline including deploy stages.
One GitLab-specific detail: if your pipeline uses rules: with if: $CI_MERGE_REQUEST_IID conditions to run certain jobs only on MRs, Pylon's sandbox environment sets the CI_MERGE_REQUEST_IID variable to a synthetic value so those rules evaluate correctly. If your pipeline has more complex variable-based rules, check the docs for how to configure the sandbox environment variables to match your pipeline's expectations.
What is still on the roadmap
GitLab Epics integration is not supported yet. If your team uses Epics to group related issues, Pylon can initiate from individual issues within an Epic but does not have awareness of the Epic context. Job descriptions derived from issue titles will not include Epic-level context. If the Epic context is important for a job, add a summary of it to the issue description before assigning to Pylon.
GitLab Container Registry integration for scanning dependencies in containerized services is not supported in this release. Pylon-Patch reads dependency files (requirements.txt, package.json, pom.xml) but does not currently scan container image layers for additional vulnerabilities. This is on the roadmap.
GitLab's built-in security scanning (SAST, dependency scanning in GitLab Ultimate) produces its own advisory format. Pylon-Patch can read Grype and Trivy output, but it does not yet parse the native GitLab security report format directly. If you are using GitLab's native security scanning, export the results to a Grype-compatible format or configure a parallel Grype scan for Pylon to read from.
If you were on the waitlist specifically for GitLab, you should have received an email with access instructions. If you did not receive it, reach out to [email protected] with your email address and GitLab namespace and we will get you sorted.