IMO, this is user error. GitLab adding validation on their side at app level is a nice to have feature for sure. Ultimately though, keep your DNS records up to date! If you stop using a service, stop pointing your records to it, simple. If you point any record to a service that matches based on CNAME, A or some other arbitrary value expect squatting/"hijacking" to occur if you delete your reservation of that name.
Absolutely. If you're building a POC or MVP it's a quick and easy way to get something off the ground. The framework will take you pretty far before you have scaling issues (long enough to know if what you're making is worth it). The community is very knowledgeable and friendly, and gems for almost everything already exist.
If I needed to spin up a new project and get to work right away on something I'd go with rails no question. I've yet to find another language/framework combo that works as well as a Ruby & Rails stack (Laravel and Django are good alternatives too, I'm just more experienced with Ruby). Don't think too far ahead. Premature optimization or thinking about future scaling issues if starting a new project is time that could be spent better. Rails isn't going anywhere anytime soon.
GitLab acquired GitHost from me a couple years ago [1]. They were able to do more with it than I ever could of. It's a very niche product that probably wasn't worth the engineering effort to keep it feature complete, especially at GitLab's pace of adding new features. GitHost was created before CI/CD was integrated into GitLab core. It was a much simpler product to automate deployments for back then.
Pale Blue Dot is based on Hyperlax (hyperlax.tv). Huge thanks to Taylor Crane (https://twitter.com/taykcrane) for letting me modify it for this purpose!
VT-x is not enabled in the bios of our cloud images. Is there a specific need to run the build inside of a nested vm, as opposed to running directly in the runner itself? Feel free to email me jfrye [at] githost.io to discuss further.
All of our CI instances (coordinators and runners) are based on Ubuntu 12.04 x64 images. You are free to install any sort of software needed to run your builds on the runners.
GitLab CI integrates directly with GitLab CE installs, requiring no configuration from the end user. Compared to Jenkins, it will automatically link up with your repo and start builds on commits and pull requests. These are things you have to manually configure with something like Jenkins. As for Travis CI, the integration is just as seamless. GitLab CI talks to GitLab installs via the CE api and automatically pulls in your projects, sets the build status on your repos and assigns runners to perform your builds. The GitLab team has really done an amazing job building a CI offering that integrates really well with their CE repo app.
If you like GitLab, checkout GitHost (https://githost.io) We provide hosted private GitLab instances. We handle upgrades, security fixes, and backups automatically.
PHP is just as secure as any other language. It's the programmer's best practices (or lack of) and implementation that can make the code secure or insecure. The language is mature, actively maintained, and has a nice standard lib (debatable). Whether or not YOUR program will be secure depends on you the PROGRAMMER not the language.
Just so you guys know this script has changed a lot since I opened it up. It now has way better output formatting, the option to install Ruby from source or RVM, better stdout and stderr redirection to the install.log and even captures signals for things like ctrl-c to kill the script nicely. Thanks for all the input and I hope it's found to be useful :)