GitHub Actions vs GitLab CI/CD: when each one fits
If your renewal, a data residency requirement or lock-in concern is pushing you to rethink where CI runs, the first question is which platform should own both the code and the pipelines. GitHub Actions fits teams that want to keep GitHub as the forge and its workflow YAML, with the runners they choose to operate. Self-managed GitLab fits teams that want source hosting, merge requests, CI/CD and security tooling in one platform that they install and run in their own infrastructure.
The practical difference is what you take on. With GitHub Actions, you keep the repository hosting you already use and add self-hosted runners, which means you operate the runners and whatever sits behind them, while the forge stays where it is. With self-managed GitLab, you run the forge itself, so the GitLab installation, upgrades and backups become your obligation. Before you choose, review the GitLab maintenance policy and the upgrade paths, because required upgrade stops mean an upgrade is a planned project with its own staffing. Confirm with GitLab which installation method and reference architecture match your user count, and whether your team can run the stateful services that the reference architectures place outside Kubernetes.
The decision turns on three questions. First, can your code leave the current forge, or must repositories, merge requests and pipeline definitions move together? Second, how many people will administer and use GitLab, which determines the operating load and the high availability design you need? Third, which CI features must the tier include: advanced CI/CD in Premium, or the security, supply chain and compliance capabilities that the pricing page places in Ultimate. Write those three answers down before you request a quote, because they set the tier, the team and the scope.
Which option fits which scenario
This table maps common buyer situations to the option that fits best, with the condition that decides it. Read each row by checking whether the condition applies to your organization, since the fit often depends on where repositories may live and who will run upgrades.
| Scenario | Better fit | Reason |
|---|---|---|
| Keeping GitHub but needing in-house runners | GitHub Actions with self-hosted runners, or Woodpecker CI beside GitHub | Code can stay on GitHub while builds run in your own network. Confirm the runner model and any metering terms with GitHub before committing to a cost model. |
| One self-hosted forge for regulated code | GitLab CI/CD on a self-managed instance | Repositories, merge requests, pipelines and artifacts sit on one platform inside your infrastructure, so no build data leaves your control. Plan for the installation and upgrade obligations. |
| Air-gapped builds | GitLab CI/CD on a self-managed instance | GitLab documents offline, air-gapped deployments. Confirm which CI features and scanners your offline setup needs, since some depend on external services. |
| Team already on GitLab | GitLab CI/CD | Existing .gitlab-ci.yml pipelines, runner registrations and permissions already fit the platform, so the switch is a conversion project rather than a new forge. |
| Team already on GitHub with workflow YAML they want to keep | GitHub Actions or a Gitea or Forgejo forge | Workflow syntax carries over more easily to compatible forges than to GitLab, whose pipeline format differs. Choose GitLab only if the forge move is also wanted. |
| Small team without platform staff | Hosted GitHub Actions or a managed forge, unless you can staff upgrades | A self-managed GitLab instance adds installation, backup, patching and forced upgrade stops to someone's job. If no one owns that work, the operating burden can outweigh the benefit. |
| Premium or Ultimate features needed | GitLab Premium or Ultimate on self-managed | Advanced CI/CD and some security and compliance features sit in paid tiers. Confirm which features you need against the current GitLab pricing page before choosing a tier. |
How hosting changes data control and compliance
With GitHub-hosted Actions, repositories, workflow logs, artifacts and Actions secrets are stored and operated by GitHub, and the hosted runners execute your jobs on GitHub's infrastructure. GitHub Enterprise Server moves the forge, Actions and its data into your own data center or cloud account, while you still operate the server and its storage. In both cases the secret store is a service boundary you must document, because the REST API returns Actions secret names without values, so a platform change means re-creating each secret rather than exporting it.
- Code and history: Hosted GitHub keeps repositories on GitHub's platform; Enterprise Server keeps them on the instance you run.
- Logs and artifacts: Hosted retention is limited by platform settings, with GitHub Actions defaulting to 90 days, so export before expiry.
- Secrets: Values are write-only through the API, so the record of who set what lives in your change process, not in the platform.
- Runners: Self-hosted runners on Enterprise Server run in your network, but you must confirm which telemetry and update paths still reach GitHub.
- Air-gapped use: Enterprise Server is GitHub's documented route for isolated networks, which you should verify against your own connectivity rules.
Confirm with GitHub which data classes leave your environment in each deployment option, and get that in writing for your assessor.
GitLab.com is a multi-tenant service operated by GitLab, so repositories, pipeline logs, job artifacts and CI/CD variables sit on GitLab's infrastructure under GitLab's contractual and technical controls. For a regulated organization the question is less about where the bytes sit and more about which contract, region and access model applies, and whether your auditor accepts the vendor's evidence for the controls you need. Your team still owns project permissions, variable scoping and pipeline design, which means misconfiguration risk remains with you even though the platform is operated by someone else.
- Shared platform: Your CI data runs on a service used by other customers, so isolation and access are defined by GitLab's own controls.
- Variables: Project and group CI/CD variables are managed in GitLab and your team controls who can read or change them.
- Artifacts and logs: Retention is set by GitLab and your project settings, so review those values against your records policy.
- Evidence: Ask GitLab which third-party reports and attestations cover the service, and which of them your auditor will accept.
- Migration: Moving off GitLab.com later requires exporting projects and re-entering secrets, so plan that cost up front.
Confirm current data location options, retention settings and the audit reports available before you rely on them in scope.
A self-managed GitLab instance places the forge, the CI control plane, runners' coordination, logs, artifacts, database and backups inside your environment, which gives you direct ownership of storage location, retention and access logging. GitLab documents installation through the Linux package, Helm chart, GitLab Operator, Docker or source, and documents offline and air-gapped operation with separate guidance for security scanners and GitLab Duo Self-Hosted. Those choices change where state lives, so the data inventory has to follow the install method you actually run.
- Data stores: The database, Gitaly repository storage, object storage for artifacts and backups all need owners, encryption and backup testing.
- Runners: GitLab Runner executes jobs on runners you host, so job logs and secrets exposed to jobs stay on your hosts.
- Identity: Authentication and authorization can be integrated with your directory, which lets access reviews cover CI as well as code.
- Air-gapped use: Offline installs need packaged scanner data and updates imported by your team, which is an ongoing process.
- Licensing: Outside the ee/ directory the source is MIT Expat, while ee/ content falls under the GitLab Enterprise Edition license, so confirm which edition's features and terms your team relies on.
Ask DeployOpen or your architect to map each data class to a storage location and owner, then confirm the controls with your auditor.
GitLab's source repository is open core. Content under the ee/ directory is licensed under the GitLab Enterprise Edition license, and content outside it is available under the MIT Expat license. For compliance work this matters because the features you enable determine which license terms apply, and the self-managed Free, Premium and Ultimate tiers differ in which CI and security capabilities they include. Licensing review is therefore part of the data control analysis, not a separate procurement step.
- License split: Map each CI and security feature you plan to use to its license location in the repository.
- Tier features: Advanced CI/CD and priority support sit in Premium, while application security and compliance features sit in Ultimate.
- Evidence: DeployOpen prepares configuration, access and backup evidence for your controls, while independent auditors issue any attestation.
- Patching: Security fixes are backported to the previous two monthly releases, so plan upgrades inside that window.
- Upgrade stops: Required upgrade stops apply, so the upgrade path is part of your operational control set.
Confirm licensing and tier terms with GitLab in writing, and ask your assessor which evidence formats they will accept.
What running self-managed GitLab requires from your team
Choosing GitLab CI/CD on a self-managed instance means your team also becomes the operator of a large application, so the first decision is which installation method you can support for years. GitLab documents the Linux package as the most mature and scalable method, and it bundles PostgreSQL, Redis and Sidekiq, so the database, cache and job queue are upgraded and backed up with the application. The Helm chart, the GitLab Operator, Docker and source installs are also documented. Each one moves more of the component lifecycle onto your own platform team, so confirm which method matches your Kubernetes and VM skills before you commit to it.
Sizing comes next. GitLab's reference architectures run from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second, and the documentation generally recommends a high availability strategy once you reach 3,000 or more users. That strategy relies on Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Ask your team who will run Patroni failover and Gitaly repair, and whether they have done it before, because those tasks are where self-managed GitLab outages usually start.
The documentation says PostgreSQL and Redis should not run inside Kubernetes, so a cluster-first plan must place those stateful services on virtual machines or managed services. The Cloud Native Hybrid architecture follows that rule by running stateless components on Kubernetes and stateful services elsewhere. Before you pick a topology, check the reference architecture page for your user count, confirm which database and storage services your organization already operates, and write down who owns backups, which GitLab backup and restore procedure you will test, and how upgrades fit the required upgrade stops.
GitLab upgrade and maintenance obligations
How often does GitLab release a new major version?
GitLab ships one major release each year, and the maintenance policy lists GitLab 20.0 as planned for May 2027. A major number is not a reason to upgrade on its own, but it is the point where a team should check deprecations and removed features against its own configuration. Plan a yearly review window for major changes, separate from the routine monthly patching. Confirm the planned date and any breaking changes in the GitLab maintenance policy before you set your calendar.
When does GitLab publish its minor and patch releases?
GitLab publishes a minor release on the third Thursday of each month and patch releases twice a month. For a self-managed instance, this means a steady stream of updates that a team has to triage, test and schedule. Patch releases matter most because they carry fixes that need to reach production quickly. Build a standing test environment that mirrors your CI runners and integrations so each release can be validated before it reaches the production instance.
Which GitLab release lines are currently supported?
The maintenance policy currently maintains 19.5, 19.4 and 19.3. Any instance running an older line is outside that set and needs to move forward, usually through the required upgrade stops described below. Check the current list on the maintenance policy page on the day you plan, because the set changes as new minor releases ship. Record which line each environment runs, including development, staging and any air-gapped copies.
Does GitLab backport bug fixes to older releases?
Bug fixes are backported only to the current stable release. Security fixes go further and are also backported to the previous two monthly releases. In practice, a team that waits for a bug fix on an older line may wait for a full upgrade, while security fixes reach a slightly wider set of versions. Ask your team to decide whether it is comfortable running a line that receives only security fixes, and document that decision with the security owner.
What are GitLab required upgrade stops, and since when do they apply?
Since GitLab 17.5, upgrades must pass through required upgrade stops at versions x.2, x.5, x.8 and x.11. The upgrade paths documentation gives examples such as 18.2, 18.5, 18.8, 18.11 and 19.2, 19.5, 19.8 and 19.11. An instance that skips a stop cannot simply jump to the newest release, so the upgrade plan has to include each stop in order. Confirm the current stop list and the path from your version in the GitLab upgrade paths documentation before scheduling.
How should a team build an upgrade calendar around these obligations?
A workable calendar has three layers: a monthly minor and twice-monthly patch cycle, a yearly major review, and planned stops that move the instance forward in sequence. Each stop needs a backup, a restore test and a rollback plan, because backups and restores are the safety net for a multi-step path. Estimate the staff time for each layer from your own pipeline volume and integration count, since the effort depends on how much CI configuration, runner software and custom code the instance carries. Ask for a written scope before outsourcing any part of this cycle.
What should we confirm with GitLab before we plan upgrades?
Confirm the current supported lines, the next major release date, the required upgrade stops from your current version and any breaking changes that touch CI features you use. Ask which Runner versions match each GitLab line, since runners are upgraded separately. For air-gapped environments, check the offline guidance so that package and security scanner updates can be imported without internet access. Write these answers into your change calendar and review them whenever GitLab publishes a new policy update.
Who pays for GitLab upgrades when you run the instance yourself?
With a self-managed instance, the upgrade work falls on your staff or a services partner you hire, and it recurs every month and every year. Costs include staff time for testing, backup verification, maintenance windows, rollback preparation and runner updates, plus any infrastructure needed for a staging copy. A subscription tier does not remove this work. Ask any partner for a fixed-scope written proposal that names the upgrade cadence, the environments covered and what happens when a required stop falls inside a busy release period.
GitLab Runner and GitHub runners compared in practice
Both platforms run jobs on runners you can place inside your own network, but the unit of work, the secrets model and the retention rules differ. The cards below cover the decisions that change how a migration or a parallel run behaves in practice.
Runner registration and executors
GitLab Runner is a separate agent that you register against a GitLab instance and configure with an executor, such as Docker, Kubernetes or shell. GitHub self-hosted runners use a similar registration step but are tied to repositories, organizations or enterprises through GitHub's own settings. If your pipelines rely on a specific executor or Docker-in-Docker behavior, test that combination on the GitLab side before you retire GitHub runners.
Stages and jobs versus workflow jobs
A .gitlab-ci.yml file groups jobs into ordered stages, and jobs in the same stage run in parallel. GitHub workflows describe jobs that run in parallel by default and use needs to express dependencies. Teams that depend on stage ordering will need to rewrite dependencies explicitly when moving from needs based workflows, and matrix builds do not map one to one.
Runner placement and network access
Self-managed GitLab Runners can sit in the same network as your GitLab instance, your artifact stores and your deployment targets, which removes the need for inbound connections from the internet. On the GitHub side, self-hosted runners are placed where you install them but still poll GitHub for jobs. Check which systems each runner must reach, including package mirrors, container registries and internal Git servers, before you size the network path.
Secrets that cannot be exported
GitHub's REST API returns Actions secret names without their values, so a migration to GitLab CI/CD means re-entering every secret by hand from the source of truth. Plan for this during cutover, rotate credentials that were ever exposed to shared runners, and record which owner supplied each value. Treat the re-creation step as a separate task with its own review, not a copy operation.
Artifact retention on each side
GitHub Actions keeps artifacts for 90 days by default, and that setting can be changed in repository or organization settings. GitLab artifact expiry is set per job or project in the pipeline configuration. Export any build history, logs or artifacts that your audit or release process needs before GitHub's window closes, and confirm the retention values you configure on the GitLab instance match your policy.
Offline and air-gapped setup
GitLab documents running self-managed instances in offline, air-gapped environments, and it provides separate guidance for its security scanners. GitHub's answer for isolated networks is GitHub Enterprise Server with self-hosted runners. Confirm which GitLab features you need offline, including scanners and any AI features, and verify that runner images, dependency mirrors and actions or templates can be imported into the isolated network before you commit to the design.
How a move from GitHub Actions to GitLab CI/CD unfolds
The sequence moves workflows, secrets, run history and runners from GitHub into a self-managed GitLab instance in an order that keeps builds working until cutover. Each step closes with a check the team can confirm before the next one starts.
Inventory workflows, actions and secrets
The platform team lists every repository with workflow files under .github/workflows, the marketplace actions each workflow calls, the self-hosted runners in use, and the environments and secrets each job depends on. Owners of deploy jobs confirm which credentials they rely on, since GitHub's REST API returns secret names without values and those values must be re-supplied later. The inventory is done when every workflow has an owner and every action has a decision: keep, replace with a script or template, or retire.
Decide where the forge and CI will live
Leadership and the platform team decide whether GitLab will host the code as well as the pipelines, or whether code stays on GitHub while GitLab CI/CD runs builds through external integrations. Moving repositories and CI together gives one permission model and one audit trail, while splitting them adds cross-system tokens to maintain. The decision is recorded in writing with the hosting location, identity provider and data residency requirements, and the owners of each system named.
Install and size the GitLab instance
DeployOpen or the client's infrastructure team installs self-managed GitLab in the target environment, using an installation method that fits the operating model and the offline or air-gapped constraints if they apply. Sizing follows GitLab's reference architectures, which scale by user count and API request rate and recommend a high availability design at larger scale, with stateful services such as PostgreSQL and Redis kept on VMs or managed services rather than inside Kubernetes. Backup and restore are tested before any repository is moved. The step closes when a test backup restores into a separate environment.
Configure identity, access and security baseline
Administrators connect the corporate identity provider, define groups that map to the existing GitHub teams, and apply the hardening recommendations for the instance, including protected branches, protected variables and runner access rules. Access is reviewed against the current GitHub permissions, so that no user gains rights they did not have before. The step is complete when a sample group of users can sign in and see only the projects they were granted.
Import repositories with GitLab import tooling
Repositories are imported into GitLab using its built-in import and migration tools, starting with a pilot project that has representative workflows. Issues, merge requests and other metadata are checked for what the importer carries across, and any gaps are recorded for manual handling. Each imported project is compared against its GitHub source for branches, tags and default branch. The step closes when the pilot repository matches its source and the owner signs off.
Rewrite workflows as .gitlab-ci.yml
Each GitHub workflow is translated into a .gitlab-ci.yml pipeline. Triggers, job dependencies, caching and artifacts are mapped to GitLab keywords, marketplace actions are replaced with scripts, container images or CI/CD components, and deploy jobs are pointed at GitLab environments. The mapping is documented per workflow so reviewers can see what changed and why. The step is done when each translated pipeline runs on a branch and its job results match the GitHub run for the same commit.
Re-create secrets and export run history
Secrets are re-created in GitLab CI/CD variables or the chosen external secrets manager, because GitHub will not return their values, and each value is supplied by its owner rather than copied from a file. Run history, logs and artifacts are exported through the GitHub API or GitHub CLI before GitHub retention expires, and stored in the location the audit policy specifies. The step closes when a list shows every secret present in GitLab and an archive of run records is verified to open.
Register runners and run in parallel
Runners are installed and registered with the GitLab instance, using the executor type that matches the build environment, such as Docker or Kubernetes. For a period both pipelines run on the same commits, and the team compares results, timing and artifacts, and fixes differences. Runner capacity, network access to package sources and access to deploy targets are confirmed during this phase. The step is complete when pipeline results agree across the parallel runs for the agreed set of repositories.
Cut over and retire GitHub workflows
The team moves protected branches and deploy rights to GitLab, disables the GitHub workflows for migrated repositories, and confirms that merge requests and deployments run only from GitLab. Support contacts, runbooks and the rollback plan are updated, and a fallback path is kept until the owners agree it is no longer needed. The cutover is done when no migrated repository triggers a GitHub workflow and the change record names the owner of each pipeline.
Cost components on each side and what drives them
On the GitHub side, the cost has three separate parts that you should price individually: hosted runner minutes, charges for self-hosted runners, and GitHub Enterprise licensing if you run Enterprise Server. Self-hosted runners are free today, but GitHub announced a $0.002 per minute charge for them before postponing it, so confirm the current terms in writing before you model a long-term budget. Hosted minutes are driven by build frequency, matrix size and job duration, and storage for artifacts and caches is a further line item. On the GitLab side, the recurring cost starts with the subscription. The GitLab pricing page lists Free at 0 dollars and Premium at 29 US dollars per user per month billed annually, with Ultimate custom priced. Check which CI/CD features you actually use, because the page places advanced CI/CD in Premium.
Self-managed GitLab also carries costs that a hosted forge hides. You pay for the servers or cloud accounts that run the instance, the storage for repositories, the database and the backups, and the runner hosts that execute jobs. Staff time is usually the largest unpriced item. Upgrades must pass through required upgrade stops, and the maintenance policy describes a monthly minor release and two patch releases each month, with security fixes backported to more releases than bug fixes. Someone must own that cadence, along with backup restore tests. External support is optional, but if you buy it, its level and response terms belong in the contract. Ask your team to estimate the monthly hours for upgrades and restores, since that figure drives the true cost more than the license line.
Migration is a one-time cost. It covers converting workflow files into .gitlab-ci.yml, deploying and registering runners, re-creating secrets (GitHub returns secret names but never their values, so each value must be re-entered from its source), exporting run history before retention expires, and validating deployments. Recurring costs begin once the platform is live. When you request a quote from any implementation partner, including DeployOpen, ask for a written scope that lists the GitLab tier mix and user count, the number of runner hosts, the high availability design, the upgrade and backup responsibilities, the support hours, the workflow count, and what is excluded. A fixed scope with named deliverables makes the two sides comparable and shows which costs stay with your staff after handover.
Questions buyers ask before moving from GitHub Actions to GitLab
What does it cost to self-host GitLab compared with GitHub Actions?
Self-hosting GitLab replaces a metered service with infrastructure and staff time you own, so the comparison depends on your own numbers. GitLab Free has no licence fee, Premium is listed at 29 US dollars per user per month billed annually on the GitLab pricing page, and Ultimate is custom priced. The recurring costs are servers or cloud accounts, storage, backups, the Runner fleet, and the people who patch and upgrade the instance. The one-time costs are planning, data migration and the CI rewrite. Ask a partner for a quote built from your user count, Runner concurrency and high availability needs, since reference architectures scale from 1,000 users to 50,000 users.
How long does a migration from GitHub Actions to GitLab take?
The timeline is set by how many repositories and pipelines you have, how much of your CI relies on GitHub-specific actions, and how many systems still call your current forge. A small set of repositories with plain build and test jobs moves far faster than a large estate with reusable workflows, environment approvals and deployment secrets. Secrets cannot be exported from GitHub, because the REST API returns secret names without values, so every secret must be re-entered and verified. Build history and artifacts also expire on GitHub, so exports must happen before cutover. Ask for a fixed-scope plan that lists repository waves, pilot projects and rollback steps before any work starts.
Can our team migrate to GitLab without outside help?
Yes, a team with Linux and GitLab administration experience can install GitLab and convert simple pipelines alone, and GitLab publishes installation methods and documentation for that path. The harder parts are production readiness: high availability for 3,000 or more users, backups and restore testing, offline operation if you are air-gapped, and security hardening. Your team should confirm whether it can cover on-call, upgrades and vulnerability response for the instance over the long term. An external partner can plan, implement and document the platform on a fixed scope, then leave your staff with runbooks, or continue on a retainer for upgrades and testing.
What does the migration need from our engineers and administrators?
Expect a mix of platform, pipeline and security work. Platform administrators need to size the Linux package, PostgreSQL, Redis and Gitaly, and decide how stateful services run, since GitLab's reference architectures say PostgreSQL and Redis are not supported inside Kubernetes and the Cloud Native Hybrid pattern runs them on VMs or managed services. Pipeline owners rewrite workflow YAML into .gitlab-ci.yml, map GitHub Actions to GitLab CI components, and set up GitLab Runner executors. Security staff review secret scopes, runner isolation and access control. Plan time for each group in the scope document.
Do we need GitLab Premium or Ultimate for our CI features?
It depends on which CI features you use. GitLab Free covers the core pipeline model, and the GitLab pricing page lists advanced CI/CD and priority support as Premium features, while application security testing, software supply chain security, vulnerability management and compliance features sit in Ultimate. Map each feature your GitHub workflows use today, such as environment approvals, required reviews, scanning steps or audit reporting, against the tier that includes it, and confirm the exact entitlement with GitLab before purchase. Licensing is per user, so the seat count drives the cost of Premium.
How do GitLab upgrades work, and what do we have to plan for?
GitLab ships a major release yearly, a minor release on the third Thursday of each month and patch releases twice a month, and it maintains the three most recent minor versions listed in its maintenance policy. Bug fixes go only to the current stable release, while security fixes also go to the previous two monthly releases. Upgrades must pass through required upgrade stops, which since GitLab 17.5 fall at x.2, x.5, x.8 and x.11, for example 19.2, 19.5, 19.8 and 19.11. Plan a recurring window for each stop, a staging rehearsal, a verified backup before every step, and a named owner who tracks releases.
Is GitLab's source code safe to self-host under our licence rules?
Yes, but review the terms first. GitLab's repository is open core: code under the ee/ directory is covered by the GitLab Enterprise Edition licence, and code outside it is available under the MIT Expat licence. Your legal team should read the LICENSE file and confirm which features and distributions your use case allows. Ask your partner to document which edition and version you run, so audits and upgrades refer to the same build.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted GitLab inside your own cloud accounts, data centers or air-gapped networks. For a GitHub Actions to GitLab CI/CD move, that work usually covers the GitLab instance itself, the installation method you choose, runner fleets and executors, the migration of repositories and secrets, and the operating runbooks your team needs after handover. Because GitLab couples the forge and CI, the scope also has to settle who owns the upgrade calendar, including the required upgrade stops, and how backups of the database, repositories and CI configuration are tested. DeployOpen also runs security testing against the resulting pipelines and the instance, and prepares the controls and evidence that your compliance assessors will ask for. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
Most engagements are fixed-scope. Before work starts, DeployOpen agrees the scope, deliverables and timelines in writing, and a quote follows from that written scope rather than from a published price list. To make that scope concrete, ask for the number of users and projects, the workflows and marketplace actions that must be translated, the secrets to re-create, the Premium or Ultimate features you need, and whether the environment is offline. Your engineers will then have a defined handover point, which makes the decision to move easier to review.
After the first release, most teams need ongoing help with patch and minor releases, upgrade testing, runner capacity and periodic security testing. DeployOpen offers this support as retainers, which can be set up alongside the fixed-scope implementation. Before you sign anything, confirm with DeployOpen in writing which parts of the work are in scope, who holds administrator access to the instance, and how responsibilities are split between your team and ours for incidents and upgrades.
