GitLab Pages allows you to create a statically generated website from your project that is automatically built using GitLab CI and hosted on our infrastructure.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
Pages is not strategically our most important Release feature, but it's a popular feature and one that people really enjoy engaging with as part of the GitLab experience; it's truly one of our most "personal" features in the Release stage. We do not plan to provide a market-leading solution for static web page hosting, but we do want to offer one that is capable for most basic needs, in particular for hosting static content and documentation that is a part of your software release.
Multiple version Pages support (gitlab#16208) is our most popular issue and one that is constantly being requested. It allows creating pages not only form the master branch but also on other branches as well.
This category is currently at the "Complete" maturity level, and our next maturity target is Lovable (see our definitions of maturity levels). Key deliverables to achieve this are:
Gitlab pages are offered as a service, but we do not position ourselves as a static site market leader. Other providers, such as Netlify provide a more comprehensive solution. There are project templates available in Gitlab that offer the use of Netlify for static site CI/CD, while also still taking advantage of GitLab for repos, merge requests, issues, and everything else. gitlab-ce#57785)
Our TAM team has identified gitlab#17584
The most popular customer issue is gitlab#17584. Creating Gitlab pages today requires admins to setup wildcard DNS records and SSL/TLS certificates. Some services and/or corporate security policies forbid wildcard DNS records, preventing users from benefitting from using Gitlab pages. This issue will remove the need for wildcard DNS and allow many more users to enjoy the pages experience. (GitLab Pages without DNS wildcard) as important for their customers.
Our top internal customer issue is gitlab#16208 which enables having multiple GitLab Pages generated based on branches or tags.
Our own docs team is considering moving to a different hosting provider; details on reasons why can be found at gitlab-docs#313. The main difficulty with using Pages at www-gitlab-com / GitLab documentation scale is:
From a vision standpoint, adding Review Apps for Pages (gitlab#16907) is interesting because it allows for more sophisticated development flows involving testing, where at the moment the only environment that GitLab understands is production. This would level up our ability for Pages to be a more mission-critical part of projects and groups.