--- layout: markdown_page title: "Category Direction - GitLab Pages" --- - TOC {:toc} ## GitLab Pages 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. - [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Category%3APages) - [Overall Vision](/direction/release) - [UX Research](https://gitlab.com/groups/gitlab-org/-/epics/594) - [Documentation](https://docs.gitlab.com/ee/user/project/pages/) ### Overall Prioritization 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. Popular issues and compelling blockers for our users hosting static content and documentation will be the top priority for Pages. ## What's Next & Why In order to improve Pages performance, we are working on changing the [Pages architecture](https://gitlab.com/groups/gitlab-org/-/epics/1316). Now that we have delivered the first improvement to speed up the initialization time with [gitlab#28782](https://gitlab.com/gitlab-org/gitlab/issues/28782) and are working toward serverless support for GitLab Pages via [gitlab#282](https://gitlab.com/gitlab-org/gitlab-pages/issues/282), we are planning to tackle the Object Storage re-architecture to support cloud native installations of GitLab Pages via [gitlab#39586](https://gitlab.com/gitlab-org/gitlab/issues/39586). Simultaneous to the re-architecture effort, we are making it easier to set up and manage domains of a Pages site in the Settings page via [gitlab&2403](https://gitlab.com/groups/gitlab-org/-/epics/2403). ## Maturity Plan This category is currently at the "Complete" maturity level, and our next maturity target is "Lovable" (see our [definitions of maturity levels](/direction/maturity/)). Key deliverables to achieve this are: - [Automatic certificate renewal](https://gitlab.com/gitlab-org/gitlab-foss/issues/28996) (Complete) - [Access controls for Pages on gitlab.com](https://gitlab.com/gitlab-org/gitlab/issues/25362) (Complete) - [Speed up Pages initialization time by using configuration API](https://gitlab.com/gitlab-org/gitlab/issues/28782) (Complete) - [Redirect from GitLab pages URL to custom domain when one exists](https://gitlab.com/gitlab-org/gitlab/issues/14243) - [Pages without DNS wildcard](https://gitlab.com/gitlab-org/gitlab/issues/17584) - [Per-site, in-repo configuration](https://gitlab.com/gitlab-org/gitlab-pages/issues/57) - [Multiple version support](https://gitlab.com/gitlab-org/gitlab/issues/16208) ## Competitive Landscape Gitlab Pages are offered as a service, but we do not position ourselves as a static site market leader. We are invested in supporting the process of developing and deploying code from a single place as a convenience for our users. Other providers, such as [Netlify](https://www.netlify.com/), provide a more comprehensive solution. There are project templates available that offer the use of [Netlify for static site CI/CD](https://gitlab.com/pages?filter=netlify), while also still taking advantage of GitLab for repos, merge requests, issues, and everything else. We are seeing a rise in [JAMStack](https://jamstack.org/) and static site generators partnering in the media. This trend toward API-first, affirms our modernization effort of Pages, reinforcing our cloud native installation maturity plan. ## Top Customer Issue(s) and Top Customer Success/Sales Issue(s) The most popular customer issue is [gitlab#17584](https://gitlab.com/gitlab-org/gitlab/issues/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. We are working on better supporting custom domains and will expect to have a path to redirect to custom domains ([gitlab#14243](https://gitlab.com/gitlab-org/gitlab/issues/14243)) following the Pages re-architecture effort. Our most popular issue for Pages, Multiple-version Pages support ([gitlab#16208](https://gitlab.com/gitlab-org/gitlab/issues/16208)) will also need to wait until the new architecture is in place, but we are working on an alternative solution of using environments for achieving the same functionality ([gitlab#33822](https://gitlab.com/gitlab-org/gitlab/issues/33822)). ## Top Internal Customer Issue(s) Our top internal customer issue is [gitlab#16208](https://gitlab.com/gitlab-org/gitlab/issues/16208) which enables having multiple GitLab Pages generated based on branches or tags. Our own docs team has been considering moving to a different hosting provider; details on reasons why can be found at [gitlab-docs#313](https://gitlab.com/gitlab-org/gitlab-docs/issues/313). ## Top Vision Item(s) Adding Review Apps for Pages ([gitlab#16907](https://gitlab.com/gitlab-org/gitlab/issues/16907)) will allow for more sophisticated development flows involving testing and review of Pages deployments. Enhancing the maturity of deployment would integrate Pages more critically within projects and groups. Another vision item being investigated is to leverage JAMstack for Pages. The primary goal would be to enhance the user experience ([gitlab#2179](https://gitlab.com/groups/gitlab-org/-/epics/2179)) and allow easy to set up Pages from the UI without expanding APIs. Lastly, in combination with [feature flags](/direction/release/feature_flags), Pages can be used to support A/B testing ([gitlab#14122](https://gitlab.com/gitlab-org/gitlab/issues/14122)).