AI · SaaS
AI agents have changed how much code a team can produce in a day. Review queues haven’t kept up, and delivery stalls while changes wait for a closer look. The usual workarounds (reminders, reviewer rotations, assigning a team) buy a little time and then burn people out.
Client-side review with AI helps the author by catching issues as the code is being written, before a merge request even opens. But it only goes so far. A review that only checks quality still leaves the organization without enforceable policy on the way to production, since comments on a diff do not decide whether a change can merge or reach production.
Every merge request still needs a consistent certification step tied to pipelines, security findings, code owners, approval rules, and audits. Review in the author’s environment cannot standardize that work across all your projects, route policy-bound changes to the right person, or show leaders what the agent did before the change merges. As agents write more of the code, automated reviews need to happen in the platform that already tracks each change from plan to production, and where identity, policy, and oversight controls are already in place.
Earlier this year, we made Code Review Flow generally available on GitLab Duo Agent Platform, bringing that sign-off to the merge request and making agentic review part of the same platform where code ships. Teams can turn it on so every change is automatically addressed under rules you set once, at $0.25 per review, delivering an estimated 100x ROI. That predictable unit cost is low enough to leave automatic review on for every merge request, which is how reviews move at machine speed while staying cost-efficient at organizational scale.
Agentic reviews, built for how you ship
Code Review Flow is native to GitLab merge requests, so it covers your whole environment. It runs as a CI/CD job on your runners, whether GitLab-hosted or your own, so review executes in the same environment as the rest of delivery. It works the same way on GitLab.com, GitLab Dedicated, and GitLab Self-Managed, keeping inference under your control with self-hosted models when air-gapped or regulated environments require it. You also have the flexibility to choose which model acts as the foundation for agentic code review: GitLab-managed or your own self-hosted models.
When certification is the default on the merge request, teams get coverage, control, and follow-through in one place. Here are the key highlights for agentic code review with GitLab Duo Agent Platform:
Every merge request is reviewed, without anyone having to ask. Turn on automatic reviews at the project, group, or instance level and settings cascade. Authors don’t have to remember to request a first pass.
Standards you set once for how the group ships. Custom review instructions capture language conventions, security practices, and path-specific rules. A group can point the Code Review Flow at a template project so those standards travel with the work. Pair guidance with GitLab’s enforced security and compliance controls when a requirement must always hold.
Follow-through on every finding. Follow-up review rechecks what GitLab Duo Agent Platform already flagged, verifies fixes, and avoids repeating the same points. At that price, you can leave automatic reviews everywhere.
The right human, when policy requires one. Code owners and relevant approval rules still apply. Recommend Reviewers Flow suggests the smallest group that can satisfy those rules based on their level of expertise, workload, availability, and timezone.
How agentic code review works in GitLab
Within GitLab, code review happens on the merge request, next to your pipelines, security findings, and approvals.
A merge request opens (or becomes ready). Automatic review can start the Code Review Flow, or an author assigns GitLab Duo.
The flow runs as a CI/CD job on your runners, analyzes the change with repository and merge request context, guided by your custom review instructions and the models your group selected, and comments on the diff.
Authors and their coding agents push fixes. Follow-up review verifies Duo’s prior findings and carries context forward from the earlier pass.
When a human must approve, Recommend Reviewers Flow proposes who should take the request; you assign from the merge request.
Pipelines, security findings, approval rules, and the session record stay in the same place, so “reviewed” means certified on the path to production.
Watch agentic code review in GitLab in action:
What’s ahead
Our platform roadmap for agentic code review includes:
Deeper review when the change warrants it. An extended analysis pass will pull in calling code and tests for high-complexity merge requests, under your model-selection controls.
Clearer decisions on the merge request. GitLab Duo will be able to approve or request changes under settings you control.
Focus on risk. Risk assessment on the merge request will help teams see which changes deserve more attention.
Review before the merge request opens. Local review in Duo CLI will let developers run project review guidance against working-tree changes before the merge request runs the organization’s official check.
As agents write more of your code, you need reviewed code reaching production, with every change held to your standards and your reviewers focused on the changes that need a person. Every improvement on this roadmap is built to help you get there.
Getting started
If you are new to GitLab Duo Agent Platform, you can get access with a free trial. If you already are a GitLab Premium or Ultimate customer, you can simply turn on Duo Agent Platform and use the GitLab Credits included with your subscription.
This blog post contains "forward‑looking statements" within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.
Oct 15 · 00:00·GitLab
SaaS · Jobs & workplace
Agents are working across your team's software development lifecycle, but most still operate as separate tools, leaving the context, handoffs, and permissions for your team to stitch together. When your agents use APIs for these disparate tools, they often guess at endpoints and use up their context window on extra calls. The GitLab MCP server, now generally available with GitLab 19.5, connects your team’s external agents to your entire software lifecycle — from planning through production.
The GitLab MCP server enables any MCP-compatible agent to run GitLab workflows from the client your team already works in, getting what it needs in fewer calls and with less context bloat. Agents can work across code, merge requests, work items, and pipelines, and hand work to agentic flows within GitLab Duo Agent Platform. Each action runs under your existing GitLab permissions.
Built for how agents work
APIs are built for developers writing code. An agent that uses one has to work out which endpoints to call and make several calls to assemble one answer. Model Context Protocol (MCP) is an open standard built for agents. An MCP server tells an agent what it can do and offers a curated set of tools designed around real workflows. Agents get the tools they need with more focused context, in fewer calls, and needing less data to carry through each task.
The GitLab MCP server applies that approach to your workflows across your projects, supporting all your team members within the GitLab permissions you already set.
Whether you're a developer handing a task to an agent or a team deciding how agents should work across your organization, your agents get tool coverage broad enough to complete the work, with access that follows each user’s GitLab permissions. Developers can even start GitLab Duo Agent Platform flows from the MCP-compatible coding agent they already use.
Here is Claude Code using the GitLab MCP server to start the Fix Pipeline flow in Duo Agent Platform:
More of your workflow, within reach of an agent
In addition to the tools announced in 19.4, the GitLab MCP server now includes more tools for working with code and pipelines, and for finding the right group or doc.
Code: add_branch starts a feature branch, get_repository_file reads a file at any ref, and semantic_search finds code by meaning, answering "where is this implemented?" without knowing the file or symbol name.
Pipelines: get_pipeline shows why a pipeline is red, with its jobs, downstream pipelines, and artifacts on request. list_pipelines surfaces patterns across recent runs, and get_artifact_file reads a single file from a job's artifacts, such as a log, report, or test fixture, without downloading the whole archive.
Orientation: list_groups lets an agent browse your group hierarchy to find the right group instead of guessing at identifiers, and list_wiki_pages, an opt-in tool, surfaces runbooks and docs before it answers a how-to question.
In 19.5, the MCP server tool catalog is also simpler to work with. Related tools are now consolidated, with fewer tools doing more. get_merge_request lets you ask your agent for a merge request’s commits, diffs, pipelines, conflicts, or notes. get_pipeline now includes get_pipeline_jobs, so you can ask for a pipeline’s jobs along with the pipeline itself. Your agents spend less time choosing the right tool and pull in only the details a task needs.
Toolsets let you choose which groups of tools the server returns. Each agent works from a focused set of tools that fits your team’s workflow instead of everything the server offers. A smaller set makes it less likely that an agent picks the wrong tool and has to retry. Most groups are on by default, and code security and wikis are available as opt-in groups. Browse the full catalog in the tools reference.
Start GitLab flows without leaving your client
Calling tools is one way an agent works with GitLab. Now, an agent can also hand a job to GitLab Duo Agent Platform and follow that job to the result without leaving your client. It can find the flows a project offers with list_duo_agents_and_flows, start a new flow from a goal in plain language with start_duo_session, and check progress with get_duo_session and list_duo_sessions. The work runs in a CI job inside GitLab, under the same context layer, policy checks, and audit trail as any other Duo Agent Platform session.
When a session needs a decision, it pauses for your input. With send_duo_session_input, you approve or reject the agent’s proposed action, or answer its question, and the session picks back up, keeping you in the loop. The duo_agent_platform toolset is included by default alongside the rest of the GitLab MCP server's tools.
Connect your agents to GitLab today
The agents supporting your software lifecycle will continue evolving. As your team adopts new agents, the GitLab MCP server connects each one to GitLab’s tools and flows, so they’re productive from day one.
You can connect the agents your team already uses by following the MCP server documentation, which includes setup instructions for Claude Code, Claude Desktop, Cursor, GitHub Copilot, OpenAI Codex, Gemini, Kiro, Zed, and other MCP-compatible clients. The GitLab MCP server is available on the Free, Premium, and Ultimate tiers, on GitLab.com, GitLab Self-Managed, and GitLab Dedicated. On GitLab.com, per-user rate limits are set at 60 calls per minute on Free and 600 on Premium and Ultimate.
If you’re new to Duo Agent Platform, start a free trial. Already on Premium or Ultimate? Turn on Duo Agent Platform and use the GitLab Credits included with your subscription.
Oct 15 · 00:00·GitLab
Crypto · SaaS
Credentials often start in an engineer's local dev environments, then get copied into unscoped CI/CD variables to keep pipelines running. Stored there as a raw value rather than a reference to a scoped secret, a signing key reaches every job in the pipeline — compromised or not.
Standing up a standalone vault narrows that exposure but requires mirroring every change to project membership, protected branches, and production environments. When the vault falls out of sync, a pipeline breaks or an agent’s service account keeps access it no longer needs.
GitLab Secrets Manager tightens credential security without a second permission model. It is now generally available in GitLab 19.5 for Premium and Ultimate on GitLab.com and GitLab Self-Managed, with GitLab Dedicated coming soon. Built on OpenBao, it stores build-time and runtime credentials under the same permissions and audit trail as your code. Platform teams can offer developers self-service secrets, and security teams get credentials scoped to the jobs that use them, plus the pipeline and job ID on every CI/CD read.
"GitLab Secrets Manager lets us centralize secrets across CI/CD, Kubernetes, and infrastructure as code without standing up multiple vaults or maintaining separate integration points. It also strengthens our supply chain security by tightening which users and pipelines can access a given credential." - Jeremy Nauta, Software Architect, OneTrust
How Secrets Manager scopes build-time secrets to each job
Agents can take actions no one anticipated, so security teams need to regard every job as if its agents will use any credential it can reach. Secrets Manager narrows what agents can reach with the context GitLab already holds about each job: its project, the branch it runs on, whether that branch is protected, and the environment it targets.
A developer declares the secret a job needs with the secrets: keyword in .gitlab-ci.yml, and GitLab injects the value only into jobs that declare it and fall within its scope. Scope conditions accept wildcards on branch and environment, and they combine, so one rule can require a protected branch and a production/* environment before a job receives the credential.
Inside the job, GitLab writes the value to a temporary file and exposes only its path, which limits exposure in subprocesses, crash dumps, and telemetry. GitLab masks the value in job logs and discards it when the job ends. Unlike a CI/CD variable, a secret is never readable in your project configuration.
OpenBao encrypts secrets at rest with AES-256-GCM, so a copy of the secrets database holds only ciphertext. Jobs fetch values straight from OpenBao with short-lived tokens bound to each job’s identity, which keeps plaintext secrets out of the GitLab application.
See how to get started with Secrets Manager:
Revoke and trace an exposed credential
When the axios npm package was compromised, a SANS advisory warned teams to "assume all environment variables on affected systems were exfiltrated" and extend investigations to CI/CD runners and build infrastructure. Responders had to work out which credentials each affected job could read, how to cut off access, and which runs read them.
With Secrets Manager, when a job runs a poisoned dependency, the exposure stops at the secrets that job declared and was authorized to read. To clean up, revoke and replace the leaked credential, update the value in Secrets Manager, and audit that one job while other pipelines keep running. Secrets Manager prompts you to set a rotation reminder when you create a secret. Dynamic credentials are coming soon and will provide ephemeral access without manual rotation.
GitLab streams every secret create, read, update, and delete event to your audit event destinations and records changes in the audit trail. Each pipeline read carries the pipeline and job IDs, which tie to the commit, the triggering user, and the merge request, when there is one. Incident responders and auditors can trace a read to the change behind it without correlating logs from a CI system, a vault, and an identity provider. Audit events never contain secret values.
Govern secrets with the permissions that govern your code
As agents take on more work, platform teams field more requests for pipelines and service accounts that need credentials. When those requests queue, teams fall back on broad grants and shared secrets.
Secrets Manager uses the GitLab namespace as its isolation boundary. Projects inherit secrets defined in the groups above them, so you define a shared credential once. Owners grant read, write, and delete permissions to specific users or default roles, using the same membership model that governs the code. Remove a person or an agent's service account from a project, and that identity's access to the project's secrets ends.
Developers reference secrets through the project access they already hold. When a secret reference breaks, they fix it in the same merge request as the code, with no second repository, approver, or access ticket. With a governed credential one line away, fewer secrets end up in over-scoped CI/CD variables, local files, or the repository.
One store for pipelines and runtime workloads
Kubernetes, Terraform, and scripts often get separate secret stores, each with its own access model and logs. Secrets Manager serves runtime tools from the same store as pipelines, under the same permissions and audit trail:
Kubernetes, through External Secrets Operator. ESO re-fetches the secret on a set interval and updates the Kubernetes Secret in place, so a rotated value reaches the cluster without a pipeline run.
Terraform and OpenTofu. They read a secret as a data source at plan or apply time and keep credentials out of .tfvars files and CI/CD variables.
OpenBao and Vault CLIs, through the Vault-compatible API. Teams keep their existing scripts and point them at Secrets Manager.
Other runtime tools, through the Secrets Manager API.
Each runtime tool authenticates with a service account or an access token, and that identity needs project membership and explicit read permission for the secret. GitLab then issues a separate token, valid for five minutes, that the tool uses to fetch it.
How Secrets Manager fits with GitLab's supply chain controls
GitLab’s governed software factory connects code, pipelines, packages, and secrets on one platform, with one identity model and one record of how a change reached production. Dependency Firewall decides which packages enter a pipeline, Secrets Manager limits which credentials the pipeline can reach, and Artifact Central governs what you ship.
Secrets Manager supports two of the five stages in the GitLab Security Standard, GitLab's framework for letting agents earn autonomy: For Authorize, it binds each job to the secrets its identity and scope allow, and for Respond, it streams every CRUD event.
Secret push protection blocks commits containing credentials before they reach the repository, and Secret detection finds the ones already in your code and history. GitLab Duo Agent Platform triages what those scans find and flags likely false positives, so your team revokes, rotates, and audits only real leaks.
GitLab's existing integrations for HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Cloud Secret Manager keep working alongside Secrets Manager, so you can migrate at your own pace.
Get started
GitLab Secrets Manager is a paid add-on for Premium and Ultimate, billed through GitLab Credits: 1 credit per secret stored per month, and 1 credit per 2,500 read operations. An enterprise license agreement is available for air-gapped environments.
On GitLab.com, top-level group Owners can try GitLab Secrets Manager free for 30 days or 500 evaluation credits, whichever ends first. Go to your top-level group, select Secure > Secrets Manager, then Start 30-day trial.
On GitLab Self-Managed, your administrator must install and enable Secrets Manager, following the documented sizing and high-availability guidance.
GitLab Dedicated support is coming soon.
To find the first credentials to move, run the secret audit tool for CI/CD variables, which flags variables likely to hold credentials. A migration workflow for CI/CD variables is in development.
Have suggestions or feedback? Share them in the Secrets Manager feedback issue.
Oct 15 · 00:00·GitLab
AI · SaaS
As AI models take on longer, multi-step work, the challenge is putting that power to use across the software lifecycle without adding risk or cost. Teams need to be able to move faster, within enterprise controls and guardrails.
Google's Gemini 4 Argon, now available on GitLab Duo Agent Platform, was built for that kind of work. With Argon, your team can delegate long, multi-step actions and receive outputs for review. In GitLab's internal evaluation, Gemini 4 Argon completed 93.3% of GitLab’s software engineering benchmark tasks.
Reliable execution for long-horizon tasks
Work across the software lifecycle demands persistence and steady attention. Argon sustains its reasoning across the many steps of a task, reading files, running commands, and editing code through to completion. Your engineers can delegate to GitLab Duo agents powered by Argon with confidence and spend their time reviewing results instead of monitoring runs.
Google trained Argon to respect system boundaries, tell you when it couldn't find something or finish a task, and pause for confirmation before an irreversible step. Teams can hand off complex tasks and stay in control of the important decisions.
In internal evaluations, Argon resolved 73.3% of GitLab’s benchmark tasks, with each change passing the benchmark’s tests across multiple programming languages. Of the runs that hit a tool error or timeout, Argon still completed 93.8% of them, so a single failure mid-run won’t force your team to start over. Agent output lands in a merge request, where your team reviews the result with the full context of the change.
Argon works through problems thoroughly, making it a strong model choice when finishing correctly matters more than finishing fast.
Choose the Gemini model that fits your workload
Gemini 4 Argon is Google's newest frontier model and the most performant Gemini model on GitLab Duo Agent Platform. It handles long-horizon agentic actions especially well, including tasks that begin loosely defined. It pairs with the Flash models, which offer a lower-cost option for high-volume work, so you can match each workload to the best Gemini model. Whichever Gemini model you choose, it runs inside the same context layer, policy checks, and audit trail that cover every agentic action across your software lifecycle.
Try Argon on GitLab Duo Agent Platform
Gemini 4 Argon is available now on GitLab Duo Agent Platform. Like other models, it runs on GitLab Credits. Argon is available at promotional pricing of 2.86 calls per credit, through November 30, 2026. Starting December 1, standard pricing applies at 1.33 calls per credit.
If you already use GitLab Duo Agent Platform, you can try Argon today by choosing Gemini 4 Argon in model selection. GitLab Premium and Ultimate customers can turn on Duo Agent Platform and try Argon using the GitLab Credits included with your subscription. New to Duo Agent Platform? Start a free trial today.
Oct 14 · 00:00·GitLab
SaaS · Software & IT
A deep dive into how D1 architected its control plane to scale and manage millions of databases, while keeping data plane query operations at the edge. We share guiding principles on how to build on the Developer Platform effectively.
Oct 13 · 16:20·Cloudflare
SaaS · Cybersecurity
New Open Compute Project (OCP) working group: Companies form a new working group to standardize on a silicon-based and attested secure integrated hardware security module (HSM) solution for cloud and hyperscale data center infrastructure. Strengthening cloud security: Secure key caching and attestation cryptographic key lifecycle management at the server level will reduce latency, improve scalability and strengthen t
Oct 13 · 13:00·Marvell Technology
AI · SaaS
AI coding tools have changed how fast software gets written, but not how fast it ships. As code generation accelerates, the bottleneck moves downstream into verify, review, and ship. Those stages still run on human time. While agents write fixes in minutes, delivery slows on constant wait times and manual handoffs. Reviewer signoffs, pipeline alerts, scan triage, and step-by-step prompting are examples of obstacles DevOps teams face in maintaining on-time delivery.
At GitLab Transcend, we announced new agent orchestration capabilities in GitLab Duo Agent Platform to eliminate that delay. Goal-driven flows take the outcome you define and run it end to end, through review, tests, security scans, and approvals from Duo CLI, headless mode, or Agentic Chat. GitLab for Slack starts work from the conversation where it was requested, like turning a thread into an issue or kicking off a flow to fix a failing pipeline. Custom Flows let you define your own multi-step sequences and start them from GitLab events like a mention, an assignment, or a pipeline. All three run under your identity, policy, and evidence chain.
How agentic orchestration speeds up delivery
Faster coding, process checklists, and single-chat coding agents all contribute to delays in software delivery. With agentic orchestration capabilities, you can accelerate each stage and reclaim time for your development team.
Fewer handoffs. You name the goal, and the flow keeps working across review, tests, scans, and approvals instead of stopping between each step.
Start work where the request already is. A Slack thread becomes an issue or a flow immediately from where you’re already discussing the work.
Automate the process your team already follows. Custom Flows let you define your own multi-step sequences and start them from a mention, an assignment, or a pipeline.
Stay in control. Flows run under the same identity, policy, and evidence chain as the rest of GitLab, so governance stays with the work. Foundational agents and flows already cover plan through analyze stages in the GitLab UI, your IDE, and Duo CLI, and you can enable more from the AI Catalog, bring in external agents, and connect tools through the MCP client and the MCP server.
Goal-driven flows: Set your objective
Goal-driven flows give agents the finish line instead of the next step. You describe the objective and what done looks like, and the flow keeps working until it gets there. Goal-driven flows automate handoffs, so review, tests, security scans, and approvals run as one connected sequence.
You start one with the /goal command, for example:
/goal Fix the checkout timeout. Continue until tests pass and CI is green.
A separate model checks the work against your goal at each step, and you can stop or redirect a run at any point. You can start a goal-driven flow in Duo CLI, in headless mode with duo run --goal, and in Agentic Chat.
GitLab for Slack: Start where the work gets discussed
GitLab for Slack lets you start work in GitLab without leaving Slack. Mention @GitLab in any channel or thread and describe what you need, such as "fix the failing pipeline," and a flow starts. Duo streams its progress back into the thread, so your team follows the work where the conversation is already happening. The flow runs under the same identity and policy as any other GitLab flow, so governance stays in GitLab. You can also use @GitLab to ask questions about your codebase or create an issue from the conversation.
Custom Flows: Turn your process into a flow
Custom Flows chain agents together to match the process your team already follows. You define a flow once, start it from GitLab events like a mention, an assignment, or a pipeline, and run it in CI/CD pipelines. A self-healing pipeline, for example, can analyze a failed test, generate a fix, commit it, and notify your team, with human-in-the-loop checkpoints at sensitive steps. Each flow runs under the same identity, policy, and evidence chain as every other flow, so governance stays in GitLab.
Put agent orchestration to work
To achieve the benefits of agent orchestration, start with goal-driven flows. The documentation for Duo CLI slash commands walks you through /goal. Goal-driven flows are available on GitLab.com, GitLab Self-Managed, and GitLab Dedicated, on the Premium and Ultimate tiers, and require GitLab 19.3 or later and Duo CLI 9.17.0 or later.
Then extend that orchestration to your team's processes and channels with Custom Flows, which are generally available, and the MCP server and GitLab for Slack, which will be generally available later this month.
To design the foundation for your software factory, check out GitLab Duo Agent Platform. New to GitLab? Start a free trial of GitLab Duo Agent Platform. Already on Premium or Ultimate? Turn on GitLab Duo Agent Platform and use the GitLab Credits included with your subscription.
Oct 13 · 00:00·GitLab
AI · SaaS
Costs multiply with every task you hand to an agent. Each task consumes tokens and credits, and as agents spread across your teams and automations, consumption can grow faster than usage. If you run the platform, you own that growth, including which teams and workflows drive it and whether the usage ships work.
At GitLab Transcend, we introduced the governed software factory, our architecture for agentic software engineering, and new capabilities in GitLab Duo Agent Platform that bring that growth under control. GitLab-managed open-weight models matched frontier-model task completion at a fraction of the cost in GitLab's benchmark, so you can align your model to the task to improve your team’s cost efficiency. GitLab Orbit gives agents lifecycle context so they retry less. Duo Agent Platform Impact Analytics and credit caps show where credits go and put a limit on them.
Control costs in the governed software factory
A usage total tells you what you consumed, and leaves hard questions open: how much routine work sat on an expensive model, how many agent runs were wasted retries, and which users and teams burned through the credits. When the dashboard only shows tokens, platform and engineering leaders end up debating a number neither side can stand behind. If you can't attribute the usage, set a limit, and cut the waste, you can’t optimize or justify your spend.
Breaking that pattern starts with the architecture. The governed software factory is built in layers, and cost grows where those layers don't connect. Two of those layers matter most for cost. The first is agent orchestration, where open weight models put routine work on lower-cost models. The other is data and context, where Orbit, Duo Agent Platform Impact Analytics, and credit and usage controls give humans and agents the context to produce high-quality outcomes at the lowest possible cost.
You can see the problem in a shadow software factory, where each stage has its own tool, with no shared policy or context between them. Agents spend tokens searching for context across systems that were never built to integrate. A governed software factory gives agents shared context, shared policy, and one place to measure what they cost. When every AI credit counts, you can:
Spend fewer credits for the same work: Match models to the task at hand with open weight models, and ground agents in lifecycle context with GitLab Orbit so they retry less.
Trace spend to its source: See credits by user, team, task, and model in Duo Agent Platform Impact Analytics and the GitLab Credits dashboard so you can point to what drove the growth.
Set a ceiling before the next spike: Cap usage per user with credit caps, with overrides where needed, so agent loops stay inside the limits you set.
Match the model to the task
Agent cost starts with the price of each model call. GitLab Duo Agent Platform lets you pin a default per feature and control what your teams can use: your own model, self-hosted or from your provider, GitLab-managed frontier models, or GitLab-managed open-weight models, new in GitLab 19.4.
Three open-weight models are now hosted in GitLab Duo Agent Platform: GLM 5.3, Kimi K3, and MiniMax M3. In GitLab's internal benchmark with Duo agents, GLM 5.3 matched Claude Opus 5's task completion at approximately one-fifth the cost, Kimi K3 matched Claude Fable 5.1 at one-third the cost, and MiniMax M3 matched GPT-5.5 at one-eighth the cost. Model choice is an admin setting. In your top-level group's GitLab Duo settings, open Model Selection, select Manage Models, and pin a model to each feature. For example, pin Kimi K3 to Agentic Chat and MiniMax M3 to agents and flows, so routine work does not default to a frontier model. Group Owners also choose which models their teams can use.
Cut retries with the right context
Model choice sets the price of each call, and retries multiply the number of calls. Gartner found that a team of 40 developers spent 23 times more on AI because agents kept retrying without the right rules and context. Agents retry when they lack context. Across a monorepo or several repositories, an agent spends its first stretch crawling files to work out what connects to what, and every retry resends the full context window.
GitLab Orbit maps your code, work items, merge requests, pipelines, deployments, and security findings into a single graph that stays current as your teams ship. Agents in GitLab Duo Agent Platform query it natively. External agents like Claude Code and Codex connect through Model Context Protocol (MCP), and custom tooling connects through the REST API. Every agent sees exactly what its user can see in GitLab.
With that context, an agent asks the graph and gets a precise answer faster and more efficiently. In GitLab testing, the same task in Claude Code needed up to 45x fewer retries with Orbit and, separately, used 4.5x fewer tokens to get the right context the first time. Orbit is in free beta on GitLab.com today and reaches general availability next month across all deployment options.
Manage what you can measure
Models and context lower the cost of each task. Impact data shows whether it worked. Duo Agent Platform Impact Analytics answers the two questions platform leaders ask: how much are we spending, and where is that spend concentrated? It breaks spend down by team, task, and model for the teams and date range you choose, and it shows how an open weight model stacks up against your current model mix, so you compare with data instead of guessing. The GitLab Credits dashboard adds detail below the team level, tracing usage to the user and session behind it.
Visibility pairs with limits. Without a limit, the only lever left is asking everyone to use less. Credit and usage controls set caps at the subscription, group, or user level, with alerts at 50%, 80%, and 100% of spend and an automatic pause once usage reaches the cap. A flat per-user cap, such as 1,000 credits per user/per month, applies to every team member, and an individual override, such as 500 additional credits, gives an engineer who is experimenting room to work without asking for more. Per-user caps apply once a user has consumed their included credits, and only the capped user loses access to credit-consuming features, until the next billing period or until an administrator raises the cap.
Duo Agent Platform Impact Analytics shows credit consumption alongside the work that reaches production, so you can see whether usage is turning into delivered work.
See Duo Agent Platform Impact Analytics in action in this demo from our Transcend global event:
Put agent cost control to work
Start your agent cost control journey with the model. GitLab-managed open-weight models are generally available. In Model Selection pin GLM 5.3, Kimi K3, or MiniMax M3 to a routine workload, such as a flow that runs on every merge request.
Next, cut retries. GitLab Orbit is in free beta on GitLab.com today. Turn it on for the group that runs the most agent sessions. Orbit reaches general availability next month across all deployment options.
Then, measure and set limits. Duo Agent Platform Impact Analytics is in early access, so you can see spend by team, task, and model. Credit and usage controls are generally available. Set a per-user cap for GitLab Credits with overrides for your heavy users. After a few weeks, compare usage by team and model against the previous period.
Design the foundation for your software factory with GitLab Duo Agent Platform. If you're new to GitLab, start a free trial of GitLab Duo Agent Platform. If you're on Premium or Ultimate, turn on GitLab Duo Agent Platform and use the GitLab Credits included with your subscription.
Oct 13 · 00:00·GitLab
AI · SaaS
AI agents are fundamentally changing the economics of software development. As the cost of producing code falls, the volume of changes moving through the software factory is accelerating beyond what infrastructure designed for human developers was built to handle.
GitLab anticipated this shift and began developing next-generation source code management (SCM) to support thousands of concurrent agents working against large repositories. In June, we announced next-gen SCM at GitLab Transcend, joined on stage by Nick G. from Anthropic's source control team. We've continued collaborating on the technical challenges of agent-scale development, and in August we shared more of our architecture and early performance results.
This week, Anthropic provided a compelling demonstration of why this work is so important. As daily merges to its monorepo grew from approximately 2,500 in May to more than 30,000 in September, its engineers built Scion, a specialized source control system designed for their environment.
Anthropic's experience reinforces the architectural direction we've been pursuing. Scion is purpose-built for enormous monorepos where nearly all clients are agents that are always online. Anthropic acknowledges that its approach isn't a general-purpose replacement for Git and requires its own code review, search, and CI infrastructure.
GitLab is building for the broader enterprise market: delivering agent-scale performance while preserving Git compatibility, infrastructure choice, and integration with the software development lifecycle.
"Scaling our monorepo for agentic development has changed how we think about Git server architecture. We see room to expand what Git servers can do for these workloads without departing from the overall Git model."
— Nick G., Source Control, Anthropic
Built on Git. Designed for agents.
Traditional Git workflows require clients to download substantial repository data, even when an agent needs only a small portion. A single agent invocation can involve 5–10 GB of data transfer and more than 30 seconds of setup, just to answer one question. Multiply that overhead across thousands of agents and source control becomes a bottleneck.
Most enterprises can't move source control onto new infrastructure just to scale it. Next-gen SCM preserves the Git protocol while modernizing the architecture underneath. Stateless compute scales horizontally against shared object storage, while agent-native interfaces let agents request the files and history they need without repeatedly cloning entire repositories.
In early internal tests, workloads completed up to 50x faster, used up to 2x fewer tokens, and generated up to 1,000x less network traffic compared with conventional workflows. These are peak improvements under specific test conditions, and we're continuing to validate performance under sustained, concurrent load.
The same architecture is designed to run on GitLab.com and on S3-compatible storage that customers control, including in air-gapped data centers. Repository data stays within the customer's infrastructure, preserving data sovereignty and existing investments while delivering the scalability agentic development demands.
For a closer look at the architecture and what we're building, watch Mark and Kranthi's latest next-gen SCM update:
Source control is only the first bottleneck
Speeding up source control alone moves the bottleneck downstream. An agent that writes code in seconds creates little value if the resulting changes spend hours waiting for validation, security review, or deployment.
Traditional merge queues and CI workflows face growing pressure when agents generate changes faster than validation can complete. We're seeing this pressure across GitLab.com. Over the past year, customers created 40% more CI/CD pipelines, while code pushes increased 50%. Agent-scale CI will need to validate more changes with less compute per change while preserving evidence of what was tested and verified.
This is why next-gen SCM is part of GitLab's broader vision for a governed software factory. As agents accelerate software production, source control, context, orchestration, CI, security, and governance must evolve together.
We're designing next-gen SCM to let thousands of agents work in parallel in isolated sessions, where unsuccessful experiments can be discarded without disrupting shared code. Successful changes can flow into GitLab's existing merge requests, pipelines, security checks, and governance controls on their path to production.
GitLab Orbit is being developed to provide a context graph of the entire software lifecycle, while GitLab Duo Agent Platform orchestrates agent work across stages. We're also advancing capabilities to make agents accountable for their work, including attribution and authorization of agent actions, preserving the instructions and decisions behind code changes, and giving reviewers the context needed to focus human judgment where it matters.
The goal is to reduce the time and total cost of moving software from intent to production, even as the number of agents and changes grows dramatically.
We believe a governed software factory offers the best economics for agentic development: more software delivered at lower cost per change, with the security and control enterprises require.
Advancing Git through open collaboration
Git's open ecosystem has been foundational to modern software development, and we believe it will remain essential in the agentic era. GitLab has long been an active contributor to Git, and we'll continue working with the community to advance the standard that millions of developers and tools depend on.
Our next-gen SCM architecture builds on that foundation, combining Git compatibility with a redesigned backend and agent-native interfaces designed to deliver the performance and scalability these new workloads demand.
This approach preserves the investments customers have made in Git while allowing GitLab to innovate rapidly across the broader software lifecycle. Our differentiation is the governed software factory: bringing source control, context, orchestration, security, and governance together on one platform.
What's next
Next-gen SCM is in private beta, and we're working with customers to validate performance against their own repositories and workloads.
As agents dramatically increase software production, the entire software factory must operate at machine scale. GitLab is building that foundation.
Request early access to next-gen SCM and evaluate it against your own repositories.
This blog post contains "forward-looking statements" within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.
Oct 13 · 00:00·GitLab
Crypto · AI
Every software build is assembled from open source packages, base images, and libraries, with your code on top. When one of those components is missing or has drifted, the build fails. At agent speed, those failures multiply, and no team can clear them as manual exceptions.
Project-by-project registry sprawl makes it worse because retention rules, storage limits, and publish access all live separately inside each project. Project-level design works when a person sets up each registry by hand, but breaks down when agents are running continuously across hundreds of projects.
At GitLab Transcend today, we announced GitLab Artifact Central: one organization-level registry that replaces hundreds of project-level ones, so every pull or publish by a human or an agent runs through the same governed door, enabling platform teams to assemble the right software the first time.
Here is more on why we developed Artifact Central, and how it can help your team.
Set policy once, enforce everywhere
In GitLab, retention rules, storage limits, and who can publish all live inside each project’s free package and container registry, configured on its own. GitLab Artifact Central moves that job up one level. Teams assign retention rules, quota settings, and access policies once at the organization level, instead of recreating them in every project underneath it.
Every repository is closed by default: Being a member of the organization is the gate, not the grant. Organization membership alone doesn't unlock a single repository until a role grants it. We’ve built four roles specifically for artifacts: Admin, Manager, Contributor, and Viewer. These roles are kept separate from GitLab's existing project roles, so granting someone access to a repository never touches their privileges anywhere else.
One URL for publishing, proxying, or both
Instead of navigating an internal wiki page explaining what is where, developers point to one URL for everything. GitLab Artifact Central does this through three repository types:
Hosted — The private packages and images your teams build and publish.
Remote — A proxy in front of an external source, like Docker Hub or Maven Central, with the connection tested before anything depends on it.
Virtual — A single endpoint that brings hosted and remote repositories together. GitLab checks the hosted repository first, then falls back to the remote source. The first external pull is cached, so subsequent pulls come directly from GitLab without another trip to the internet.
Virtual repositories matter most for teams comparing GitLab with other artifact management solutions. They give developers the familiar single-endpoint experience without requiring them to think about where an artifact lives. Whether it was built internally or pulled from an external registry, developers request it the same way. During the beta period, Artifact Central supports Maven, npm, Docker, and OCI, with more formats to follow.
Trace anything back, automatically
Here's the part that's hard to replicate outside GitLab. Every artifact that publishes through GitLab Artifact Central carries its build provenance automatically: which pipeline built it, which branch and commit it came from, who triggered the job. Since it is the same platform that ran the build, the registry already knows.
Authentication works the same way. Publishing and pulling use CI_JOB_TOKEN, the identity your pipelines already have, for people and agents alike. An agent publishing or pulling through CI pipelines uses that exact same job token, not a bolted-on service account with separate permissions to maintain. With a standalone registry, tracing an artifact back to its source means separately correlating IDs across your CI system and your registry – using a script someone owns and maintains. With Artifact Central, the pipeline, branch, commit, and job are already attached to the artifact itself.
Answer 'what did we publish?' in seconds
Artifact Central lives in the same platform as your code, merge requests, and pipelines, so artifacts published from CI carry their build provenance: the pipeline that built them, the commit, and who published them.
Next, we plan to connect that across your organization through GitLab Orbit, so "which of my running services are affected by this vulnerability?" becomes one question with one answer, instead of a manual search across four or five tools.
Pair Artifact Central with Dependency Firewall
GitLab Dependency Firewall, a separate GitLab product now in early access for Premium and Ultimate customers, works out of the box with Artifact Central. With Dependency Firewall, you can stop risky packages before they ever reach a build. You add its check to each pipeline using the glab CLI, so coverage is pipeline by pipeline, no matter which package manager your teams use. Next, we plan to enable tighter integration between the two capabilities, so that one policy for your whole organization blocks risky packages by vulnerability, license, or package age the moment they're pulled.
Two benefits of the same registry
Here's what that looks like from two different desks: a developer shipping code, and the platform team making sure the whole thing holds together.
A developer publishing from CI. Your pipeline publishes a Maven artifact using the job token it already has without any new secrets to manage. If that same developer needs an internal package alongside something from Maven Central, they point at one virtual repo URL and let GitLab Artifact Central sort out where each one actually lives.
A platform team setting policy once. Instead of configuring rules across 100s of separate projects, an admin sets storage quotas and repository access rules at the organization level, one time — and every repository underneath inherits it. When someone asks how much the company is storing, and where, there's one dashboard with the answer.
Migrating your artifacts
Most companies aren't starting from zero, and switching cold from an existing registry isn't realistic. With GitLab Artifact Central, you can add your existing repos as remotes behind a virtual repo, so developers point at one URL and artifacts move over only when a build actually asks for one. There is no need for bulk copies, weekend migration windows, or moving petabytes of data across your network.
Your old registry remains the system of record. When you're ready, you convert that remote to a hosted repo on Artifact Central. Your migration is safer and gradual.
Try Artifact Central, free in beta
GitLab Artifact Central is available today in beta for GitLab.com, with availability on GitLab Self-Managed planned for later this month. There's no billing during the beta, and nothing to purchase. We're tracking usage to shape pricing ahead of general availability, and we'll share details then.
Help us continue to build GitLab Artifact Central
None of this would be where it is without our design partners, who've been running Artifact Central with real workflows for weeks. Their feedback already shaped what's shipping today, and your feedback will shape what comes next.
No invitation is required to participate in the beta of Artifact Central, just sign up on our website and a member of our team will be in touch to help enable it for your account. If you don’t have a GitLab account yet, you can also sign up for the beta, and a member of our team will reach out.
We can't wait to see what you build.
Watch the replay of our Transcend event to see demos of new platform capabilities and explore what it takes to carry the speed of agentic AI across the full software lifecycle.
Oct 6 · 00:00·GitLab
Crypto · AI
Attackers disguise malicious packages as ones you trust. In June 2026, GitLab researchers found five malicious PyPI packages, four of them typosquats of Flask, Requests, and NumPy, that run at install time and steal CI/CD credentials. Additionally, AI coding agents now add open source dependencies on their own, often unreviewed, so developers don't have oversight into what packages may contaminate your build.
Once a malicious or vulnerable package enters your build, its code may run with the same access in your CI pipeline, and it can then reach any system your pipelines touch.
GitLab Dependency Firewall, introduced today at Transcend in early access, can block packages that match your policy, including malicious, vulnerable, and non-compliant packages, before they reach your build. Built-in governance stops risk before install, so your team doesn’t have to trace, remove, or rebuild what a policy blocks. Developers and their agents can keep pulling the dependencies they need without waiting on a manual security review, and packages that satisfy your policy requirements become part of your official build.
Block malicious packages without breaking your build
Without a policy at the point of install, a bad package goes into the build first and gets caught later. Software composition analysis (SCA) scans what you've already pulled in, so by the time it flags a malicious package, a high-severity vulnerability, or a license your legal team won't accept, the dependency is installed and may have shipped in an artifact. Tracing where it went, pulling it out, and rebuilding turns a routine pipeline run into unplanned work for your engineering team.
With Dependency Firewall, you decide what's allowed into your builds before it's installed, by defining policies for:
Malicious status — packages flagged in GitLab's malware advisory database
Vulnerability severity — the severity you set (critical, high, medium, or low) and the number of findings you allow at that level, including zero
License type — the licenses you allow or deny, listed by full name, and how to handle packages whose license can't be determined
Package age — the minimum age a package must reach before it can enter a build, so a version published minutes ago can't go straight in before anyone has vetted it
Rolling out enforcement does not have to put delivery at risk. Start in warn mode, where the firewall records what a policy would catch, but lets the build continue. It leaves an audit event, a dashboard entry, and a line in the CI summary, so you can analyze whether or not to block the build.
Once you trust the policies, switch to block mode, which stops the pipeline on a match and gives the reason. When someone has a real need to get an approved package through, a logged bypass lets a designated user or token proceed, on the record.
Set policy once, or tailor it by team
A firewall that enforces only at the registry gives everyone the same policy, but that rarely fits how teams actually work. A payments service and an internal prototype carry very different risk, and your policy should treat them differently.
With Dependency Firewall, you set one policy at the top-level group and every project beneath it inherits the same rules. When a team needs something different, you can set a policy for that group or project.
You can also enforce policy at the registry, so every pull is checked, not just pulls from a pipeline. Rules live as code in a security policy project, so they are reviewed and changed through a merge request like the rest of your configuration. They inherit from the top-level group down to each project, and where rules overlap the strictest one applies. A critical service can be held above the organization's baseline, and no project drops below it.
Check a package before you pull it in
A developer, or an agent working on their behalf, usually finds out a package is not allowed only when the pipeline fails. That costs a build cycle and breaks concentration, right when the work is moving.
You get the answer from GitLab Dependency Firewall before you add a dependency, in the place you already work, allowing you to pick a package that passes the first time.
Using GitLab CLI within the terminal or within a script, a command line check can identify if a package will pass or be blocked by your policy, without requiring developers to open a separate console. It covers common package managers such as npm, pip, Poetry, Maven, Gradle, and Bundler, with more coming soon.
See and prove every decision
A security leader has to be able to prove what a control is doing during an audit. A control that blocks quietly, with no record, does not answer the auditor’s question and does not build trust with the teams it governs.
You get one view of what the firewall has allowed, warned against, and blocked, with an immutable record of each decision you can hand to an auditor.
A Dependency Firewall dashboard shows activity and outcomes across the projects in scope. Every warn, block, and bypass writes an audit event that records the rule that matched, the policy behind it, and the package involved.
Get early access to GitLab Dependency Firewall
You can stop malicious, vulnerable, and non-compliant packages before they reach a build. It is compatible with GitLab Artifact Central and external registries from Sonatype Nexus Repository and JFrog Artifactory, and does not require standing up a separate tool next to your GitLab deployment. Dependency Firewall is now in early access for GitLab.com and GitLab Self-Managed customers in the Premium or Ultimate tier. Request early access today!
Oct 6 · 00:00·GitLab
Crypto · AI
At Transcend, we made over a dozen announcements across all four layers of our architecture for agentic software engineering: agent orchestration, data and context, DevOps workflows, and governance and security. Watch the replay, or read on for what shipped and how to turn on the new capabilities.
At a glance
What we launchedRelease statusWhat it does
Goal-driven flows (/goal)GA this monthCarry a change through review, tests, scans, and approvals without waiting between stages of the software lifecycle.
Custom FlowsGAChain agents together to match the process your teams already follow for software delivery.
GitLab for SlackGA this monthStart an agentic flow from the channels where your teams already work.
MCP ServerGA this monthSecurely connect AI tools and applications into GitLab workflows under the same policy.
Open weight modelsGAGet comparable performance on lower-cost workloads with GitLab-hosted GLM 5.3, Kimi K3, and MiniMax 3 models.
GitLab OrbitGA next monthGive your agents the right knowledge requiring 45x fewer retries with a context graph of your software lifecycle.
Duo Agent Platform Impact AnalyticsEarly accessMeasure the cost and impact of your AI investment, by team, task, and model.
Credit and usage controlsGASet caps at the subscription, group, and user level and get alerts on AI spend.
GitLab Artifact CentralBetaGive every package and container one governed home, next to source and CI.
GitLab Dependency FirewallEarly accessSet rules that block, quarantine, or warn on risky packages before they reach your build.
GitLab Secrets ManagerGA this monthScope build-time secrets to the job and revoke them with one click.
GitLab Security StandardAvailable todayHarden your software factory in five stages and let your agents earn autonomy.
New flows with Claude Mythos 5 and 5.1GA next monthFind and remediate vulnerabilities on GitLab Duo Agent Platform with new security flows.
Agent orchestration across the software lifecycle
Today, each step in your agentic workflow still waits for a person to approve it before the next one starts.
Goal-driven flows take a stated objective and run it end to end, through review, tests, security scans, and approvals from the Duo CLI, headless mode, or Agentic Chat. Custom Flows let you chain agents together to match the process your team already follows. GitLab for Slack starts a flow from the channel where the conversation is already happening. The MCP Server enables external AI applications and coding agents to securely access your GitLab instance under the same policy your own agents follow.
GitLab-hosted open-weight models, including GLM 5.3, Kimi K3, and MiniMax 3, give you a lower-cost option when a workload doesn't need a frontier model. At similar task-completion rates, some open weight pairings deliver up to 8x more model calls per GitLab Credit than their frontier counterparts.
Data and context to power human and agent reasoning
Every agent task starts by re-deriving the same context, which drives up retries and token use. And without coherent visibility into AI costs and ROI, there's no way to tell whether your investment is paying off.
GitLab Orbit, the context graph of your entire software lifecycle increases agent accuracy with up to 45x fewer retries, effectively reducing cost for agentic workflows with up to 4.5x fewer token use. During its beta period, Orbit has been used by more than 3,500 organizations, running over 280,000 queries.
Duo Agent Platform Impact Analytics shows the cost and impact of your AI investment by team, task, and model. Credit and usage controls let you set caps at the subscription, group, or user level, with alerts at 50%, 80%, and 100% of spend, and an automatic pause once you hit the cap you set.
DevOps infrastructure at agent scale
Most of what ships isn't code your team wrote, it's assembled from open source packages, base images, and libraries pulled in from everywhere. When every team runs its own registry, there's no single place to confirm what you actually published or shipped.
Back in June, during Transcend London, we introduced our next-gen source code management solution helping you achieve machine scale with your coding agents. The next machine-scale problem goes to the step after code, when you’re creating a build.
GitLab Artifact Central replaces a separate registry per team with one place to publish and pull from, built next to your source code and CI pipelines. It publishes and pulls Maven, npm, and Docker, and OCI packages directly from CI pipelines, with PyPI and NuGet coming at GA. Artifact Central uses the same identity and permissions as your source code, with virtual repos, native CI/CD authentication, and full build provenance. Early results show roughly 50% lower total cost of ownership compared to alternative tooling.
Governance and security with centralized enforcement
Agents pull in package components to your build at machine speed, making it impossible to manually secure what you ship. When that gap exists, you risk shipping security vulnerabilities into production rather than catching them before they impact customers, and you have to answer for it.
GitLab Dependency Firewall, now in early access, sets rules on package age, vulnerability severity, malicious package detection, and license compliance, with actions to block, quarantine, or warn, enforced on the registries you already use. It works directly with GitLab Artifact Central, and is compatible with JFrog Artifactory and Sonatype Nexus Repository.
With a greater number of builds, another risk emerges: agents inheriting build-time secrets from local dev environments that nobody secured, and using them across CI pipelines. GitLab Secrets Manager gives each build-time secret one home, scoped to the job that needs it, with one-click revocation for a leaked credential and up to 50% savings compared to hosting a separate vault.
The same AI models that let agents write and ship code at machine speed also make existing weaknesses faster and cheaper to discover, connect, and exploit. The GitLab Security Standard lays out five stages for assessing and hardening your agentic software development: authorizing every actor's access, isolating workspaces and their inputs, verifying the checks that judge the work, releasing exactly what was verified, and responding fast when something looks wrong, all built on a foundation of policy, audit, and ownership. Read the full standard for the complete breakdown.
Coming soon, Anthropic’s Claude Mythos 5 and 5.1 will power new GitLab Duo Agent Platform security flows, helping organizations with approved environments find and fix vulnerabilities faster than attackers can discover and exploit them.
How to buy with GitLab Flex
Agentic software engineering makes headcount, credit burn, and new capabilities hard to predict six months out. GitLab Flex is one annual commitment that covers new GitLab capabilities as they ship, without re-procurement. It lets teams reshape seat and AI spend via GitLab Credits on a monthly basis as their needs change.
Where to start
Turn on GitLab Duo Agent Platform: Existing customers start today with credits already in their subscription, and every new GitLab trial includes 30-day access. To increase the efficiency of your agents, turn on GitLab Orbit beta for GitLab.com.
Adopt the GitLab Security Standard: GitLab Ultimate is available as a free trial. A Secrets Manager trial is available to Ultimate and Premium customers. GitLab Artifact Central is open in beta, and you can request early access to Dependency Firewall.
Get more from every dollar with GitLab Flex: One annual commitment for new GitLab innovations without re-procurement - with the ability to reshape your spend for seats and GitLab Credits month to month.
If you're migrating from GitHub, do it on your own terms with dedicated migration tools, custom migration services, and an exclusive offer to get one year of GitLab free when signing up for a three-year contract.
And if you're ready to start building, join "Life after code: the path to production at the speed of imagination," our three-week hackathon in partnership with Anthropic and Google Cloud.
Wherever you start, you're choosing the same destination: the foundation for a governed software factory where agents accelerate the work and every change stays trusted.
We can’t wait to see what you build next.
Oct 6 · 00:00·GitLab