When does GitLab customization need outside help?
Most teams that run a self-managed GitLab instance handle small configuration changes in-house: application settings, a few group and subgroup structures, and a basic CI/CD include. Customization needs outside help when the work spans several components at once, such as shared CI/CD components consumed across many projects, custom runners with specific images and network access, system hooks and webhooks that feed other tools, and integrations with Jira, chat or artifact stores. Each of these is supported in principle by GitLab, but the design choices they force, and the people who must own them afterward, are where partners are usually brought in.
The main risk is not the first build. It is what breaks at the next upgrade. GitLab ships a new minor release each month and requires upgrades to pass through upgrade stops, so a customization built against today's API, template behavior or Runner version has to be retested on every step of the path. Custom code that calls undocumented endpoints, scripts that parse log output, or hooks that depend on a field name removed in a later release will fail quietly or loudly at the worst moment. Ask who will rerun those tests, against which target version, and where the test results are kept.
Start by listing every customization and tagging it with the GitLab feature it depends on, the API or configuration path it uses, and the Runner version it requires. Customizations that touch only documented settings and the public API carry less upgrade risk than those that patch application code or rely on internal behavior. The fact that GitLab's source is open core, with content under the ee/ directory licensed under the GitLab Enterprise Edition license and the rest under the MIT Expat license, means edition matters: features you plan to customize may sit in a tier you do not run, so confirm the edition before designing the work.
Connectivity changes the scope as well. An internet-connected instance can pull packages, images and some scanner data directly, while an air-gapped instance needs offline transfers for every update, container image and Runner dependency. GitLab documents separate guidance for running its security scanners and GitLab Duo Self-Hosted offline, and a customization that assumes a live external call will not work there. Confirm with your own security team which connections are permitted before writing a single hook or integration.
Before you decide, ask a partner or your own team for a written inventory, a test plan that covers each upgrade stop, a rollback path for each customization, and a named owner for every integration after handover. A fixed-scope agreement makes these items visible before work starts, which is easier to evaluate than an open-ended retainer that has not defined what is covered.
What GitLab customization includes and what you receive
Customization work touches settings, pipelines, runners, automation and external tools, and each package changes how your teams work day to day. Every package below lists the artifact you keep, so your own engineers can maintain it after handover. Scope is agreed in writing before work starts, and the out-of-scope items show where a separate decision is needed.
Instance and group settings
We document and apply instance-wide and group-level configuration, including default branch rules, merge request approval settings, sign-up and visibility controls, and group naming conventions. Settings are captured as a versioned configuration record with a change log, so an administrator can see why each value was chosen. Check that the settings match your written engineering policy and that the record is stored in your own repository. Out of scope: redesigning your organizational structure or your role model.
CI/CD templates and components
We build shared pipeline templates and reusable CI/CD components for the build, test and deploy stages your teams repeat. Each component is published from a versioned repository with pinned release tags, input parameters and a short usage guide. Check which projects consume each version and who approves changes to shared templates. Out of scope: building a new CI platform or rewriting every existing pipeline in your estate.
Custom runner images and executor configuration
We design runner images and executor settings for your build workloads, covering base image contents, tool versions, cache paths and resource limits for shell, Docker or autoscaling executors. The deliverables are image build definitions, an executor configuration file and a runbook for rebuilding and rotating images. Check that Runner versions stay aligned with your GitLab version and that image updates have a named owner. Out of scope: sizing or buying the underlying compute capacity.
Webhooks and API automation
We implement project and group webhooks and API scripts that trigger actions such as provisioning projects, syncing labels or notifying downstream systems. Each receiver is delivered with a documented endpoint contract, payload examples, retry behavior and a token rotation procedure. Check how each receiver authenticates requests and where its logs are stored. Out of scope: building general-purpose internal developer portals or custom user interfaces on top of the API.
System hooks
We configure instance-level system hooks for events your platform team needs to act on, such as user changes, project creation or group membership updates. The deliverable is a hook registry listing each event, its receiver, its owner and the failure response. Check that system hook receivers are hardened as privileged endpoints and that their failures raise an alert rather than failing silently. Out of scope: replacing your identity provider or moving account lifecycle management out of its current system.
Integrations with Jira, chat and artifact stores
We connect GitLab to your Jira projects, chat channels and artifact stores so issue links, pipeline notices and build outputs reach the tools your teams already use. Deliverables include integration configuration, a credential inventory and a runbook for reconnecting after a token change. Check which service accounts hold these credentials and whether artifact retention matches your storage policy. Out of scope: replacing Jira or your chat platform, or changing their own administration.
What drives GitLab customization cost and duration
This table lists the factors that change how much work GitLab customization takes and how long it runs, with the reason each one matters and the practical step that keeps it contained. Read it before requesting a quote, because each row maps to a question the implementation partner will ask about your environment. The main takeaway is that scope size, edition, deployment layout and the number of environments usually move effort more than any single feature request.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| User count and groups and projects | More users, groups and projects mean more permission models, more group settings to standardize and more project-level variables and webhooks to review and migrate. | Standardize settings at the top-level group and use inheritance, and limit customization to a documented set of shared templates. |
| Number of distinct pipelines and templates | Each pipeline type with its own stages, rules and images needs design, testing and ongoing maintenance. Shared CI/CD components or templates multiply the testing matrix across every consuming project. | Consolidate pipelines into a small number of reusable CI/CD components or includes, and retire pipelines that no team still uses. |
| Number of external systems to integrate | Each integration, such as Jira, chat, artifact stores or identity providers, adds authentication, data mapping, error handling and monitoring. Webhook and API automation that depends on these systems is often the slowest part to validate. | Agree the list of integrations and their data flows in writing before build, and phase lower-priority integrations after the core workflow is stable. |
| Edition (Free, Premium or Ultimate) | Features available in the chosen tier decide what can be configured natively and what must be built as custom automation. Premium and Ultimate add capabilities such as advanced CI/CD and compliance features, so the same requirement can take a different build path in each tier. | Map each requirement to the tier that provides it before scoping, and confirm current tier features with GitLab's pricing page and your license holder. |
| Deployment layout (Linux package, Helm chart or Operator) | The Linux package bundles PostgreSQL, Redis and Sidekiq, while Helm chart and Operator layouts add Kubernetes manifests, persistent volume handling and external stateful services. Customization such as custom images, runner placement and configuration management differs in each layout. | Choose the layout early based on your existing platform skills, and keep custom configuration in version-controlled files that match the chosen layout. |
| Network isolation (air-gapped or restricted egress) | Isolated networks require offline package and image transfer, internal mirrors for runners and images, and changes to any integration that expects internet access. Each external dependency needs an internal replacement or an approved transfer path. | List every outbound dependency during scoping, such as package sources, runner images and integrations, and agree on an internal alternative for each. |
| Number of environments kept in step | Development, staging and production instances must receive the same settings, templates, runners and integration configuration. Each additional environment adds configuration drift risk, testing time and upgrade rehearsal work. | Keep instance and group configuration in code, promote changes through the same path in every environment, and limit the number of non-production instances to what testing requires. |
| Runner and image customization | Custom runners and container images need build, hardening, version alignment with GitLab and capacity testing. Each runner type or image variant adds ongoing maintenance. | Limit the number of runner types and base images, and align runner versions with the GitLab release in use. |
How a GitLab customization project runs from scoping to handover
The sequence moves a customization from a documented understanding of current workflows to a tested, staged change that your own team can run and upgrade after the engagement ends. Each phase closes with a written output, so you can check progress before the next one starts.
Discover current workflows and existing customizations
DeployOpen reviews how your teams use the instance today: group and project settings, CI/CD templates and components, runners, webhooks, system hooks, API scripts and integrations with Jira, chat and artifact stores. Your platform and engineering leads describe the pain points and the outcomes they need. Existing customizations are inventoried with their owners, their dependencies and the upgrades they might break. The phase is done when you have a discovery document that lists each workflow, each customization and the gaps between them.
Agree a written scope with acceptance criteria
The discovery findings become a fixed-scope proposal that names the deliverables, the excluded items, the GitLab version and deployment method in use, and the acceptance criteria for each deliverable. Acceptance criteria describe observable results, such as a pipeline template that passes a defined test job or a webhook that delivers a defined payload to a named receiver. Ask for a phase-by-phase schedule in the written scope so each milestone and its dependencies are visible before signature. The phase is done when both parties have signed the scope.
Build the change in a non-production instance
The customization is built on a non-production GitLab instance that matches production's version, edition and installation method as closely as your environment allows. Settings are applied through the admin interface or configuration where possible, and anything that cannot be expressed as configuration is written as versioned code kept in source control. Every change is recorded with its purpose and the acceptance criterion it serves. The phase is done when every deliverable in the scope has passed its own checks in the non-production instance.
Test against the next GitLab release where possible
Where the release schedule allows, the build is also tested against the next GitLab release in a separate environment before you upgrade production. This shows which settings, API calls, hooks and CI/CD features change behavior, and it gives you time to adjust before a required upgrade stop. Confirm with your own team which releases are in scope for testing, because the upgrade path depends on your current version. The phase is done when test results and any required adjustments are recorded against the acceptance criteria.
Roll out in stages to production
Production rollout proceeds in stages, usually starting with a small group of projects or a single team, then widening once the change is confirmed to behave as the tests predicted. Rollback steps are written and rehearsed before each stage, and a current backup is confirmed before any change touches production data or configuration. Your team observes the instance during each stage and signs off the acceptance criteria for that group. The phase is done when all in-scope groups run the customization and the acceptance criteria are signed off.
Hand over runbooks and an upgrade checklist
DeployOpen delivers runbooks that explain how each customization works, how to change it, how to troubleshoot it and how to roll it back. An upgrade checklist records which settings, hooks, scripts and integrations must be retested at each GitLab upgrade, including the required upgrade stops your version will pass through. A walkthrough with your administrators confirms they can operate the change without DeployOpen. The phase is done when your team has accepted the runbooks and checklist in writing and the handover session is complete.
Keeping customizations working through GitLab upgrades
Customization design decisions decide how much work each GitLab upgrade will cost you. GitLab ships a major release yearly, a minor release on the third Thursday of each month, and patch releases twice a month. Under the maintenance policy, GitLab currently maintains the three most recent minor lines, and it requires upgrades to pass through required upgrade stops. Since GitLab 17.5 those stops fall at x.2, x.5, x.8 and x.11, so a jump from one stop to the next is a planned step, not an optional one. Any customization that only works on the version you run today will break at the first stop it does not survive.
The maintenance policy also changes how you should test. Bug fixes are backported only to the current stable release, while security fixes are backported to the previous two monthly releases as well. That means a bug you hit on an older instance may never be fixed on that line, and a security fix may arrive on a version you are about to leave. Test each customization against the full upgrade path you intend to take, including the required stops, rather than against the version in production alone. Confirm the exact stops and upgrade order in the GitLab upgrade paths documentation before you schedule a window.
Prefer the extension points GitLab documents over changes to the installed application. Use the public REST and GraphQL APIs, webhooks, CI/CD components and versioned CI/CD templates, and keep pipeline logic in project or group-owned files that you version and review. Avoid patching files under the application directory, editing bundled Omnibus or Helm defaults in place, or forking templates that GitLab maintains. Each patch to the installed application is a merge conflict waiting for the next upgrade, and it is usually invisible to the team that made it. When you do need a change that GitLab does not expose, record it, justify it, and make it a named item in the upgrade plan.
The tooling around the instance needs its own upgrade test. Scripts that call the API, backup and restore jobs, chat notifications, Jira link checks, artifact store clients, and custom runners or runner images all depend on API responses, job environment variables and runner versions that can change between releases. Keep runner major and minor versions aligned with GitLab, as the GitLab Runner documentation advises, and pin the API version and CI/CD component versions your automation uses. Maintain a short staging test that runs the automation against a restored copy of production at the target version, and treat a failed test as a blocker for the production upgrade.
Which GitLab customization work teams keep in-house and which they outsource
This table compares six areas of GitLab customization by typical owner and the skills each one needs. Rows marked as partner-led are commonly taken on in a fixed-scope project, while rows marked as internal are the ones a named owner should hold after handover. Use it to decide where to draw the line between your team and an implementation partner before you request a quote.
| Work area | Typical owner | Skills needed |
|---|---|---|
| Platform administration (instance settings, gitlab.rb, backups) | Partner for the initial build, then internal owner | Linux administration, GitLab configuration, backup and restore testing, change control for settings that affect all projects |
| Pipeline engineering (CI/CD templates and components) | Partner for the first templates, internal team for ongoing changes | CI/CD YAML, shared template design, versioning of components, knowledge of how engineering teams build and test |
| Runner and image work | Partner for runner setup, internal owner for images and capacity | Runner executor configuration, container image build, capacity planning, keeping Runner versions aligned with GitLab |
| API and webhook development | Partner for scoped automations, internal owner for maintenance | GitLab REST and GraphQL APIs, token and permission design, webhook receivers, error handling and logging |
| Third-party integration (Jira, chat, artifact stores) | Partner for the integration build, internal owner for credentials and changes | Integration configuration, service account management, network routing to external systems, secrets handling |
| Ongoing maintenance (upgrades, patches, template and integration updates) | Internal owner, with optional partner retainer | Upgrade planning across required upgrade stops, regression testing of pipelines, dependency and credential rotation, release notes review |
What goes wrong in GitLab customization projects and how to prevent it
Most GitLab customization problems are not caused by the feature being built but by how it is built, documented and kept running. The cards below cover the failure points we see most often in self-managed instances, each with the check or design step that prevents it.
Dependence on undocumented internals
Customizations that read database tables, edit application files or call private endpoints often work on one release and break at the next upgrade, which is when GitLab's required upgrade stops and background migrations change the underlying structures. Before building, list every interface the customization touches and confirm it is part of the documented API or a documented configuration option. Keep a short compatibility note per customization and re-test it against each upgrade stop in a staging instance before production.
Custom runner images out of step
A custom runner image or runner binary that falls behind the GitLab version can produce job failures that look like pipeline bugs. GitLab's documentation advises keeping Runner major and minor versions aligned with GitLab, so a runner built months earlier may be the cause of a failure. Pin the runner version in your build definition, tie image rebuilds to GitLab upgrade dates, and confirm the alignment as a step in every upgrade runbook.
Webhook receivers without retry or authentication
Webhook receivers that accept GitLab events without verifying the secret token, or that drop a request when the downstream system is briefly unavailable, leave gaps in Jira, chat or artifact integrations. An unauthenticated receiver can also be used to trigger internal actions by anyone who can reach its URL. Design each receiver to validate the shared secret, return success only after the event is durably queued, and retry failed deliveries. Test with a deliberately stopped downstream service before go-live.
Secrets in unscoped pipeline variables
Access tokens and deployment credentials stored as broadly visible CI/CD variables are readable by any pipeline that can run in the project or group, and they often outlive the person who created them. Scope each secret to the protected branches and environments that need it, mark sensitive values as masked and protected, and prefer short-lived credentials where your cloud or vault supports them. Ask the team to list every variable with its owner, scope and rotation date, and review that list on a fixed schedule.
Scripts only one engineer understands
Pipeline templates, migration scripts and API automation written by a single engineer tend to stop working when that person is unavailable, and nobody can safely change them during an incident. Require a second engineer to review each script before merge, store the scripts in a versioned repository with a README covering inputs, outputs and failure modes, and run a short handover exercise where another team member makes a small change. Treat undocumented scripts as unfinished work.
Hardening guidance treated as complete
GitLab's hardening documentation covers application settings, CI/CD, gitlab.rb, the operating system and NIST SP 800-53 oriented configuration, and GitLab describes this guidance as a work in progress to be rolled out gradually. Teams that apply the full list at once, or that assume a checklist is final, often break integrations or pipelines and then roll back the controls. Map each recommendation to an owner and a test, apply changes in stages on staging, and record which settings were deliberately not adopted and why.
How GitLab customization changes by deployment and starting point
On a Linux package installation, most instance-level customization is expressed in the gitlab.rb configuration file and the files it references. The work is less about where settings live and more about keeping them reproducible. A change made by hand on one server is a change nobody can review, reapply or explain during an incident, so the configuration should sit in version control with a documented reconfigure step. Customization that touches the operating system, such as file permissions, certificates or service ordering, needs the same treatment because it is part of the instance even though it is not inside GitLab.
What changes in the work:
- Configuration in code: gitlab.rb, certificate paths, SMTP and object storage settings are reviewed through merge requests in your own repository, not edited directly on the host.
- Reconfigure as a controlled step: each change is tested on a non-production instance first and applied with a recorded reconfigure.
- Operating system drift: packages, kernel settings and hardening baselines are tracked alongside GitLab settings so upgrades do not silently change them.
- Upgrade review: configuration keys can be renamed or deprecated between releases, so the repository is checked against each required upgrade stop.
- Secrets handled separately: the configuration and secrets files are backed up and access-controlled in their own right.
Before committing to this approach, confirm with your team which settings are managed through the repository and which are changed through the admin interface, and document that boundary so it does not drift.
On Kubernetes, customization moves into values files and manifests. The Helm chart or GitLab Operator becomes the single place where instance behavior is declared, so changes to resources, ingress, storage classes or component replicas should be made there and not by patching live objects. This keeps the cluster state reproducible, but it also means every customization must be expressible in the chart's supported parameters or in manifests you own. Anything the chart does not expose will need a documented workaround that survives chart upgrades.
What changes in the work:
- Values as the source of truth: overrides for images, resource requests, ingress and Helm release settings are stored and reviewed like application code.
- Stateful services outside the cluster: PostgreSQL, Redis and Gitaly are not run inside Kubernetes under the reference architectures, so their connection, backup and sizing decisions are made on VMs or managed services.
- Cloud Native Hybrid layout: stateless components run on the cluster while stateful services sit elsewhere, which shapes network policy, secrets and failover design.
- Chart version pinning: chart and application versions are upgraded together, and upgrade stops still apply to the GitLab version.
- Custom images and runners: any image you build for CI jobs or runners is versioned and scanned on your own registry.
Before you begin, confirm with the chart documentation and your platform team which parameters you will override and which external services you will operate, because those choices determine most of the ongoing effort.
An air-gapped instance cannot pull templates, container images, packages or vendor-hosted services at runtime, so customization depends on what you mirror and when. Anything that would normally be fetched from the internet, including CI/CD templates, component catalogs, runner images, scanner data and integration endpoints, must be available inside the isolated network before it is needed. Customization work therefore starts with an inventory of external dependencies and ends with a transfer and update process you can repeat for every release.
What changes in the work:
- Mirrored templates and components: CI/CD templates and components referenced by pipelines must resolve to internal copies that are updated deliberately.
- Image and package transfer: container images for jobs, runners and any offline features are moved through an approved transfer path and verified before import.
- Offline scanner guidance: GitLab's guidance for running security scanners offline applies, so scanner data and rulesets must be refreshed through your own process.
- Integration endpoints: webhooks, chat and Jira connections, and artifact stores must point at reachable internal services, and any outbound assumptions in your automation must be removed.
- Patch and upgrade bundles: each minor release, patch and required upgrade stop is planned with its offline package set, not downloaded on the day.
Before committing, confirm with GitLab's offline documentation which features your tier supports in an offline setting and which scanner or AI features need separate offline setup, since these vary and should not be assumed.
When you migrate from GitHub, Bitbucket, Jenkins or another GitLab instance, customization starts before the instance is configured. The first deliverable is an inventory of what the existing system does: groups and permissions, pipeline logic, scripts that call the API, webhooks, integrations with issue trackers and chat, and the places where people rely on behavior that no one documented. Without that inventory, customizations are either rebuilt by guesswork or lost, and both surface later as broken releases or unexpected access.
What changes in the work:
- Customization inventory first: list webhooks, scheduled jobs, pipeline templates, runner tags, custom scripts and integrations, with an owner for each.
- Mapping, not copying: decide which items become instance settings, group settings, CI/CD components or retired processes, rather than moving every script unchanged.
- Import scope: confirm which content types the importer supports from the source system and which need external conversion, such as Subversion history.
- Parallel running: keep the old system's automation available during the transition so each replacement can be checked.
- Identity and permissions: user mapping and group roles are reviewed alongside integrations, because an imported webhook or token can carry access the new owners did not intend.
Before cutover, confirm with the importer documentation for your source system which objects will move and which must be recreated, and agree the inventory sign-off with the teams that own each integration.
What you need to provide before GitLab customization starts
Customization work moves quickly only when the client has settled a short list of inputs before the quote is finalized. The first is administrator access to a non-production GitLab instance that matches the production edition and configuration as closely as possible, with a current backup of that instance. Changes to instance settings, group defaults, CI/CD templates and hooks should be tested against this copy, and the backup gives the team a way back if a setting breaks logins or pipelines. Confirm who holds the administrator role, how credentials are issued, and whether the team can reach the instance from its own network.
Next, name an owner for every group whose workflow will change and for every pipeline standard that will be shared across projects. A group owner decides which merge request approval rules, protected branch settings and project defaults apply to their teams. A pipeline standard owner signs off on the shared CI/CD component or template that other projects will include. Without these named people, every design question waits for a meeting, and the team tends to reopen decisions after build work has started. Ask for names, backup contacts and the decision rights each person holds.
Provide a written list of the integrations the customization must touch, such as Jira, chat tools and artifact stores, together with the API access each one needs. For each integration, state the service account to be used, the scopes or permissions it requires, and your credentials policy, including who may create tokens, how long they live and where secrets are stored. Also provide an inventory of existing scripts, webhooks and system hooks that run against the current GitLab, and the GitLab edition in use. Feature availability differs between Free, Premium and Ultimate, so the edition determines which settings and CI/CD features can be designed in at all.
Decide where GitLab Runners will run before design starts, because runner location affects network access, image storage, secrets handling and the executor type that can be used. Runners may sit on existing virtual machines, in a container platform or in an autoscaling pool on cloud or hypervisor capacity. Record which networks they must reach, whether they will run in an offline environment, and who operates them. Finally, name a sign-off authority who can accept deliverables against written acceptance criteria. Missing owners and unclear acceptance criteria are the most common causes of scope change in this kind of work, because decisions get deferred and then reopened. Agree on what "done" means for each deliverable and who confirms it before the quote is finalized.
How much does GitLab customization cost and how long does it take?
What actually drives the cost of GitLab customization work?
The number of customizations, their depth and the systems they touch drive cost the most. A change to instance or group settings is a small task. Custom CI/CD components, runner images, webhooks, system hooks and integrations with Jira, chat or artifact stores each need design, build, testing and documentation. Work that must pass through your change control, or that runs in an offline network, adds effort. Ask the partner to itemize the written scope by customization so you can see which items carry the effort and which are optional. DeployOpen does not publish a price list, so a quote follows from that written scope.
Is GitLab customization work fixed-scope or billed by the hour?
Most DeployOpen engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, so you know what is included before any work begins. Ask for the scope to list each customization, the acceptance criteria for each one, the systems and accounts involved, and what happens if your requirements change during delivery. Ongoing work such as upgrades and continuous support is available as a retainer, which is a separate written agreement.
What recurring costs follow after customizations go live?
Upgrades, maintenance of custom components and runner compute recur. GitLab ships a major release yearly, a minor release each month and patch releases twice a month. Custom CI/CD components, webhooks and integrations may need changes when GitLab changes its APIs or templates. Runner compute is often the largest ongoing cost, because it scales with pipeline volume. Upgrades must pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11 and 19.2, 19.5, 19.8 and 19.11, according to the GitLab upgrade paths documentation. Ask the partner to estimate each recurring item in the quote and to state who pays for it.
Can our own engineers maintain GitLab customizations without outside help?
Yes, if someone on your team has the skills and time to own the work after handover. Customizations written in the GitLab API, CI/CD YAML, or with custom runners need people who can read the code, test it and respond when an upgrade changes behavior. Before deciding, check whether your team can run the GitLab upgrade path, review changes to the configuration files, and maintain the runner images. The GitLab maintenance policy only backports bug fixes to the current stable release, so older custom code may need rework. Ask the partner which parts the team can run alone and which parts need a support retainer.
How much of our staff time does customization need?
Your staff time is needed for requirements, access, reviews and acceptance testing. Expect your engineering leads to define the workflows to change, your platform team to provide accounts and network access, and your security team to review settings and secrets handling. Your Jira, chat or artifact store owners may be needed for integration testing. The exact hours depend on the scope, so ask the partner to list each role, the meetings or reviews involved, and the point in the schedule where each is needed. A written scope makes these commitments visible before work starts.
How are GitLab customizations handed over to our team?
Handover should include the code, configuration, documentation and a knowledge transfer session. Ask for every custom component, script, webhook definition, runner configuration and integration to be stored in a repository you control, with the GitLab settings that were changed recorded. Documentation should explain how each customization works, how to test it, how to roll it back, and which GitLab version it was verified against. Request a walkthrough with the engineers who will own the work, and confirm in the written scope who holds the credentials and tokens at handover.
How long does a typical customization project take?
Duration depends on the scope, your approvals and the systems involved. Small settings and template changes move quickly. Projects that add runners, several integrations or offline installation take longer, because each needs environment access, testing and sign-off. Duration is set in the written scope, so ask for milestones tied to deliverables, the dependencies on your side, and the testing window before go-live. Do not accept a duration that is not tied to a listed deliverable.
What should we confirm about the GitLab edition before customizing?
The edition decides which features you can customize against. GitLab Free costs 0 dollars, Premium costs 29 US dollars per user per month billed annually according to the GitLab pricing page, and Ultimate is custom priced. The pricing page lists advanced CI/CD and priority support for Premium, and application security, compliance and vulnerability management for Ultimate. Confirm with GitLab which features your chosen tier includes before the scope is written, because a customization that depends on a higher tier adds licence cost that is not part of the services quote.
How DeployOpen scopes, builds and hands over GitLab customizations
DeployOpen plans, builds, tests, documents and hands over GitLab customizations inside your own infrastructure, whether that is your cloud accounts, data centers or an air-gapped network. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- We inventory your current instance settings, groups, CI/CD templates, runners and integrations before defining any change.
- The written scope names each customization, the GitLab version it targets and the systems it touches, such as Jira, chat or artifact stores.
- We confirm which customizations depend on your GitLab tier, since some features are limited to Premium or Ultimate, and document that assumption.
How we build
- We build webhooks, system hooks, API automation and CI/CD templates or components in version-controlled repositories you own.
- Custom runners and images are configured to match your GitLab version, with Runner and GitLab major and minor versions kept aligned.
- Each change is tested on a non-production instance that mirrors your installation method, before it is promoted to production.
How we hand over
- You receive the source, configuration and deployment steps, along with documentation of every custom hook, template and integration.
- We run a walkthrough with your administrators covering how to change, roll back and troubleshoot each customization.
- Handover includes a record of which customizations must be re-tested at each required upgrade stop, so your team can plan upgrades.
How we support
- Ongoing support, upgrades and continuous testing of your customizations are available as a retainer, separate from the fixed-scope project.
- Retainer scope is agreed in writing and can cover checking custom code against monthly minor releases and security patches.
- Ask any provider to confirm in writing which customizations their support covers and how breaking changes in GitLab releases are handled.
