diff options
Diffstat (limited to 'doc/install')
| -rw-r--r-- | doc/install/aws/manual_install_aws.md | 4 | ||||
| -rw-r--r-- | doc/install/azure/index.md | 6 | ||||
| -rw-r--r-- | doc/install/cloud_native/index.md | 54 | ||||
| -rw-r--r-- | doc/install/docker.md | 48 | ||||
| -rw-r--r-- | doc/install/google_cloud_platform/index.md | 6 | ||||
| -rw-r--r-- | doc/install/index.md | 46 | ||||
| -rw-r--r-- | doc/install/install_methods.md | 51 | ||||
| -rw-r--r-- | doc/install/installation.md | 4 | ||||
| -rw-r--r-- | doc/install/migrate/compare_sm_to_saas.md | 124 | ||||
| -rw-r--r-- | doc/install/requirements.md | 33 |
10 files changed, 245 insertions, 131 deletions
diff --git a/doc/install/aws/manual_install_aws.md b/doc/install/aws/manual_install_aws.md index 7494dc1e95e..2aa2aa0c3f7 100644 --- a/doc/install/aws/manual_install_aws.md +++ b/doc/install/aws/manual_install_aws.md @@ -483,7 +483,7 @@ Connect to your GitLab instance via **Bastion Host A** using [SSH Agent Forwardi #### Disable Let's Encrypt -Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration) when using an `https` domain in GitLab 10.7 and later, so we must explicitly disable it: +Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl.html#enable-the-lets-encrypt-integration) when using an `https` domain in GitLab 10.7 and later, so we must explicitly disable it: 1. Open `/etc/gitlab/gitlab.rb` and disable it: @@ -605,7 +605,7 @@ Now that we have our EC2 instance ready, follow the [documentation to install Gi #### Add Support for Proxied SSL -As we are terminating SSL at our [load balancer](#load-balancer), follow the steps at [Supporting proxied SSL](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl) to configure this in `/etc/gitlab/gitlab.rb`. +As we are terminating SSL at our [load balancer](#load-balancer), follow the steps at [Supporting proxied SSL](https://docs.gitlab.com/omnibus/settings/ssl.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination) to configure this in `/etc/gitlab/gitlab.rb`. Remember to run `sudo gitlab-ctl reconfigure` after saving the changes to the `gitlab.rb` file. diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md index 7f155a78140..dd2e7d678e8 100644 --- a/doc/install/azure/index.md +++ b/doc/install/azure/index.md @@ -233,7 +233,7 @@ The first thing that appears is the sign-in page. GitLab creates an administrato The credentials are: - Username: `root` -- Password: the password is automatically created, and there are +- Password: the password is automatically created, and there are [two ways to find it](https://docs.bitnami.com/azure/faq/get-started/find-credentials/). After signing in, be sure to immediately [change the password](../../user/profile/index.md#change-your-password). @@ -248,7 +248,7 @@ in this section whenever you need to update GitLab. To determine the version of GitLab you're currently running: -1. On the top bar, select **Menu > Admin**. +1. On the top bar, select **Main menu > Admin**. 1. On the left sidebar, select **Overview > Dashboard**. 1. Find the version under the **Components** table. @@ -294,7 +294,7 @@ up-to-date GitLab instance. ## Next steps and further configuration Now that you have a functional GitLab instance, follow the -[next steps](../index.md#next-steps) to learn what more you can do with your +[next steps](../next_steps.md) to learn what more you can do with your new installation. ## Troubleshooting diff --git a/doc/install/cloud_native/index.md b/doc/install/cloud_native/index.md index f3265500877..d971cd419e9 100644 --- a/doc/install/cloud_native/index.md +++ b/doc/install/cloud_native/index.md @@ -1,51 +1,11 @@ --- -stage: Systems -group: Distribution -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments -comments: false -description: Install GitLab in a cloud native environment -type: index +redirect_to: 'https://docs.gitlab.com/charts/' +remove_date: '2023-09-09' --- -# Cloud Native GitLab **(FREE SELF)** +This document was moved to [another location](https://docs.gitlab.com/charts/). -[Cloud Native GitLab](https://gitlab.com/gitlab-org/build/CNG) provides cloud -native containers to deploy GitLab. These containers may be deployed and managed -via Helm using GitLab Charts or GitLab Operator on Kubernetes, OpenShift, -and Kubernetes compatible container platforms: - -- [Helm charts](https://docs.gitlab.com/charts/): The cloud native Helm chart - installs GitLab and all of its components on Kubernetes. Use this method if - your infrastructure is built on Kubernetes and you're familiar with how it - works. The methods for management, observability, and some concepts are - different than traditional deployments. -- [GitLab Operator](https://docs.gitlab.com/operator/): The GitLab Operator - provides an installation and management method for GitLab following the - [Kubernetes Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/). - You can also use the GitLab Operator to run GitLab in an - [OpenShift](../openshift_and_gitlab/index.md) environment. - -Here's an overview of how the containers are built: - -```mermaid -graph TD - subgraph Code - CNG --> HC - CNG --> GOP - HC --> GOP - end - - subgraph Deploy - GOP --> K8s - GOP --> OS - CNG --> DC - HC --> K8s - end - - CNG[Cloud Native GitLab containers] - HC[Helm Chart] - K8s(Kubernetes) - GOP[GitLab Operator] - OS(OpenShift) - DC(Docker Compose) -``` +<!-- This redirect file can be deleted after <2023-09-09>. --> +<!-- Redirects that point to other docs in the same project expire in three months. --> +<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
\ No newline at end of file diff --git a/doc/install/docker.md b/doc/install/docker.md index 7ec1b7c741a..bf08fecc9ca 100644 --- a/doc/install/docker.md +++ b/doc/install/docker.md @@ -301,7 +301,7 @@ point to a valid URL. To receive e-mails from GitLab you have to configure the [SMTP settings](https://docs.gitlab.com/omnibus/settings/smtp.html) because the GitLab Docker image doesn't have an SMTP server installed. You may also be interested in -[enabling HTTPS](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https). +[enabling HTTPS](https://docs.gitlab.com/omnibus/settings/ssl.html). After you make all the changes you want, you will need to restart the container in order to reconfigure GitLab: @@ -462,7 +462,9 @@ In most cases, upgrading GitLab is as easy as downloading the newest Docker To upgrade GitLab that was [installed using Docker Engine](#install-gitlab-using-docker-engine): -1. Take a [backup](#back-up-gitlab). +1. Take a [backup](#back-up-gitlab). As a minimum, back up [the database](#create-a-database-backup) and + the GitLab secrets file. + 1. Stop the running container: ```shell @@ -506,7 +508,9 @@ when upgrading between major versions. To upgrade GitLab that was [installed using Docker Compose](#install-gitlab-using-docker-compose): -1. Take a [backup](#back-up-gitlab). +1. Take a [backup](#back-up-gitlab). As a minimum, back up [the database](#create-a-database-backup) and + the GitLab secrets file. + 1. Download the newest release and upgrade your GitLab instance: ```shell @@ -527,8 +531,11 @@ We recommend you convert from the same version of CE to EE (for example, CE 14.1 This is not explicitly necessary, and any standard upgrade (for example, CE 14.0 to EE 14.1) should work. The following steps assume that you are upgrading the same version. -1. Take a [backup](#back-up-gitlab). +1. Take a [backup](#back-up-gitlab). As a minimum, back up [the database](#create-a-database-backup) and + the GitLab secrets file. + 1. Stop the current CE container, and remove or rename it. + 1. To create a new container with GitLab EE, replace `ce` with `ee` in your `docker run` command or `docker-compose.yml` file. However, reuse the CE container name, port and file mappings, and version. @@ -538,6 +545,22 @@ The following steps assume that you are upgrading the same version. This is an optional step. If you [installed the documentation site](#install-the-product-documentation), see how to [upgrade to another version](../administration/docs_self_host.md#upgrade-using-docker). +### Downgrade GitLab + +To downgrade GitLab after an upgrade: + +1. Follow the upgrade procedure, but [specify the tag for the original version of GitLab](#use-tagged-versions-of-gitlab) + instead of `latest`. + +1. Restore the [database backup you made](#create-a-database-backup) as part of the upgrade. + + - Restoring is required to back out database data and schema changes (migrations) made as part of the upgrade. + - GitLab backups must be restored to the exact same version and edition. + - [Follow the restore steps for Docker images](../raketasks/restore_gitlab.md#restore-for-docker-image-and-gitlab-helm-chart-installations), including + stopping Puma and Sidekiq. Only the database must be restored, so add + `SKIP=artifacts,repositories,registry,uploads,builds,pages,lfs,packages,terraform_state` + to the `gitlab-backup restore` command line arguments. + ## Back up GitLab You can create a GitLab backup with: @@ -554,6 +577,23 @@ If configuration is provided entirely via the `GITLAB_OMNIBUS_CONFIG` environmen meaning no configuration is set directly in the `gitlab.rb` file, then there is no need to back up the `gitlab.rb` file. +WARNING: +[Backing up the GitLab secrets file](../raketasks/backup_gitlab.md#storing-configuration-files) is required +to avoid [complicated steps](../raketasks/backup_restore.md#when-the-secrets-file-is-lost) when recovering +GitLab from backup. The secrets file is stored at `/etc/gitlab/gitlab-secrets.json` inside the container, or +`$GITLAB_HOME/config/gitlab-secrets.json` [on the container host](#set-up-the-volumes-location). + +### Create a database backup + +A database backup is required to roll back GitLab upgrade if you encounter issues. + +```shell +docker exec -t <container name> gitlab-backup create SKIP=artifacts,repositories,registry,uploads,builds,pages,lfs,packages,terraform_state +``` + +The backup is written to `/var/opt/gitlab/backups` which should be on a +[volume mounted by Docker](#set-up-the-volumes-location). + ## Installing GitLab Community Edition [GitLab CE Docker image](https://hub.docker.com/r/gitlab/gitlab-ce/) diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md index b63ab8d4e2b..e924b6f7c41 100644 --- a/doc/install/google_cloud_platform/index.md +++ b/doc/install/google_cloud_platform/index.md @@ -42,7 +42,7 @@ To deploy GitLab on GCP you must create a virtual machine:  -1. To select the size, type, and desired [operating system](../requirements.md#supported-linux-distributions), +1. To select the size, type, and desired [operating system](../../administration/package_information/supported_os.md#supported-operating-systems), select **Change** under `Boot disk`. select **Select** when finished. 1. As a last step allow HTTP and HTTPS traffic, then select **Create**. The process finishes in a few seconds. @@ -117,8 +117,8 @@ here's how you configure GitLab to be aware of the change: ### Configuring HTTPS with the domain name -Although not needed, it's strongly recommended to secure GitLab with a TLS -certificate. Follow the steps in the [Omnibus documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https). +Although not needed, it's strongly recommended to secure GitLab with a +[TLS certificate](https://docs.gitlab.com/omnibus/settings/ssl.html). ### Configuring the email SMTP settings diff --git a/doc/install/index.md b/doc/install/index.md index 413c5116c14..89203c652d1 100644 --- a/doc/install/index.md +++ b/doc/install/index.md @@ -7,46 +7,14 @@ description: Read through the GitLab installation methods. type: index --- -# Installation **(FREE SELF)** +# Install GitLab **(FREE SELF)** -GitLab can be installed in most GNU/Linux distributions, and with several -cloud providers. To get the best experience from GitLab, you must balance -performance, reliability, ease of administration (backups, upgrades, and -troubleshooting), and the cost of hosting. +You can install GitLab on most GNU/Linux distributions, on several +cloud providers, and in Kubernetes clusters. -## Requirements +To get the best experience, you should balance performance, reliability, +ease of administration (backups, upgrades, and troubleshooting) with the cost of hosting. -Before you install GitLab, be sure to review the [system requirements](requirements.md). -The system requirements include details about the minimum hardware, software, -database, and additional requirements to support GitLab. +To get started, [choose your installation method](install_methods.md). -## Choose the installation method - -Depending on your platform, select from the following available methods to -install GitLab: - -| Installation method | Description | When to choose | -|----------------------------------------------------------------|-------------|----------------| -| [Linux package](https://docs.gitlab.com/omnibus/installation/) | The official deb/rpm packages (also known as Omnibus GitLab) that contains a bundle of GitLab and the components it depends on, including PostgreSQL, Redis, and Sidekiq. | This method is recommended for getting started. The Linux packages are mature, scalable, and are used today on GitLab.com. If you need additional flexibility and resilience, we recommend deploying GitLab as described in the [reference architecture documentation](../administration/reference_architectures/index.md). | -| [Helm charts](https://docs.gitlab.com/charts/) | The cloud native Helm chart for installing GitLab and all of its components on Kubernetes. | When installing GitLab on Kubernetes, it has some trade-offs that you must be aware of: <br/>- Administration and troubleshooting requires Kubernetes knowledge.<br/>- It can be more expensive for smaller installations. The default installation requires more resources than a single node Linux package deployment, as most services are deployed in a redundant fashion.<br/><br/> Use this method if your infrastructure is built on Kubernetes and you're familiar with how it works. The methods for management, observability, and some concepts are different than traditional deployments. | -| [Docker](docker.md) | The GitLab packages, Dockerized. | Use this method if you're familiar with Docker. | -| [Source](installation.md) | Install GitLab and all of its components from scratch. | Use this method if none of the previous methods are available for your platform. Can be used for unsupported systems like \*BSD.| -| [GitLab Environment Toolkit (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit#documentation) | The GitLab Environment toolkit provides a set of automation tools to deploy a [reference architecture](../administration/reference_architectures/index.md) on most major cloud providers. | Customers are very welcome to trial and evaluate GET today, however be aware of [key limitations](https://gitlab.com/gitlab-org/gitlab-environment-toolkit#missing-features-to-be-aware-of) of the current iteration. For production environments further manual setup is required based on your specific requirements. | -| [GitLab Operator](https://docs.gitlab.com/operator/) | The GitLab Operator provides an installation and management method for GitLab following the [Kubernetes Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/). | Use the GitLab Operator to run GitLab in an [OpenShift](openshift_and_gitlab/index.md) environment. | - -## Install GitLab on cloud providers - -Regardless of the installation method, you can install GitLab on several cloud -providers, assuming the cloud provider supports it. Here are several possible installation -methods, the majority which use the Linux packages: - -| Cloud provider | Description | -|---------------------------------------------------------------|-------------| -| [AWS (HA)](aws/index.md) | Install GitLab on AWS using the community AMIs provided by GitLab. | -| [Google Cloud Platform (GCP)](google_cloud_platform/index.md) | Install GitLab on a VM in GCP. | -| [Azure](azure/index.md) | Install GitLab from Azure Marketplace. | - -## Next steps - -After you complete the steps for installing GitLab, you can -[configure your instance](next_steps.md). +If you already have a running instance, learn how to [configure it](next_steps.md). diff --git a/doc/install/install_methods.md b/doc/install/install_methods.md new file mode 100644 index 00000000000..6c62deba6fa --- /dev/null +++ b/doc/install/install_methods.md @@ -0,0 +1,51 @@ +--- +stage: Systems +group: Distribution +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +comments: false +description: Read through the GitLab installation methods. +type: index +--- + +# Installation methods + +You can install GitLab by using any of the following methods. + +| Installation method | Description | When to choose | +|----------------------------------------------------------------|-------------|----------------| +| [Linux package](https://docs.gitlab.com/omnibus/installation/) | The official deb/rpm packages (also known as Omnibus GitLab). The package has GitLab and dependent components, including PostgreSQL, Redis, and Sidekiq. | Use if you want the most mature, scalable method. This version is also used on GitLab.com. <br>- For additional flexibility and resilience, see the [reference architecture documentation](../administration/reference_architectures/index.md).<br>- Review the [system requirements](requirements.md).<br>- View the [list of supported Linux operating systems](../administration/package_information/supported_os.md#supported-operating-systems). | +| [Helm chart](https://docs.gitlab.com/charts/) | A chart for installing a cloud-native version of GitLab and its components on Kubernetes. | Use if your infrastructure is on Kubernetes and you're familiar with how it works. Management, observability, and some concepts are different than traditional deployments.<br/>- Administration and troubleshooting requires Kubernetes knowledge.<br/>- It can be more expensive for smaller installations. The default installation requires more resources than a single node Linux package deployment, because most services are deployed in a redundant fashion.<br/><br/> | +| [Docker](docker.md) | The GitLab packages in a Docker container. | Use if you're familiar with Docker. | +| [Source](installation.md) | GitLab and its components from scratch. | Use if none of the previous methods are available for your platform. Can use for unsupported systems like \*BSD.| +| [GitLab Environment Toolkit (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit#documentation) | A set of automation tools. | Use to deploy a [reference architecture](../administration/reference_architectures/index.md) on most major cloud providers. Has some [limitations](https://gitlab.com/gitlab-org/gitlab-environment-toolkit#missing-features-to-be-aware-of) and manual setup for production environments. | +| [GitLab Operator](https://docs.gitlab.com/operator/) | An installation and management method that follows the [Kubernetes Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/). | Use to run GitLab in an [OpenShift](openshift_and_gitlab/index.md) environment. | + +## Cloud providers + +You can install GitLab on several cloud providers. + +| Cloud provider | Description | +|---------------------------------------------------------------|-------------| +| [AWS (HA)](aws/index.md) | Install GitLab on AWS using the community AMIs provided by GitLab. | +| [Google Cloud Platform (GCP)](google_cloud_platform/index.md) | Install GitLab on a VM in GCP. | +| [Azure](azure/index.md) | Install GitLab from Azure Marketplace. | + +## Unsupported Linux distributions and Unix-like operating systems + +- Arch Linux +- Fedora +- FreeBSD +- Gentoo +- macOS + +Installation of GitLab on these operating systems is possible, but not supported. +See the [installation from source guide](installation.md) and the [installation guides](https://about.gitlab.com/install/) for more information. + +See [OS versions that are no longer supported](../administration/package_information/supported_os.md#os-versions-that-are-no-longer-supported) for Omnibus installs page +for a list of supported and unsupported OS versions as well as the last support GitLab version for that OS. + +## Microsoft Windows + +GitLab is developed for Linux-based operating systems. +It does **not** run on Microsoft Windows, and we have no plans to support it in the near future. For the latest development status, view this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/22337). +Consider using a virtual machine to run GitLab. diff --git a/doc/install/installation.md b/doc/install/installation.md index 2f6adb06322..5982e354ae5 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -129,7 +129,7 @@ sudo apt-get install libkrb5-dev ### Git -From GitLab 13.6, we recommend you use the +From GitLab 13.6, we recommend you use the [Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729) that: @@ -239,7 +239,7 @@ sudo make install GitLab has several daemons written in Go. To install GitLab we need a Go compiler. The instructions below assume you use 64-bit -Linux. You can find downloads for other platforms at the +Linux. You can find downloads for other platforms at the [Go download page](https://go.dev/dl). ```shell diff --git a/doc/install/migrate/compare_sm_to_saas.md b/doc/install/migrate/compare_sm_to_saas.md new file mode 100644 index 00000000000..df79987a2fa --- /dev/null +++ b/doc/install/migrate/compare_sm_to_saas.md @@ -0,0 +1,124 @@ +--- +stage: Systems +group: Distribution +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments +--- + +# Comparison of GitLab self-managed with GitLab SaaS + +GitLab SaaS is the largest hosted instance of GitLab in the world, managed by an +[all-remote team](https://about.gitlab.com/company/culture/all-remote/) that knows GitLab best. With GitLab SaaS, updates, maintenance, and patches are all performed by this team. + +Self-managed GitLab gives you a deeper breadth of control over many of the functions and systems of the application. + +## Administration + +In GitLab SaaS, administration tasks are limited compared to a self-managed application. + +In a self-managed instance: + +- You have complete access and administrative control over the application, including the [Admin Area](../../user/admin_area/settings/index.md). +- You can impersonate, create, add, and remove users. +- You can assign the [`Auditor`](../../administration/auditor_users.md) user type and `External` role. + +On GitLab SaaS: + +- You have limited administrative control. For example, you cannot impersonate, create, add, or remove users. +- You cannot access the [Admin Area](../../user/admin_area/settings/index.md). +- You cannot assign the `Auditor` user type and `External` role. + +## Logs + +Logs give insight into your processes and can help GitLab Support maintain your application and resolve problems. + +In a self-managed instance: + +- You have full access to system logs. + +On GitLab SaaS: + +- You do not have access to system logs because they are at the instance level, and managed by the GitLab [infrastructure team](https://about.gitlab.com/handbook/engineering/infrastructure/). +- You can view [Audit Events](../../administration/audit_events.md) and the [GitLab API](../../api/audit_events.md). +- You must [request audit information](https://about.gitlab.com/handbook/support/workflows/log_requests.html) from the Support team. + +## Runners + +Runners are available for both SaaS and self-managed applications. + +In a self-managed instance, your runner availability and options are broader, but there are more [security concerns](https://docs.gitlab.com/runner/security/#security-for-self-managed-runners) to consider. + +On GitLab SaaS: + +- Private [runners](../../ci/runners/index.md) are available for GitLab SaaS [groups](../../user/group/index.md) and [projects](../../user/project/index.md). +- Shared runners provided by GitLab SaaS are not configurable. Each runner instance is used once for only one job, ensuring any sensitive data left on the system is destroyed after the job is complete. +- Shared runners are subject to usage limits and are [plan specific](https://about.gitlab.com/pricing/). + +## Custom Git hooks + +In a self-managed instance you can use any custom Git hooks. + +On GitLab SaaS: + +- SaaS users do not have access to the file system, and cannot use custom Git hooks. +- You can use [webhooks](../../user/project/integrations/webhooks.md) as an alternative. + +## API and GraphQL + +In a self-managed instance, users can access all API endpoints, including those that require instance `admin` permissions. + +On GitLab SaaS: + +- SaaS users have access to all of the [API endpoints](../../api/index.md) except those that require instance `admin` permissions. +- Only authorized GitLab engineers have administrative access. + +## Authentication + +In a self-managed instance: + +- You can use an internal encryption key for your data store. +- You can view console logs. +- You can enforce jobs on every pipeline across the group or organization. +- You have control over your data backup. +- You can use the [Interactive Web Terminal](../../ci/interactive_web_terminal/index.md#interactive-web-terminals) for shared runners. + +On GitLab SaaS: + +- You cannot use internal encryption key for the data store ([bring-your-own-key](https://about.gitlab.com/handbook/engineering/security/vulnerability_management/encryption-policy.html#rolling-your-own-crypto)). +- You cannot view console logs. +- You cannot enforce jobs on every pipeline across the group or organization. +- You cannot configure or control data backups. You must use [group](../../api/group_import_export.md) and [project](../../api/project_import_export.md) export. +- The [Interactive Web Terminal](../../ci/interactive_web_terminal/index.md#interactive-web-terminals) is not available for shared runners. + +## Public or private projects + +Project privacy is different when using a self-managed application or GitLab SaaS. + +In a self-managed instance, you control who can view your projects. + +On GitLab SaaS: + +- The GitLab SaaS instance is open to the public. +- When your projects are set as `Public`, they are open to everyone on the public internet. + +## Encryption + +In a self-managed instance, you control the encryption type and configuration. + +On GitLab SaaS: + +- An [Access Management Process](https://about.gitlab.com/handbook/engineering/security/#access-management-process) is in place. +- All data on GitLab.com is encrypted at rest by default. Access to encryption keys is strictly managed by GitLab. +- GitLab does not access your tenant data except as part of a verified service request from you. + +## Support + +In a self-managed instance: + +- You can access any of your back-end systems. +- Our Support team can request logs to assist you. + +On GitLab SaaS: + +- For your privacy and security, there is no public access to GitLab back-end systems. +- Support staff work with [Site Reliability Engineers](https://about.gitlab.com/job-families/engineering/infrastructure/site-reliability-engineer/) to support the [infrastructure](https://about.gitlab.com/handbook/engineering/infrastructure/). +- GitLab Support can access instance logs and view projects, as well as impersonate users. The Support Team can access your logs. diff --git a/doc/install/requirements.md b/doc/install/requirements.md index 93d66dc92a9..03870897417 100644 --- a/doc/install/requirements.md +++ b/doc/install/requirements.md @@ -4,38 +4,9 @@ group: Distribution info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# GitLab installation minimum requirements **(FREE SELF)** +# Installation system requirements **(FREE SELF)** -This page includes information about both the supported operating systems and -the minimum requirements needed to install and use GitLab. - -## Operating Systems - -### Supported Linux distributions - -See the [list of supported operating systems](../administration/package_information/supported_os.md#supported-operating-systems). - -For the installation options, see [the main installation page](index.md). - -### Unsupported Linux distributions and Unix-like operating systems - -- Arch Linux -- Fedora -- FreeBSD -- Gentoo -- macOS - -Installation of GitLab on these operating systems is possible, but not supported. -See the [installation from source guide](installation.md) and the [installation guides](https://about.gitlab.com/install/) for more information. - -See [OS versions that are no longer supported](../administration/package_information/supported_os.md#os-versions-that-are-no-longer-supported) for Omnibus installs page -for a list of supported and unsupported OS versions as well as the last support GitLab version for that OS. - -### Microsoft Windows - -GitLab is developed for Linux-based operating systems. -It does **not** run on Microsoft Windows, and we have no plans to support it in the near future. For the latest development status view this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/22337). -Consider using a virtual machine to run GitLab. +This page includes information about the minimum requirements you need to install and use GitLab. ## Software requirements |