A: Yes. We use GCP Persistent Storage volumes underneath all of our filesystems, and that is implicitly encrypted. So the live filesystems, their snapshot-based backups, database replicas, and logical backups are all fully encrypted at the block device layer. Additionally, GCP encrypts and encapsulates traffic between our nodes within our VPCs, so data in motion is also protected from eavesdropping and tampering.
A: Neither the git repo backups nor the database backups will be purged immediately (Note: In the future, the time frame might be longer once soft deletes for groups and projects are implemented). When a project is deleted, the corresponding data from the database as well as the files associated with that project's repository, pages, and wiki will be removed, but will continue to exist in backups for up to two weeks after the deletion. For this reason we cannot guarantee that a deleted project is entirely purged from our system until the oldest of those backups expires. Please note that this is not the same as "secure delete", which typically means overwriting the deleted files' blocks with random bytes at least N times, but without the decryption keys, a stolen copy of our disk images would be unreadable.
A: You can find the settings we use for GitLab.com and our runners in our docs.
A: Data from March 2019 showed there was 3.5 Million Users, around 4,000 requests per second over https, 8.4 Million Repos, and over 3 PB total storage. See our vanity metrics dashboard.
A: Currently you can only use the project import/export feature to migrate projects to GitLab.com.
A: No, once a project is deleted it cannot be restored. In the future soft deletes for groups and projects will allow users to restore a project during the soft deletion state.
A: Yes, with sufficient evidence that it's necessary, customers can request to be allowlisted. To request to be added to the allowlist, see our section on how we handle incoming requests in the handbook.