The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | plan |
| Maturity | Complete |
| Content Last Reviewed | 2023-11-08 |
Thank you for visiting the Pages direction page for GitLab. 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. This category belongs to the Knowledge group within Plan stage. This direction page is maintained by Product Manager for Knowledge group, Matthew Macfarlane (E-Mail). More information about Knowledge group's priorities can be found on the Knowledge group direction page.
This direction page is a work in progress, and everyone can contribute:
GitLab Pages is a popular feature that exists at the intersection of multiple stages of the DevSecOps lifecycle. The long-term vision for Pages is to provide an experience that guides and supports you through Create, Verify, Package, and Release to host static assets on the web, regardless of your level of development experience.
We are currently, as of 2023-11-08, prioritizing Multiple-version Pages support and Pages without DNS wildcard. We believe these two priorities are critical in improving user experience and workflow related to GitLab Pages. Down the line we'll evaluate bigger opportunities such as making content management and collaboration easier for non-developer personas.
A future state of Pages could be described as a lightweight content management system (CMS), abstracting away the repository and git terminology in favor of WYSIWYG editing and more accessible publishing workflows. Netlify, TinaCMS, and Stackbit have successfully bridged the gap between git-backed repositories of static assets and visual editing workflows accessible to all. The ideal user journey may look something like:
main.main, triggering another Pages deploy.This category is currently at the "Complete" maturity level, and our next maturity target is "Lovable" (see our definitions of maturity levels). The key features and deliverables necessary to promote Pages are captured in the Lovable Maturity epic.
However, the assessment of this maturity level was made prior to our new process for measuring maturity. We will be conducting a category maturity assessment to validate the current maturity level and understand more about what is necessary to get it to the next level. Our goal is to conduct this measurement in FY25, depending upon our available capacity and priorities.
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, deliver a more comprehensive solution. There are project templates available that offer the use of Netlify for static site CI/CD, while also still taking advantage of GitLab for repository, merge requests, issues, and everything else. GitLab offers configurable redirects, a well-loved featured of Netlify, made available in Add simple redirect configuration.
We are seeing a rise in JAMStack 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.
GitHub also offers hosting of static sites with GitHub Pages. Key differentiators between the two are:
The most popular customer issues are:
GitLab dogfoods GitLab Pages extensively, most prominently as the hosting platform for docs.gitlab.com. Our top internal customer issue is Multiple-version Pages support, which we are currently addressing. Review Apps for GitLab Pages is another important feature for internal usage as the GitLab Internal Handbook is hosted on Pages and would benefit from having Review Apps integrated with the MR workflow.
Adding Review Apps for Pages 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 and allow easy to set up Pages from the UI without expanding APIs. Lastly, in combination with feature flags, Pages can be used to support A/B testing.