GitLab Pages on self-managed GitLab

Running GitLab Pages on self-managed GitLab

GitLab Pages on a self-managed instance publishes static sites built from GitLab projects onto infrastructure you control, so teams can host documentation, reports and internal sites without an external hosting service. You need it when project owners want their build output served under your own domain, with your own access rules, rather than from a public host. The Pages feature is not just a setting in GitLab itself: it runs as a separate Pages daemon that serves the published content, and that daemon has its own DNS, TLS and storage decisions that must be made before anyone publishes a site.

The first decision is the domain model. Self-managed GitLab Pages normally expects a wildcard DNS record on a domain that is not a subdomain of your GitLab domain, so each project can get its own host name. If you cannot dedicate a domain that way, the alternative is path mode, where sites are served as paths under one domain using namespace_in_path. Confirm which model your DNS team can support, because new sites use unique domain URLs by default, and changing the model later affects every published URL. Custom domains with TLS also need a secondary IP address for the Pages daemon, so network and load balancer planning belongs in the same review.

Access control is the second decision. Pages can be restricted to users who sign in to your instance through the gitlab_pages['access_control'] setting, which should be checked against the visibility levels your teams already use for projects. Existing deployments that store Pages content on local disk can be moved to object storage with the gitlab:pages:deployments:migrate_to_object_storage Rake task, so plan the bucket, its access policy and a test migration on a non-production instance before you change the storage backend. Ask your GitLab administrator to confirm the exact configuration keys for your installed version in the GitLab Pages administration docs.

Choosing wildcard DNS, path mode or unique domains

Self-managed GitLab Pages can address sites in three ways, and each one sets your DNS records, certificate scope and user-facing URLs. Pick the addressing model before you configure the Pages daemon, because changing it later affects every published site. The cards below cover the default wildcard DNS model, path mode under one domain, unique domain URLs for new sites and the checks to run in your own environment.

Wildcard DNS on a separate domain

Normal self-managed Pages setup uses a wildcard DNS record on a domain that is not a subdomain of your GitLab domain. Each project site then gets its own hostname under that wildcard, so one DNS entry covers many sites. The domain must be separate because browsers treat Pages content as untrusted and isolating it from the GitLab origin is the point. Confirm with your DNS team that the wildcard record resolves to the Pages address and that your certificate covers the wildcard name.

Path mode under one domain

With namespace_in_path enabled, sites are served as paths under a single Pages domain rather than as separate hostnames. This removes the need for a wildcard DNS record and wildcard certificate, which simplifies environments where wildcard DNS is hard to get approved. The trade-off is that sites share one origin and one hostname, so review how your organization handles cookies and isolation for published content. Confirm the exact configuration key and behavior with the current documentation for your version.

Unique domain URLs for new sites

Unique domain URLs give each Pages site its own generated hostname and are the default for new sites. They suit teams that publish many independent sites and want clean URLs without path prefixes. Each site still resolves through the Pages domain, so the DNS and certificate design from the wildcard model still applies. Check whether existing sites migrated under older settings keep their current URLs before you change anything.

Certificate scope and wildcard TLS

The addressing model determines what your certificate must cover. Wildcard hostnames need a certificate that matches the Pages domain pattern, while path mode may need only the single Pages hostname. Decide early whether your certificate authority issues wildcard certificates, how renewal runs and who owns the private key. Confirm certificate handling with your security team and your certificate provider, since the supported options depend on your environment.

Custom domains and the secondary IP

Custom domains with TLS, which let a project serve its own hostname, need a secondary IP for the Pages daemon. Plan that address alongside the wildcard or path design so that custom domain traffic does not collide with the primary Pages endpoint. Ask your network team whether an additional address can be allocated and routed on your load balancers and firewalls before you commit to a design.

Choosing the model for your organization

Choose wildcard DNS when you control the DNS zone and want clean isolation for many sites. Choose path mode when wildcard DNS or wildcard certificates are not available, and accept shared origin behavior. Choose unique domains as the URL style for new sites within whichever model you pick. Write the decision down with the DNS owner, the certificate owner and the security reviewer, since it is hard to reverse once sites are published.

Configuration options and when each fits

This table compares the main GitLab Pages settings on a self-managed instance, from DNS layout to access control, custom domains and storage. Read each row for the situation it suits and the trade-off it brings, then confirm the exact settings against the Pages administration documentation for your GitLab version.

Option	When it fits	Main trade-off
Wildcard DNS domain	You can dedicate a domain that is not a subdomain of the GitLab domain and create a wildcard DNS record for it.	Requires DNS control and a wildcard certificate plan before sites go live.
namespace_in_path	You want all Pages sites served as paths under one domain and cannot delegate a wildcard DNS record.	Site URLs carry the namespace, and some relative-path assumptions in static sites may need adjusting.
Unique domains	You want each new site to have its own hostname, which is the default for new sites.	Each site needs its own hostname resolution, so DNS and certificate handling grow with the number of sites.
Access control (gitlab_pages['access_control'])	Pages content should only be visible to people signed in to your GitLab instance, such as internal documentation or reports.	Access depends on GitLab sign-in, so confirm how it behaves with your authentication setup and project visibility settings.
Custom domains with TLS	Teams need their own domain names for published sites, with HTTPS for each one.	Each custom domain needs certificate management, and you must confirm the TLS approach your organization accepts.
Secondary IP for the Pages daemon	You enable custom domains, because the Pages daemon needs a dedicated secondary IP address to serve them.	Adds an address to plan in your network, DNS and firewall rules before custom domains can be used.
Object storage for deployments	Deployment volume or availability needs push Pages content out of local disk, and you run an object store you control.	Requires an object storage service and a one-time migration with the gitlab:pages:deployments:migrate_to_object_storage Rake task; confirm the steps for your version.

Setup sequence for Pages with custom domains

This sequence takes a self-managed GitLab instance from a planned domain model to a working Pages setup in which project sites and custom domains are served over TLS. Each step ends with a check you can run before moving on.

Plan the domain model and DNS
Decide whether Pages will use a wildcard DNS record on a domain that is not a subdomain of your GitLab domain, or a single domain with sites served as paths through namespace_in_path. Decide whether new sites will use unique domain URLs, which is the default for new sites. Your DNS team creates the records and the network team confirms that the Pages domain resolves from the networks where visitors will be. Done when the planned records are written down and you can resolve a test hostname under the Pages domain from a client machine.
Configure the Pages domain and wildcard record
On the GitLab server, set the Pages domain and the external URL for Pages in the Linux package configuration file, gitlab.rb, using the keys listed in the GitLab Pages administration guide. Then run a reconfigure so the change takes effect. The wildcard record should point to the address the Pages daemon listens on. Done when a test project with a simple index page loads at its generated address over HTTP or HTTPS, and the reconfigure finishes without errors.
Enable access control if the sites need it
If some Pages sites must only be visible to signed-in users with project access, enable access control through gitlab_pages['access_control'] in gitlab.rb and reconfigure. Check that the Pages daemon is then reachable through the authentication flow your users will use. Done when a private project's site returns a sign-in prompt to an anonymous browser and loads for a member with access, and public sites still load anonymously.
Provision a secondary IP for the Pages daemon
Custom domains with TLS require the Pages daemon to listen on a secondary IP address on the host. Your infrastructure team allocates that address, adds it to the network interface or load balancer, and opens the required ports to the public side. Confirm the exact configuration keys in the administration guide before editing gitlab.rb. Done when the secondary address answers on the expected ports from outside the host and the Pages service reports healthy after a reconfigure.
Configure TLS or Let's Encrypt for custom domains
Choose between a certificate you supply and a certificate issued through Let's Encrypt. For supplied certificates, install the certificate and key where the Pages configuration expects them. For Let's Encrypt, confirm that the instance can reach the validation endpoint from the public internet, since an air-gapped or restricted network may not allow this. Check the administration guide for the current keys and any required settings. Done when the Pages daemon reports a valid certificate for the test domain and the certificate chain is trusted by a standard client.
Add and verify a custom domain
In a test project, add a custom domain under Settings and Pages, then create the verification record that GitLab shows and upload the certificate if you are not using automatic issuance. Your DNS team adds the records and the project owner confirms the domain status. Done when the domain shows as verified and an HTTPS request to the custom domain returns the test project's content with a certificate that matches the domain name.
Test a project site and a custom domain together
Run a final test with at least one project site on the generated domain and one custom domain, from a browser on the internal network and one outside it if visitors will reach the site from outside. Check that access control behaves as planned, that redirects and assets load, and that a fresh deployment appears after a pipeline runs. Record the results and the configuration version so later upgrades can be checked against them. Done when all test cases pass and the results are stored with your change records.

How custom domains and TLS change the network plan

Custom domains with TLS change the network plan because the Pages daemon needs its own secondary IP address on the GitLab Pages host. Unique domain and wildcard sites are served from the main Pages address, but a custom domain is a separate hostname that the client reaches directly, and the instance must be able to present a certificate for it on the correct address. Plan that IP before the first custom domain is added, record it in your IP allocation, and confirm with your network team that the host, its interface and any load balancer in front of it can carry it. Keep the wildcard DNS record for the Pages domain in mind as well, since it must resolve to the same Pages front door that serves your custom domains.

Your certificate choice decides who owns renewal. With supplied certificates, your certificate authority process, key storage and renewal calendar sit with your team, and every custom domain needs its certificate and key uploaded and replaced on time. With Let's Encrypt, the instance requests and renews certificates automatically, which shifts the operational risk to the outbound HTTP challenge path, the DNS records and the continued reachability of the Pages address from the internet. Confirm which option your security policy allows, whether your environment can reach the Let's Encrypt service at all, and who is paged when a renewal fails. Offline or restricted networks usually rule out the automated option.

Before you commit to a design, confirm three things outside GitLab. First, that your load balancer or reverse proxy passes TLS traffic for custom domains through to the Pages address without terminating it in a way the instance cannot manage. Second, that firewall rules allow inbound connections on the Pages ports from the networks your visitors use, and that outbound access exists for any challenge or validation traffic you rely on. Third, that public DNS for each custom domain can be changed by the team that will own it, with a documented owner for CNAME or A records. Ask your implementation partner to put these checks in the written scope, because each one lives in a team that is not the GitLab administrator's.

Moving existing Pages deployments to object storage

This sequence moves Pages content that already sits on the instance's local disk into object storage, so sites keep serving from a store that is separate from the GitLab server. It starts with a verified backup and ends with a check that every migrated site still loads.

Confirm object storage is reachable
Before touching configuration, the administrator confirms that the object storage bucket or endpoint exists, that the credentials have read and write access to it, and that the GitLab server can reach it over the network path the instance will use. Run a simple write and read test from the GitLab host using the same credentials. The step is done when the test object is written, read back and deleted without errors, and the administrator has recorded the bucket name and endpoint for the next step.
Take and check a backup
The administrator takes a full GitLab backup with the backup and restore procedure and copies the configuration and secrets files, including gitlab-secrets.json and gitlab.rb, to a separate location. The backup should be restored to a test host or confirmed as readable before the move, because the migration changes where Pages content is stored. This step closes when the backup archive and secrets are stored off the instance and the administrator has confirmed the archive can be listed or restored in a test environment.
Configure object storage for Pages
The administrator adds the Pages object storage settings in gitlab.rb, using the bucket, credentials and endpoint confirmed earlier, and then runs gitlab-ctl reconfigure. The configuration keys are documented in the GitLab Pages administration guide, and the team should confirm the exact key names for the installed version before editing. The step is complete when reconfigure finishes without errors and the Pages service restarts cleanly.
Run the migration Rake task
The administrator runs the gitlab:pages:deployments:migrate_to_object_storage Rake task from the GitLab host, which copies existing Pages deployments from local storage into the configured bucket. Run the task first in a non-production window or on a test instance if one exists, and capture the output log for the change record. The step is done when the task reports that all existing deployments were migrated, with no failed entries left in the output.
Verify sites still serve
The administrator loads a sample of Pages sites, including one with a custom domain, one using unique domain URLs and one behind access control if that is enabled. The team checks that content, redirects and TLS certificates behave as before and that the bucket contains the expected deployment objects. The step is done when the sample sites return the expected content and the object count in the bucket matches the migrated deployments reported by the task.
Plan the rollback path
Before declaring the move complete, the administrator documents how to return Pages to local storage if sites fail to serve. This includes the saved configuration from before the change, the restored backup point and the decision owner who can authorize a rollback. The team should confirm with the vendor documentation whether migrated content can be copied back to local disk and what the procedure requires for the installed version. The step is done when the rollback steps are written, reviewed and stored with the change record.
Keep the backup and monitor after cutover
After the sites are verified, the administrator keeps the pre-move backup for the retention period set by the organization and watches Pages logs and user reports for a defined window agreed in advance. The team also updates backup scope so that the new object storage location is included in future backup and disaster recovery planning. The step closes when the monitoring period ends without incidents and the backup and storage documentation reflects the new location.

Security risks of publishing sites from GitLab

GitLab Pages turns repository content into web sites, so its settings decide who can read what and which hostnames and certificates you trust. The cards below cover the decisions that carry the most risk on a self-managed instance, from access control to the hardening baseline the Pages configuration should inherit.

Private sites need access control

Pages sites can be published for anyone, for members of a project, or behind the instance's own sign-in. On self-managed GitLab, access control is switched on with the gitlab_pages['access_control'] setting in gitlab.rb. Before you publish internal documentation, reports or dashboards, confirm that the setting is enabled, then test a site from a logged-out browser and from a user outside the project. A site that looks private in the project settings can still be public if the Pages access rule was never applied.

Wildcard DNS widens the surface

Normal self-managed Pages setups use a wildcard DNS record, so every new project site gets a hostname under one domain. That record is a standing grant: anyone who can create a project can create a site name, and a stale or misdirected record can send traffic to the wrong place. Plan the Pages domain as its own zone that is not a subdomain of the GitLab domain, and ask who controls DNS changes for it.

Certificate scope follows the domain

A wildcard certificate or a custom domain certificate covers every hostname it names, so a broad certificate can be used on sites you did not intend to expose. Custom domains with TLS also need a dedicated secondary IP for the Pages daemon. Check which names each certificate covers, who holds the private key, and how renewal is handled before you add a customer or internal domain to Pages.

Public Pages can expose internal content

Build artifacts often contain more than the page a team meant to publish, including internal hostnames, configuration examples, test data or generated reports. A project that moves from private to public visibility can change what is reachable through Pages without any change to the site itself. Review the artifact contents of each job that deploys Pages, and restrict who can change project visibility and Pages settings.

Pages must follow the hardening baseline

Pages settings sit alongside the instance controls covered in GitLab's hardening guidance: application settings, CI/CD, configuration files such as gitlab.rb, and the operating system. Pages deployments are produced by CI/CD jobs, so the runners and protected branches that build them count as part of the Pages attack surface. Map each Pages setting to the baseline your organization already uses, and roll changes out gradually because GitLab describes that guidance as a work in progress.

Questions teams ask before running GitLab Pages

How much effort does a GitLab Pages setup take, and what drives it?

The effort depends mostly on which addressing model you choose and how many of the optional features you need. A single wildcard DNS setup with unique domains and no custom domains is the smallest case. Effort rises with each addition: access control, custom domains with TLS, a secondary IP for the Pages daemon, and the move of existing deployments to object storage. Ask any partner for a written scope that lists each of these items separately, because each one has its own testing and rollback steps. Duration and price follow from that list, not from the feature name alone.

Can our internal team set up GitLab Pages without a partner?

Often yes, if your team already runs self-managed GitLab and controls its DNS zone and TLS certificates. The core work is editing gitlab.rb settings, reconfiguring the instance and verifying that sites resolve and load. The harder parts are DNS delegation for a domain that is not a subdomain of your GitLab domain, certificate handling for custom domains, and testing access control across projects. Check whether your team has done a reconfigure and a rollback on a production instance before you start. A partner is most useful when the scope includes custom domains or a storage migration that must not disturb live sites.

What does the setup need from our DNS, certificate and network teams?

Plan for four inputs before the build begins:

A wildcard DNS record on a domain that is not a subdomain of your GitLab domain, or a single-domain plan for path-based sites.
A certificate and key for each custom domain, or a Let's Encrypt setup that your network allows the instance to reach.
A secondary IP address for the Pages daemon when custom domains use TLS.
Object storage credentials and a bucket if you plan to move deployments off local disk.

Confirm with your network and security teams which of these they can provision, and how long their change process takes. Those approvals often set the calendar more than the GitLab work does.

Will moving GitLab Pages deployments to object storage take sites offline?

The migration is designed to run against existing deployments using the gitlab:pages:deployments:migrate_to_object_storage Rake task, so the impact depends on how you run it and what you test first. Before the move, confirm the object storage configuration, run the task in a non-production instance with a copy of your data, and check that sample sites still load after the move. Schedule the production run for a window you have agreed with the teams that publish sites, and keep the local deployment files until you have verified the result. Ask your partner to document the rollback path in writing.

What changes for GitLab Pages when we upgrade GitLab?

Pages is part of the same instance, so each GitLab upgrade can change its configuration, templates or behavior. Follow the required upgrade stops rather than jumping versions, since GitLab requires upgrades to pass through them, and review the release notes for Pages-related settings. Bug fixes are backported only to the current stable release, while security fixes also reach the previous two monthly releases, so plan to move to a supported version on a steady cadence. Re-run your access control and custom domain tests after each upgrade, because a configuration change can affect them without any visible error.

What recurring work does GitLab Pages add to our operations?

Once live, Pages adds recurring work in three areas: certificate renewal for custom domains, DNS and secondary IP records that must stay correct, and storage capacity and backups for deployments held in object storage. Each of these should have a named owner and an alert or checklist item. Ask any partner whether ongoing support is included in the fixed scope or offered as a separate retainer, and ask what they will monitor on your behalf. Confirm your own backup procedure covers Pages data as well as the repositories.

Does access control for GitLab Pages depend on our identity setup?

Access control for Pages is enabled through the gitlab_pages['access_control'] setting, which restricts who can view a site. Whether it fits your model depends on how your users sign in to GitLab and which projects need restricted sites. Test with a user who has access and one who does not, across both unique domain and path-based sites. Confirm the behavior with your GitLab version's documentation before you rely on it for sensitive content, because access rules that look correct in one addressing mode can differ in the other.

Limits to confirm in your environment

GitLab Pages depends on several layers outside the GitLab application itself: the release you run, your DNS provider, your certificate policy, your network path and your storage backend. Each layer can block a working Pages setup, so confirm them in writing before you choose a design. The cards below list what to check and where to check it.

Version compatibility for your release

Pages behavior, configuration keys and the object storage migration task can change between GitLab releases. Your instance runs one current or maintained release, and the upgrade stops you must pass through set the versions you can reach. Confirm the Pages settings you plan to use against the documentation for your exact version, and check that your target release is one of the stops on the upgrade path before you commit to a configuration.

Wildcard DNS behavior at your provider

Default Pages hosting relies on a wildcard DNS record on a domain that is not a subdomain of your GitLab domain. Not every DNS provider handles wildcard records the same way, especially where other records already exist under the same zone. Ask your DNS team whether the wildcard resolves for every unique domain name, how it interacts with existing records, and whether your provider's API or change process can support it.

Certificate authority policy

Custom domains with TLS need certificates, and your certificate authority decides whether you can use Let's Encrypt or must buy and renew certificates through an internal or commercial process. Confirm whether your environment allows automated issuance, how wildcard and per-domain certificates are approved, who holds the renewal duty and where private keys are stored. A missed renewal takes customer-facing Pages sites offline.

Network path to the secondary IP

Custom domains with TLS require a secondary IP address for the Pages daemon. Confirm with your network team that this address is routable from the internet or from the user networks that need access, that load balancers and firewalls forward ports 80 and 443 to it, and that internal clients can resolve the same names. Document the path so that a firewall change does not silently break every custom domain.

Object storage compatibility

Moving deployments to object storage is done with the gitlab:pages:deployments:migrate_to_object_storage Rake task on existing installations. Confirm that your object storage service is compatible with the GitLab object storage configuration you use, that the bucket and credentials are in place before the migration, and that your backup plan covers the bucket as well as the database. Ask the storage team who owns retention and access policy.

Install method support for the configuration

Your install method determines how Pages settings such as access control and the secondary IP are applied. The Linux package, the Helm chart, the GitLab Operator, Docker and source installs have different configuration paths and different levels of documented support. Confirm with the install method documentation that the setting you need exists for your method, and test the configuration in a non-production instance before you apply it to production.

Keeping Pages running through upgrades and backups

Pages sits outside the main GitLab upgrade path in ways that are easy to miss. Its behavior depends on gitlab.rb settings such as gitlab_pages['access_control'], on a wildcard DNS record that points at the Pages daemon, on a secondary IP address when custom domains use TLS, and on where deployment archives are stored. A GitLab upgrade can succeed for the core application while Pages quietly stops serving sites, redirects break, or certificates fail to renew. For that reason, each required upgrade stop needs its own Pages regression test before it goes to production. Build the test on a staging instance that mirrors your production DNS and storage layout as closely as you can, then publish a known test site, a site behind access control, and a custom domain with TLS, and confirm each one after every step of the upgrade path.

Backups need the same scope check. Deployment content and the Pages configuration are not always captured the way a team assumes, so before relying on a backup, confirm exactly what the GitLab backup and restore documentation covers in your version. Pay particular attention to the gitlab-secrets.json file and the configuration files, since a restore without them can leave Pages unable to decrypt or serve what was restored. If you have moved deployments to object storage, confirm whether your backup captures the bucket contents or only references to them, and who owns the bucket lifecycle and versioning rules. Record the answers in your runbook.

Test restores, not just backup jobs. Restore a backup into an isolated environment, then check that Pages deployments, access control and custom domain certificates all behave as they did before. Repeat the test whenever you change storage, DNS or the Pages secondary IP, and after each upgrade stop. Confirm with your GitLab support channel or your own testing which Pages items sit outside the standard backup, and plan separate exports for them. The effort of this work recurs with every upgrade stop, so ask any partner quoting this work to show how the regression suite and restore tests will be maintained.

What a DeployOpen Pages engagement covers

A Pages engagement usually follows one sequence: decide how sites are addressed, plan the DNS and certificates that serve them, then configure, test and hand the result to your operators. Each card below is a piece of that work that can be written into a fixed scope before any change is made. Scope, deliverables and timelines are agreed in writing before work starts.

Domain model design

The first decision is how published sites are addressed: unique domain URLs for each new site, or sites served as paths under one domain. This choice shapes every later step, including DNS, certificates and access rules. We document the naming scheme, which groups or projects may publish, and how existing sites will be handled. Ask us to confirm which addressing model your users will see before configuration begins.

DNS and wildcard records

Self-managed Pages normally relies on a wildcard DNS record on a domain that is not a subdomain of your GitLab domain. We plan the zone layout, record ownership and change process with your network team. We also check how the wildcard interacts with existing records so that internal services are not exposed by accident. Confirm who controls the DNS zone and how changes are approved.

Certificate and TLS planning

Custom domains with TLS need a dedicated secondary IP for the Pages daemon, so network allocation must be settled early. We map which certificate source you will use, whether an internal CA or Let's Encrypt, and how renewals are monitored. The plan covers ownership of private keys and what happens when a customer domain expires. Ask your network and PKI owners to confirm address space before the scope is signed.

Access control configuration

Pages access control is switched on through gitlab_pages['access_control'] in gitlab.rb, which decides whether published sites are visible to anyone or only to signed-in users. We design the policy for internal documentation, reports and prototypes, then test it with users from each group. The test plan checks anonymous access, project membership and redirects. Confirm which sites must stay private and who approves exceptions.

Object storage migration

Existing deployments can move their stored sites to object storage using the gitlab:pages:deployments:migrate_to_object_storage Rake task. We plan the bucket, credentials, rollout window and a rollback path, then run the task in a staging copy first. Verification compares site counts and sample page responses before production is changed. Ask for the storage backend and retention rules to be confirmed in the written scope.

Testing and handover documentation

We test each addressing, access and certificate case against the agreed plan, then write the runbook your operators will use. The handover covers configuration keys, renewal steps, the migration record and a list of known limits. Operators keep the documents and the test scripts after the engagement ends. Ask for the acceptance criteria to be listed in the scope so both sides agree on what done means.

How DeployOpen scopes and supports GitLab Pages

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including GitLab Pages on self-managed GitLab. Each engagement starts from a written scope that covers your domain model, access rules and TLS approach before any configuration changes are made.

How we scope

Confirm the DNS model first: wildcard records on a separate domain, or path mode under one domain.
Record which groups and projects need public, internal or private Pages access, and who approves changes.
Agree in writing whether custom domains, TLS certificates and object storage migration are in scope.

How we build

Configure unique domains, wildcard DNS and the Pages daemon in a staging instance before production.
Enable access control and test it against each group visibility setting used in your organization.
Plan the secondary IP for custom domains with TLS and run the deployment migration to object storage in a rehearsed window.

How we hand over

Deliver configuration, DNS records, certificate procedures and runbooks in documents your team can maintain.
Walk your administrators through custom domain onboarding and the steps for removing a deployed site.
Record backup coverage for Pages content so restores can be tested alongside the rest of the instance.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review Pages behavior with each GitLab upgrade, including required upgrade stops and changed defaults.
Ask any quote to list who does certificate renewal, DNS changes and object storage monitoring.