>If you are using GitLab.com to host your website, then:

>The general domain name for GitLab Pages on GitLab.com is gitlab.io.

>Custom domains and TLS support are enabled.

>Shared runners are enabled by default, provided for free and can be used to build your website. If you want you can still bring your own Runner.

GitLab.com runs GitLab EE, which you can use for free.

We considered bringing it to CE. But we still think this is more useful if you run a server with a lot of developers, our criteria for EE features as listed on https://about.gitlab.com/about/#stewardship

Our thesis is that if you have less users you likely have less sites and you can set up a normal CI jobs to deploy it.

This is a moot point to anyone running GitLab CE though.

I was a little short in my reply, my apologies.

Sytse explained our vision below [0]. We're always open to discuss this further.

[0]: https://news.ycombinator.com/item?id=11432614

(Disclaimer: I wrote b3cmd)

We have a wildcard DNS entry pointed at our server and we use b3cmd[1][2] for static servers. It also handles docker-compose projects. SSL everywhere, CORS supported, branches / namespaces supported. Pretty great so far.

[1]: https://github.com/mikew/b3cmd [2]: https://github.com/mikew/b3cmd-server

I thought that, too. But on the other hand if you're running your own private instance what's really the point of serving up statically generated pages from GitLab instead of just directly off your own HTTP server of choice?

There's less stuff to manage if you're serving up pages from a selfhosted Gitlab instance than actually serving up the repo directly.