[Pages] Should "Use unique domain" be disabled by default?
Problem Statement
The current default behavior of using unique domains for GitLab Pages projects (e.g., portfolio-7d24a8.gitlab.io) doesn't align with many users' expectations. Users often expect clean, predictable URLs in the format of username.gitlab.io/project-name, similar to GitHub Pages.
This creates a disconnect between:
- What users expect:
username.gitlab.io/project-name - What they get:
portfolio-7d24a8.gitlab.io
While unique domains solve important technical problems, the lack of clear explanation about this behavior and its benefits causes confusion for users.
This issue was created following a thread started as
We need to reconsider having 'Use unique domain' enabled by default. The current default doesn't align with user expectations and creates unnecessary complexity. Users should opt-in to unique domains rather than having to opt-out.
Evidence
-
User feedback indicates confusion when deploying a test project:
"I deployed a test project under my namespace and expected to access it via https://\[user-name\].gitlab.io/\[project-name\], but unexpectedly it redirected me to a URL with unique identifiers."
-
Multiple team members have acknowledged this experience gap:
Technical Background
As @janis explained, unique domains provide several benefits:
- Industry standard for static site deployments (used by Netlify, Vercel, Cloudflare, etc.)
- Prevents accidental resource sharing between projects
- Solves static asset path issues (CSS files and images not loading due to absolute paths)
- Aligns production experience with local development
Proposed Solutions
Main approaches were mentioned at the discussion thread that would address this issue:
1. Change Current Behavior:
Disable "Use unique domain" by default
- Align with user expectations for clean, predictable URLs
- Make unique domains opt-in rather than opt-out
- Match GitHub Pages approach for namespace/project URL structure
2. Keep Current Behavior:
Continue enabling "Use unique domain" by default with improvements
- Add clear UI messaging explaining why unique domains are used and their benefits
- Improve domain generation to create more intuitive subdomains from project names
- Allow users to choose available subdomains through the UI after page creation
- Consider using randomized words instead of hashes for better recognition
- Enhance documentation on the reasoning behind using unique domains
3. Middle-Ground Approaches:
- Enable unique domains only when needed (when authentication is enabled)
- Keep URLs simple for basic static sites while maintaining security for complex ones
- Implement smart detection of cases where unique domains solve technical problems
Questions to Consider
- How do other platforms (besides GitHub) handle this balance between security and user experience?
- What validation would be needed to prevent subdomain conflicts if we allow more user control?
- How can we prevent potential security issues (like the takeover vulnerability mentioned by @vshushlin here)?