Community Edition (CE) is still a common term people use when looking for GitLab. The key change is that Free is not limited to CE: the Enterprise Edition (EE) package can also run with Free features. What differs most for self-managed users is the path to paid features.
GitLab offers Free, Premium, and Ultimate tiers. The EE package can run with Free features without a paid subscription. If you later purchase a subscription, you can activate EE with an activation code to unlock the features in that tier. See the current plans and EE activation instructions.
Starting a new self-managed instance? Choose EE, even if you plan to use Free. EE Free can opt into Registration Features for access to selected additional features when Service Ping is enabled. The program isn't available with CE, and it doesn't include every paid-tier feature.
| Starting point | Using GitLab for free | If you want paid features |
|---|---|---|
| CE package | Use the Community Edition package. | Convert the instance to EE, then activate a subscription. The process depends on your installation type. |
| EE package | Use the Free features without a paid subscription. | Activate a subscription with an activation code. You can also start a 30-day Self-Managed Ultimate trial. |
For a new self-managed installation, EE offers a more direct route if you expect to evaluate or move to paid features later. If you already use CE and want to keep using its Free feature set, you can continue with it; moving from CE to paid features requires a package conversion first. For Linux package instances, follow the CE-to-EE conversion guide and back up your instance before making changes.
Free Self-Managed EE instances can also opt into the Registration Features Program. It provides access to certain paid features when an administrator enables Registration Features and sends activity data through Service Ping. The program does not replace a paid tier or include every paid feature.
Before 2019, Community Edition and Enterprise Edition were developed in separate repositories. In 2019, development moved to a single codebase: the former CE repository became the GitLab FOSS mirror, while the main GitLab project became the central place for development. Read the 2019 transition overview for background.
The canonical GitLab project is where development takes place, including issues and merge requests. The GitLab FOSS project is a read-only mirror of the main codebase with proprietary code removed. Use it to browse or clone that code view, not to report issues or propose changes.
For a new self-managed deployment, start with the GitLab installation page and follow the relevant Linux package instructions.
If you already run CE and want to access paid features, use the conversion guide for your installation type. For Linux package instances, the conversion guide explains how to install the EE package over CE and then add a license. If you are evaluating paid features, you can start a Self-Managed Ultimate trial.
No. GitLab development takes place in the canonical project, and contributions are not limited to CE. Follow the contribution guide to propose code, documentation, design, and other improvements.
Customer teams looking for guided collaboration can learn about GitLab Co-Create, where customers work with GitLab Product and Engineering teams on features and improvements. Co-Create is a structured customer program; it is separate from the standard community contribution path.
gitlab-org/gitlab-ce still the active development repository?No. The former CE repository became the GitLab FOSS mirror. Ongoing development takes place in the canonical GitLab project.
It is a read-only copy of the main codebase with proprietary code removed. It is for browsing or cloning that code view, not for reporting issues or proposing changes.
Use the installation page to choose a deployment method, then follow the relevant GitLab Docs. If you are moving from CE to EE, use the conversion guide for your installation type.