Genesys Cloud CI/CD with GitLab.
Trigger InProd changeset validation and deployment from GitLab merge requests — with protected environment gates, Simulate Run before every environment, and deployment evidence at every stage of your Genesys Cloud GitLab CI pipeline.

Step-by-step implementation guide
How to build a Genesys Cloud CI/CD pipeline with GitLab CI and InProd — including MR validation, protected environment setup, and rollback strategy.
How It Works
Three steps from a reviewed change to a recorded production deployment.
Define changes as an InProd changeset
Package your Genesys Cloud configuration changes — routing flows, queue definitions, skill mappings, data actions — into governed deployment units managed in InProd and triggered from your GitLab repository.
Validate and Simulate Run from your GitLab merge request
Automatically trigger a validate-only job on every merge request. InProd runs Simulate Run against the target environment and reports exactly what would change — before anything is merged.
Promote through Dev, UAT, and Production with approval gates
Use GitLab's native pipeline orchestration to move the same changeset through environments, with manual approval gates protecting production and InProd handling environment-aware variable mapping at each stage.
What You Get
Merge request-triggered validation
Every configuration change is automatically verified against the live target environment as part of your peer-review process — not after it reaches production.
Protected environment promotion
Use GitLab's protected environments to ensure only authorized users can trigger production deployments. InProd respects the same access boundaries.
Simulate Run before each environment
InProd executes a pre-deployment simulation showing exactly what will be created, updated, or deleted — including environment-specific differences invisible to a standard diff.
GitLab CI artifact for deployment evidence
Execution results and status files are captured after every run, providing an immutable deployment record for compliance and incident review.
Rollback from pipeline or InProd UI
Revert to a previous state using InProd's point-in-time restore — without manual reconstruction of what the configuration was before the change.
Works With Your Existing GitLab Setup
No custom runners required. InProd integrates directly with GitLab CI using a published template. Your existing protected environments, merge request approval rules, and branch protection settings all apply — InProd adds Genesys Cloud-specific validation and deployment governance on top of the pipeline you already run.
This makes it straightforward to add CX as Code deployments to a GitLab workflow your team already understands.
New to the InProd pipeline model? See how the five-stage Genesys Cloud CI/CD pipeline works →
GitLab CI vs GitHub Actions vs Bitbucket Pipelines
InProd runs the same governed Genesys Cloud deployment workflow on every platform. The right choice depends on where your team already works.
GitLab CI
You are hereBest fit for teams running GitLab as their single platform for source control and CI/CD — whether on GitLab.com or self-hosted. Merge request approvals, protected environments, and the published pipeline template all live in the same tool your team uses for code review.
- MR-triggered validation is native to the platform
- Published pipeline template — no custom runner configuration
- Works with self-hosted GitLab and GitLab.com
GitHub Actions
Best fit when changeset files live in the same GitHub repository as application code. Pull request reviews, protected environment approvals, and GitHub Secrets are already in place — the InProd action is published on the GitHub Marketplace.
- PR-triggered validation native to GitHub
- Protected environments enforce approval before production
- Marketplace action — no custom infrastructure
Bitbucket Pipelines
Best fit for teams in the Atlassian ecosystem — Jira for issue tracking, Confluence for documentation, Bitbucket for code review. Deployment environment gates and manual trigger steps work with existing repository variable configuration.
- Native Jira and Confluence integration
- Deployment environment gates with manual trigger steps
- Artifacts captured directly from the Bitbucket UI
Frequently Asked Questions
Why use GitLab CI for Genesys Cloud deployments instead of manual promotion?
Manual promotion relies on engineers replicating the same steps correctly across Dev, UAT, and Production every time. GitLab CI enforces the same process on every release — validation runs automatically, approvals are required before production, and every deployment generates a record. The pipeline removes the process variability that causes most configuration-related incidents.
Does InProd work with GitLab protected environments and approval rules?
Yes. InProd deploys through your existing GitLab pipeline, so GitLab's protected environment rules, required approvals, and branch protections all apply as normal. InProd adds Genesys Cloud-specific governance — Simulate Run, environment-aware variable handling, and deployment records — on top of whatever access controls your GitLab project already enforces.
What is the difference between using GitLab CI and GitHub Actions for Genesys Cloud?
Both platforms can run InProd changesets through the same Dev → UAT → Production promotion flow. GitLab CI is often preferred by enterprise teams that self-host their Git infrastructure or require native merge request approvals within a single platform. GitHub Actions is the right choice for teams already standardized on GitHub. The InProd deployment behaviour is identical across both.
Does this work with CX as Code and Terraform?
Yes. InProd sits alongside your CX as Code and Genesys Cloud Terraform workflows. Terraform manages desired-state definitions; InProd governs the deployment lifecycle — Simulate Run, promotion gates, drift detection, and the audit trail. The GitLab pipeline can trigger both Terraform applies and InProd changeset deployments within the same stages.
Need the full pipeline picture? Genesys Cloud CI/CD Pipeline →
A Genesys Cloud GitLab CI Pipeline That Actually Governs the Deployment.
Every configuration change validated before it merges, approved before it reaches production, and recorded after it deploys.
Book a Consultation







