
Step 1: Connect your stack
27+ native integrations plus 9,800+ tools via managed connectors. Mostly one-click OAuth, a few API keys. No webhooks, no Zapier zaps.
Viktor works in GitLab for you. Ask in Slack or Microsoft Teams.
Viktor is an AI employee that connects to GitLab and helps you build, test, and deploy code through CI/CD pipelines, running 28 GitLab actions for you like Get Issue, Create Epic, and List Groups. Ask in plain English from your workspace; Viktor does the work in GitLab and reports back. Viktor connects in one click via OAuth.
Viktor connects to your GitLab account and completes work in it. He doesn't just answer questions about GitLab, he takes the actions on your behalf and delivers the finished result to your workspace.
Unlike workflow builders such as Zapier or Make, there is nothing to configure - no triggers to map, no workflows to maintain. You describe the outcome in plain English, and Viktor picks the right GitLab actions, chains them with the other 9,800+ tools he connects to, and asks for approval before anything sensitive runs.
About GitLab
GitLab is the most comprehensive AI-powered DevSecOps Platform.
Message Viktor in a Slack channel, a Microsoft Teams chat or a direct message. He opens GitLab, does the work and posts the result in the same thread, so nobody has to switch tabs.
He can also run GitLab work on a schedule, like a weekly GitLab summary posted to your team's channel. Anything sensitive waits for your approval before it runs.
Viktor is not affiliated with or endorsed by GitLab.
You ask in your workspace
Describe what you need in plain English
Viktor picks the actions
Selects from 28 GitLab actions, chains them together
Runs in GitLab
Helps you build, test, and deploy code through CI/CD pipelines - your real data.
Reports back
Delivers the finished result to your workspace
Messages you'd actually send. Paste one into your workspace, swap in your specifics, and Viktor takes it from there.
“Check GitLab for the latest failed build and summarize the likely cause.”
— you, to @Viktor
“Trigger a deploy in GitLab for the latest release and report when it's done.”
— you, to @Viktor
“Watch GitLab for failed pipelines and post a summary here with the likely cause.”
— you, to @Viktor
“Summarize what shipped through GitLab this week for the changelog.”
— you, to @Viktor

27+ native integrations plus 9,800+ tools via managed connectors. Mostly one-click OAuth, a few API keys. No webhooks, no Zapier zaps.
Message Viktor like a teammate: "Pull this week's MRR from Stripe." "Triage new Linear bugs." "Pause Meta ads over $40 CPA." Any tool.
Viktor opens the tools, runs the work, and posts back exactly what changed. Sensitive actions wait for your approval. It’s all logged.
Ask in plain English from your workspace. Viktor picks the right GitLab actions, runs the work, and reports back. No workflows to build.
Approve a merge request as the authenticated user, or withdraw an earlier approval by setting Action to unapprove. Call Get Merge Request first to check the merge request is actually ready — its readiness rollup reports the pipeline status, conflicts and how many approvals are still required — and Get Merge Request Diffs to read the changes being approved. Two things commonly go wrong: GitLab refuses to let you approve your own merge request, and a project may require approval from a specific approval rule that the authenticated user does not satisfy; both surface as a 401. To approve as part of leaving review feedback in one step, use Create Merge Request Review with its Action set to approve instead. Optionally pass SHA to make the approval conditional on the merge request's head commit, so it fails rather than silently approving work that was pushed after you read the diff.
Create a new branch in the repository.
Creates a new epic.
Creates a new issue.
Post a comment on a merge request. It works in three modes, chosen by which props you set: leave File Path and Discussion ID blank for a plain comment on the merge request as a whole; set File Path plus a line number to open an inline thread anchored to that line of the diff; or set Discussion ID to reply inside an existing thread. Use Get Merge Request Diffs first to get valid file paths and line numbers, and List Merge Request Discussions to get a Discussion ID to reply to. Line numbers follow GitLab's diff rules: for a line the merge request adds or leaves unchanged, pass New Line; for a line it removes, pass Old Line; for an unchanged context line, pass both. Getting that wrong is the usual cause of a rejected inline comment. To post several review comments at once, and optionally approve in the same step, use Create Merge Request Review instead.
Submit a whole review on a merge request in one step: any number of inline comments anchored to lines of the diff, an overall summary comment, and optionally an approval. This is the tool for \"review this MR\" — call Get Merge Request and Get Merge Request Diffs first to read the changes, then send the findings back here. GitLab has no single submit-review API, so this action posts each inline comment as its own thread and then approves if asked; if an individual comment is rejected (usually a line that is not part of the diff) the rest are still posted and the failures are returned in failed, so check that array rather than assuming everything landed. Line numbers follow GitLab's diff rules: newline for a line the merge request adds, oldline for a line it removes, both for an unchanged context line. There is no REST equivalent of GitLab's Request changes state — to block a merge request, leave the findings as comments and do not approve.
Open a new merge request from one branch into another. Use this for \"open an MR\", \"raise a merge request\", \"submit my branch for review\". Both branches must already exist in the project — use List Repo Branches to check, or Create Branch to make one. Reviewers and assignees are given as usernames and resolved to IDs automatically; a username that is not a member of the project is rejected rather than silently dropped. Set Draft to true for work that is not ready for review — GitLab expresses this by prefixing the title with Draft:, which this action does for you and which blocks merging until removed. After creating, use Get Merge Request to check its pipeline and merge readiness.
Gets a single issue from repository.
List the commits contained in a merge request, newest first. Use this to understand how a change was built up — whether it is one clean commit or a long history to squash, who wrote each part, and what the commit messages claim. For the actual code changes call Get Merge Request Diffs instead; for merge readiness call Get Merge Request.
Ask for outcomes that span tools - Viktor pulls from GitLab, cross-references the rest of your stack, and delivers one finished result.
Yes. GitLab is one of the 9,800+ tools Viktor connects to, in one click via OAuth. Once connected, anyone on your team can put Viktor to work in GitLab from their workspace - no workflow builder, no code.
Ask Viktor in your workspace to connect GitLab, then approve the one-click OAuth prompt. Viktor never sees your password, handles authentication itself, and starts working right away. Setup takes about two minutes, and you can revoke access at any time.
Viktor can run 28 GitLab actions, including Get Issue, Create Epic, and List Groups - and chain them with other tools in a single request. In practice that means Viktor helps you build, test, and deploy code through CI/CD pipelines. If a task spans several actions, Viktor plans the sequence itself and reports back when the work is done.
No. Viktor isn't a workflow builder - there are no triggers to map and nothing to maintain. You ask for the outcome in plain English in your workspace, and Viktor decides which GitLab actions to take, runs them, and reports back.
Start free. Viktor delivers.
Start for free today. No credit card required.