GitLab Dedicated vs GitLab self-managed: which model fits your team
GitLab Dedicated suits a regulated team that wants GitLab run by its vendor on AWS, in a region it picks, with a single-tenant instance and no infrastructure to patch. GitLab Dedicated is a fully isolated, single-tenant SaaS hosted and managed by GitLab, deployed on AWS in the customer's chosen region, with high availability, disaster recovery and a monthly 99.9% availability objective. Self-managed GitLab suits a team that must keep the platform inside its own data centers, cloud accounts or air-gapped network, or that needs control over upgrades, hooks and authentication. The deciding question is where your data is allowed to run and who must operate it.
If your organization has no AWS footprint, Dedicated brings a new cloud provider and a new contract into scope, which many risk and procurement teams will need to review. GCP and Azure hosting are not offered for Dedicated, so a team that must run on those clouds should treat self-managed GitLab as the default. Air-gapped operation is also a self-managed path: GitLab documents offline environments, and a hosted service is not a fit for a network with no outside connectivity. Confirm with GitLab, in writing, the regions and data residency terms that apply to your contract before you rely on them.
Self-managed GitLab gives your team control over the platform, while Dedicated saves the operating burden. Dedicated removes the work of running the Gitaly, PostgreSQL, Redis and object storage tiers, and it keeps engineers from having direct access to your environment. It also offers an optional customer-managed AWS KMS key for data at rest. Self-managed GitLab keeps those duties with your team, but it also lets you choose your install method, schedule upgrades against GitLab's required upgrade stops, and keep server-side Git hooks and LDAP or Kerberos authentication. Ask GitLab for a written statement of who performs backups, restores and upgrades under each model before comparing quotes.
GitLab Dedicated vs self-managed side by side on control, features and terms
This table sets GitLab Dedicated, the single-tenant hosted service, beside running GitLab Self-Managed in your own infrastructure. Read each row as a control question: where data sits, who operates the instance, which features you keep, and what happens when the subscription ends. Rows that depend on your own environment name what to confirm with GitLab before you sign.
| Decision factor | GitLab Dedicated | GitLab self-managed |
|---|---|---|
| Hosting location | Fully isolated single-tenant SaaS hosted and managed by GitLab, deployed in an AWS region of your choice | Runs in your cloud accounts, data centers or air-gapped networks, so location is set by your own infrastructure |
| Cloud provider options | AWS only; GCP and Azure deployments are not supported | Any environment you can build and operate, subject to GitLab's installation and architecture guidance |
| Customer-managed keys | Optional use of your own AWS KMS key for data at rest; confirm key rotation and access steps with GitLab | You control encryption and key management in your own environment, with the operating burden that comes with it |
| Feature set | Based on the Self-Managed Ultimate feature set, minus the listed exceptions such as LDAP and server-side Git hooks | Whatever tier you license: Free, Premium or Ultimate, with features gated by that tier |
| Authentication options | SAML or OIDC SSO; LDAP, smart card, Kerberos, SSH certificate authentication and reply by email are unavailable | Broader options, including LDAP, subject to the tier you license; confirm the exact methods your tier includes |
| Availability commitment | High availability with disaster recovery and a monthly service level objective of 99.9% availability from GitLab | You define availability through your own architecture, backups and staffing; no vendor SLA applies |
| Upgrade ownership | GitLab operates the service and its upgrades; confirm upgrade windows and notice periods in your contract | Your team plans and applies upgrades, following required upgrade stops such as 18.5 and 19.5 |
| Air-gapped operation | Not the model: the instance is hosted by GitLab on AWS | Documented offline and air-gapped operation; confirm which scanners and AI features need separate offline setup |
| Subscription end | Access continues for 30 days after expiry, then the instance is terminated and content is deleted unless archived or migrated | Your data stays in your environment; confirm license downgrade behavior with GitLab before renewal decisions |
How data location, key control and access change the compliance picture
For a regulated team, the hosting model decides who holds the data, which keys protect it and who can reach it during an assessment. The cards below cover what GitLab Dedicated fixes for you and what stays with your own controls, evidence and auditors.
Region selection on AWS only
GitLab Dedicated runs on AWS only. You choose the AWS region, but GCP and Azure deployments are not supported. If your data residency rules, cloud standard or existing landing zone point to Azure or Google Cloud, Dedicated is off the table, and self-managed GitLab becomes the route to a non-AWS location. Confirm the region options available for your account with GitLab before you assume a specific region is offered.
Optional customer-managed AWS KMS key
Dedicated can encrypt data at rest with your own AWS KMS key, which is optional rather than automatic. With a customer-managed key, your team controls key policy, rotation and revocation in your own AWS account. Ask GitLab how key access is granted, what happens to the instance if the key is disabled, and who in your organization is responsible for that key during an incident.
Encryption in transit and at rest
GitLab Dedicated encrypts data both at rest and in transit by default. Self-managed GitLab leaves that work to you: TLS termination, disk or volume encryption, database and object storage encryption, and backup encryption are all your configuration and your evidence. Map each of those controls to the requirement it satisfies, and record where the keys for backups are held.
No direct engineer access to your environment
GitLab Dedicated engineers do not have direct access to customer environments. That limits GitLab staff access, but it does not remove your own administrator access or the access your integrators hold. For a self-managed instance, every administrator, support engineer and implementation partner with server access falls inside your access review. Write down who holds privileged access in each model and how that access is logged.
FedRAMP-hosted Dedicated for Government
GitLab also offers GitLab Dedicated for Government with FedRAMP-compliant hosting. FedRAMP authorization is a program status you verify directly with GitLab and the relevant authorizing body, not a property you inherit by choosing the product. Confirm the authorization level, the boundary and the scope of inherited controls before you rely on it in a system security plan.
Ultimate-only features and the authentication gaps Dedicated leaves open
The first thing to settle is that GitLab Dedicated runs the Self-Managed Ultimate feature set with listed exceptions, so the tier question that dominates a self-managed purchase matters much less here. You do not pick Free, Premium or Ultimate for a Dedicated tenant in the same way. What you need to check instead is whether the exceptions touch a workflow your organization depends on. Read the exceptions list in the GitLab Dedicated documentation against your current instance before you assume feature parity.
The exceptions that most often surprise identity and platform teams are LDAP, smart card and Kerberos authentication, SSH certificate authentication, reply by email, Service Desk and server-side Git hooks. Dedicated does not offer these. The documented workaround is to use SAML or OIDC single sign-on for authentication and to replace server-side hooks with push rules or webhooks. Push rules enforce commit and branch policy inside GitLab, while webhooks send events to systems you operate, so any enforcement that currently runs as a server-side hook needs to be redesigned, tested and owned by your team. If your directory group sync or Kerberos ticketing relies on the unsupported methods, that work belongs in the decision, not after it.
Self-managed teams have a different job. Free, Premium and Ultimate each expose a different set of features, so you must confirm every feature you rely on against the tier you will buy, using the GitLab pricing page and the authentication and authorization documentation for the instance. Then check identity integration against your directory before you decide: list the authentication methods your users actually use today, including LDAP group sync, smart cards and SSH certificates, and confirm which of them your target tier and deployment model support. Ask GitLab or your implementation partner to confirm each item in writing, because a gap found after cutover is far more expensive to fix than one found during evaluation.
Which hosting model fits each team profile
This profile fits a team that already runs production workloads on AWS, has mature account governance, and is comfortable delegating GitLab's day-to-day platform operations to a vendor. GitLab Dedicated is a fully isolated, single-tenant service that GitLab hosts and manages on AWS in a region the customer chooses, so the team keeps region and key control without running the GitLab stack itself. The team accepts less host-level control and a narrower feature and authentication set in exchange for less operating work.
- Region choice: the instance is deployed in an AWS region of your choosing, which helps with data residency commitments when that region is the only one your policy allows.
- Optional customer KMS key: you can use your own AWS KMS key for data at rest, which keeps key custody in your AWS account.
- Shared operations model: GitLab engineers do not have direct access to your environment, so confirm how access requests, break-glass steps and logging are handled in the contract.
- Authentication trade-off: LDAP, smart card, Kerberos, SSH certificate authentication, reply by email, Service Desk and server-side Git hooks are not available, so plan on SAML or OIDC SSO and push rules or webhooks.
- Ultimate-based features: the feature set follows Self-Managed Ultimate with listed exceptions, so verify each control you rely on against the current Dedicated documentation.
Before committing, confirm the exit terms: after a subscription expires, access continues for 30 days before the instance is terminated and content is deleted unless it has been archived or migrated.
This profile fits a team that must keep GitLab inside its own data center or an air-gapped network, either because policy forbids hosting source code in a third-party cloud or because the network has no outbound path. Self-managed GitLab is the model here, because GitLab Dedicated runs on AWS and cannot be placed on your premises. GitLab documents running self-managed instances in offline environments, with separate guidance for its security scanners and GitLab Duo Self-Hosted. The team accepts that it owns installation, patching, backups and upgrade planning.
- Full host control: you choose the operating system, network segmentation, storage and hardening baseline, and you decide how privileged access is granted.
- Offline operation: review GitLab's offline environment guidance for the scanners and features you need, since some depend on connectivity to update content.
- Upgrade discipline: GitLab requires upgrades to pass through required upgrade stops, so an offline mirror of packages and a rehearsed upgrade path are part of the operating cost.
- Authentication freedom: LDAP, Kerberos and other directory options that Dedicated does not offer can be configured against your own identity infrastructure.
- Backup ownership: you design, test and store backups, including restores into an isolated environment.
Ask the GitLab account team and your auditors to confirm which features your air-gapped deployment must omit, and cost the internal staff time against the paid tier you need.
This profile fits a platform team that already operates Kubernetes and runs PostgreSQL high availability with Patroni, and that has the skills to maintain stateful services with the same rigor as the rest of the estate. Self-managed GitLab gives this team a path to the high availability reference architectures, which GitLab recommends for 3,000 or more users and which use Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. The team accepts responsibility for every component and for the failover behavior that GitLab Dedicated would otherwise absorb.
- Reference architecture fit: the high availability design maps onto components you may already run, so existing monitoring, backup and runbook practices can extend to GitLab.
- Hybrid placement: GitLab's Cloud Native Hybrid architecture runs stateless components on Kubernetes while stateful services stay on VMs or managed services, because GitLab says running PostgreSQL and Redis inside Kubernetes is not supported.
- Disaster recovery effort: GitLab Dedicated includes high availability with disaster recovery and a 99.9% monthly availability objective, so compare that against the Geo, backup and failover work your team would own.
- Tooling continuity: you keep control of the Patroni version, PostgreSQL version and GitLab upgrade sequence in one change calendar.
- Skills risk: a Kubernetes outage or a misconfigured Patroni cluster now affects source control directly, so staff coverage and on-call rotation need to be part of the decision.
Confirm with GitLab which reference architecture matches your user count and request rate before sizing the Patroni and Gitaly tiers.
This profile fits a team whose standard platform is Azure, Google Cloud, or a mix of providers, or whose regulators or customers require a specific cloud footprint that excludes AWS. GitLab Dedicated is deployed on AWS only, and GCP and Azure deployments are not supported, so Dedicated is not an option for this team. Self-managed GitLab can run in any environment the team operates, including on-premises and multiple clouds, at the cost of running the platform itself.
- Placement freedom: you deploy GitLab into the provider and regions your governance already approves, using the installation method that fits your platform.
- Installation choice: the Linux package, Helm chart, GitLab Operator, Docker or source install are all available, so match the method to your team's skills.
- Storage and database dependencies: the Helm chart and high availability designs need external PostgreSQL, Redis and object storage that you provision in that cloud.
- Cost structure: you pay the cloud provider for infrastructure and carry the internal effort, while Dedicated would bundle hosting and operations into a custom-priced subscription.
- Portability: a self-managed instance can move between providers with a backup and restore, which is harder to plan when a hosted subscription ends.
Ask GitLab for a written statement of current cloud support before ruling Dedicated in or out, since availability by provider can change.
What your team runs in each model
This table lists the operating tasks that keep a GitLab instance healthy and shows who performs each one in GitLab Dedicated and in a self-managed installation. Read each row as a handover question: if the cell says GitLab, your team confirms the outcome and the schedule, and if it says your team, you staff and schedule the work. Staffing levels are not supplied here, so confirm them against your own environment before deciding.
| Operating task | GitLab Dedicated | GitLab self-managed |
|---|---|---|
| Version upgrades and required upgrade stops | GitLab operates the service and its upgrade schedule; confirm the change windows and notice you receive | Your team plans each path through required stops such as x.2, x.5, x.8 and x.11 per GitLab's upgrade paths documentation |
| Monthly minor and patch releases | GitLab applies releases to the managed service; confirm how your change approval fits the cadence | Your team tracks the third-Thursday minor release and twice-monthly patches, then tests and applies them. Security fixes reach the previous two monthly releases, per the maintenance policy |
| Backup and restore | GitLab runs backups as part of the managed service; confirm retention, restore testing and who requests a restore | Your team designs, schedules, tests and restores backups using GitLab's backup and restore documentation |
| High availability design | GitLab designs and runs high availability, which the Dedicated docs include; confirm the topology you are buying | Your team chooses and builds the architecture. GitLab generally recommends high availability for 3,000 or more users, with Gitaly Cluster, Patroni, Redis Sentinel and Consul |
| Disaster recovery | Included in the Dedicated offering per GitLab's docs; confirm recovery objectives in your contract | Your team designs and tests recovery, including any Geo setup. Confirm the recovery objectives you need |
| Identity configuration | Your team configures SAML or OIDC SSO and push rules or webhooks, since LDAP, Kerberos and server-side Git hooks are unavailable | Your team configures identity, including LDAP, smart card and Kerberos where your policy requires them |
| Security hardening | GitLab hardens the managed environment, and engineers do not have direct access to customer environments; confirm your own configuration responsibilities | Your team applies GitLab's hardening recommendations to the host, database, network and application layers |
| Offline and air-gapped updates | Not applicable to the SaaS model; confirm whether your network rules allow a connected service | Your team stages packages and images in an offline environment using GitLab's offline guidance |
| Availability monitoring | GitLab targets a monthly 99.9% availability objective; confirm how status reporting and incident notices reach your team | Your team builds monitoring, alerting and on-call for the instance and its dependencies |
| Staffing and on-call effort | Confirm with GitLab the internal roles you still need for approvals, access requests and incident coordination | Confirm your own platform staffing needs, since they depend on user count, architecture and on-call expectations |
What drives cost in each model and what to ask for in a quote
The two models spread cost across different payees, so compare them on who is paid for what rather than on a headline number. GitLab Dedicated has no public price on the GitLab pricing page, so the figure comes from a written quote from GitLab. With self-managed GitLab, the subscription is a separate line: Free costs 0 US dollars, Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced. Those subscription fees are only part of the bill. Your team also pays for the servers or cloud accounts that host GitLab, the PostgreSQL, Redis and object storage it depends on, backup storage, staff time for upgrades, and the planned upgrade stops GitLab requires. Under Dedicated, much of that operating work moves to GitLab, but you still carry the internal effort of identity integration, access reviews and user onboarding.
Separate what is one-time from what recurs. Migration, initial configuration, SSO setup, and any move of projects and pipelines are one-time costs in either model. Subscription fees, hosting, storage, monitoring and staff time for upgrades recur every year. Ask for each recurring element as an annual figure and keep the user count explicit, because per-user pricing scales with headcount and Premium is quoted per user. Cost rises with the number of users, the chosen region, the support level, the amount of data retained, and any added services such as a customer-managed AWS KMS key for data at rest. Ask GitLab to state whether that key is included or priced separately.
Before signing, request a quote that states the scope of the instance, the AWS region, the expected user count, the support level and the availability commitment, along with the exit terms. Check what happens after a subscription expires: access continues for 30 days, after which the instance is terminated and content is deleted unless it has been archived or migrated, so the exit plan and the cost of a migration should be priced into the decision. Confirm whether GitLab Dedicated for Government is relevant to your compliance requirements, and ask for the same terms in writing for any self-managed option you compare. DeployOpen scopes its own fixed-scope work from a written brief, so request the work breakdown as a separate, comparable document.
How to move between self-managed GitLab and Dedicated
The sequence below takes a team from one GitLab deployment to the other with feature parity, identity, repositories, hooks, cutover and backups all confirmed before the source is retired. Scope, effort and timing depend on instance size and integrations, so confirm them in writing before work starts.
Confirm feature parity against the Ultimate exceptions
Start by listing every GitLab feature your instance uses today and checking it against the features Dedicated does not offer. Dedicated uses the Self-Managed Ultimate feature set with listed exceptions, so the exceptions are the main risk. Include LDAP, smart card and Kerberos authentication, SSH certificate authentication, reply by email, Service Desk and server-side Git hooks. Confirm the current exception list with GitLab in writing, because it can change. The output is a signed-off gap register that names each affected feature, the team that uses it and the replacement or accepted loss.
Plan the identity change to SAML or OIDC
If your self-managed instance authenticates through LDAP or Kerberos, plan the move to SAML or OIDC single sign-on before any data moves. Map every group and role that currently drives access, including LDAP group sync if it is in use, to identity provider groups. Decide how existing accounts will be matched to new identities and who approves that mapping. Test sign-in with a pilot group and confirm that deprovisioning works. The output is a tested identity mapping and a documented fallback path for administrators.
Rework server-side Git hooks into push rules or webhooks
Inventory every server-side Git hook and any custom check that runs on push. Dedicated does not offer server-side Git hooks, so rebuild each check with push rules where the rule fits, or with webhooks that call a service you operate. Record which checks now run later in the pipeline, which may change when a developer sees a failure. Test each replacement against a sample push that should be rejected and one that should pass. The output is a replacement table with a test result for every hook.
Export or migrate projects and groups
Choose the transfer method for groups, projects, merge requests, issues, CI variables and container or package registries. GitLab's import and migrate documentation describes the supported paths, and each one has different limits, so test the method on a representative group first. Record the group structure, member roles and repository sizes before transfer. Ask GitLab to confirm in writing which data types move and which must be rebuilt. The output is a migration test report that lists object counts before and after, with mismatches explained.
Validate backups before cutover
Take a full backup on the source instance and restore it into a separate environment to confirm it is usable. For self-managed GitLab, use the backup and restore procedure for the installation method in use. For Dedicated, confirm with GitLab how backups and restores are handled and what the customer can verify. Check that repositories, the database and object storage content all restore and that the restored copy starts and serves a test project. The output is a restore record signed by the operations owner, with the date and the scope of what was verified.
Schedule cutover and rehearse the switch
Agree a cutover window with the teams that depend on GitLab, including CI runners, webhooks, integrations and any deploy tooling that points at repository URLs. Rehearse the full switch on a copy of the data, including DNS changes, runner re-registration and certificate or SSO updates. Freeze writes on the source during the final sync, then run a final migration pass. Confirm that CI pipelines run on the target before anyone is told the move is complete. The output is a written cutover runbook with a named owner for each step and a rollback decision point.
Retire the source only after acceptance
Keep the source instance read-only and reachable for a period agreed in advance, so the team can check any data that was missed. Confirm acceptance with each team that owns a group or integration. For a move away from Dedicated, note that when a subscription expires, access continues for 30 days before the instance is terminated and content is deleted unless it has been archived or migrated, so plan the exit before that window. Record the final backup location and retention, then decommission. The output is a closure record with acceptance sign-offs and the location of the archived final backup.
What happens to your data when a Dedicated subscription ends
When a GitLab Dedicated subscription expires, access continues for 30 days, after which the instance is terminated and customer content is deleted unless you have archived or migrated it. That deadline is the single most important date in your exit plan, and it runs on the vendor's side of the contract, not yours. Before you sign, ask for the expiry, notice and termination terms in writing and confirm how the 30-day window is counted, whether it applies to renewals, and whether the content deletion is documented as final. Write the exit plan into the contract itself: who initiates the archive or migration, which formats are delivered, and what support is included during the window.
Decide the archive or migration path well before day 30. Check whether your target is another GitLab instance you run, a different forge, or a mix, and confirm what each route carries over: repositories, merge requests, CI configuration, container and package registries, and attachments. Ask GitLab which backup or export methods apply to a Dedicated tenant, since you cannot run the self-managed backup tooling against a host you do not control. Then rehearse the export on a non-production copy and time it against your largest repository set. A rehearsal that fails in week one is far cheaper than a failure in the final week of the window, and the results will tell you how much of the 30 days you actually need.
Self-managed GitLab works differently because you hold the server, the database and the backups. Your retention rules, backup schedule and deletion decisions apply regardless of GitLab subscription status, so a lapsed license does not remove your data from your disks. The limit is on features, not content: paid capabilities on self-managed still depend on the subscription, and an expired Premium or Ultimate license changes what the instance can do. Confirm with GitLab how the license behaves on expiry for your edition, and keep a documented procedure for the change so that compliance records, retention periods and legal holds stay enforceable after any subscription change.
Questions buyers ask about GitLab Dedicated vs self-managed GitLab
Why is GitLab Dedicated quoted instead of listed with a price?
GitLab Dedicated has no public price on the GitLab pricing page, so the number comes from a quote built on your requirements. The cost drivers are the size of the user base, the region and AWS footprint GitLab operates for you, the high availability and disaster recovery posture included in the service, and the support terms you select. Self-managed GitLab splits cost differently: 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. Ask GitLab for a Dedicated quote that states what is included, what is excluded, and how renewals and user growth are priced. Compare it with a self-managed total that includes subscription, infrastructure, backups, upgrades and staff time.
How long does a move to GitLab Dedicated or self-managed GitLab take?
No duration is supplied for either path, so treat any timeline as something to confirm in writing. The main drivers are the volume of repositories and LFS data to migrate, how many CI/CD pipelines and integrations depend on the current system, how many authentication methods must be replaced, and whether your environment is air-gapped. Dedicated removes the infrastructure build but still requires SSO configuration, pipeline rework and cutover planning. Self-managed work adds platform build, high availability design and hardening. DeployOpen plans and implements these engagements under a fixed scope with deliverables and timelines agreed in writing before work starts, so ask for the scope and timeline in that form.
What does the internal team need to provide during the project?
Both models need named owners for identity, networking, the data migration plan and the decision on who approves cutover. Dedicated shifts day-to-day platform operations to GitLab, but your team still owns SSO integration with your identity provider, project and group structure, pipeline definitions, runner strategy for jobs you run yourselves, and the internal policies that map to your controls. Self-managed GitLab also needs people for patching on the monthly and security release cadence, upgrade stops, backup and restore testing, and monitoring. Before starting, confirm the roles, approval steps and time commitments your staff can give, and write them into the scope.
Can a team run self-managed GitLab without outside help?
Yes, many teams do, and GitLab documents several installation methods, including the Linux package, the Helm chart, the GitLab Operator, Docker and source installs. The Linux package is described as the most mature, scalable method. The harder part is operations: GitLab ships a minor release monthly, requires upgrades to pass through required upgrade stops such as 19.5, 19.8 and 19.11 after 17.5, and recommends a high availability strategy for 3,000 or more users with Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul. Ask whether your team has the skills and on-call capacity to run that stack, and whether a retainer or fixed-scope project would cover the gaps.
Can GitLab Dedicated run on GCP or Azure?
No. GitLab Dedicated is deployed on AWS in a region of the customer's choice, and GCP and Azure deployments are not supported according to the GitLab Dedicated documentation. If your landing zone, data residency rules or contracts require Google Cloud or Azure, self-managed GitLab inside that environment is the path to evaluate, or a Dedicated deployment on AWS if that meets your rules. Confirm the AWS region list and any government hosting option directly with GitLab, since the pricing page also lists GitLab Dedicated for Government with FedRAMP-compliant hosting.
What happens to our data when a GitLab Dedicated subscription expires?
Access continues for 30 days after a GitLab Dedicated subscription expires. After that the instance is terminated and customer content is deleted unless it has been archived or migrated, according to the GitLab Dedicated documentation. Treat the 30-day window as the deadline for your exit plan, not as a grace period for planning. Before renewal, export or migrate repositories, issues, packages, registry content and audit records you must keep, and test the destination. Self-managed GitLab avoids this cliff because you hold the data, but you still need a tested backup and restore process. Ask GitLab in writing what export formats and assistance exist at exit.
Can DeployOpen help with GitLab Dedicated or self-managed GitLab?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including self-managed GitLab in your cloud accounts, data centers or air-gapped networks. For that model, work is usually fixed-scope, and ongoing upgrades and support are available as retainers. DeployOpen is not GitLab's service operator, so for GitLab Dedicated the hosted service is run by GitLab, and DeployOpen can help with the surrounding work such as identity integration, migration planning, pipeline rework and evidence preparation for your assessments. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes, delivers and supports self-hosted GitLab
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For GitLab Dedicated vs GitLab self-managed, we start from a written scope that states which path fits your region, identity, key and data requirements before any work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm your required region, data residency, key control and tier needs before choosing between the hosted and self-managed paths.
- We list which authentication methods, Git hooks and integrations your teams depend on, then check them against the features each option supports.
How we build
- For self-managed GitLab, we plan the installation method, PostgreSQL, Redis and object storage layout, and any high availability design you need.
- Where air-gapped or offline operation is required, we plan how packages, updates and scanner content reach the environment.
- We test backup and restore procedures in your environment and document the results before go-live.
How we hand over
- You receive configuration, architecture and runbook documentation covering upgrades, backups and access controls.
- Upgrade planning follows the required upgrade stops that GitLab publishes, so your team knows which versions to pass through.
- We walk your administrators through daily operations and record the controls and evidence your compliance assessors will ask for.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope, response expectations and service levels are agreed in writing, so confirm them against your own requirements.
- Compliance work stays on the preparation side: we prepare systems, controls and evidence, while independent auditors issue any formal assessment.
