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 | 2024-03-07 |
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 the 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 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.
As of 2024-03-07 we are prioritizing GitLab Pages Multiple Deployments and Pages without DNS wildcard. We recognize these two improvements as critical for improving Pages user experience. 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.Pages is currently at "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. Pages without DNS wildcard is one improvement we are tackling in the Lovable maturity designation.
Depending upon our available capacity and priorities we would like to conduct a category maturity assessment to further validate the current maturity level in FY25.
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 Pages extensively, most prominently as the hosting platform for docs.gitlab.com. Our top internal customer issue is GitLab Pages Multiple Deployments, which estimate to move to GA in 16.11.
GitLab Pages Multiple Deployments 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.