diff --git a/README.md b/README.md
index bc173b5403c777a8becf4c53e8288751dc0bb34b..caafa30ead5050f39604d8055ec98f6b4c627630 100644
--- a/README.md
+++ b/README.md
@@ -68,9 +68,9 @@ GitLab is an open source project and we are very happy to accept community contr
 
 To work on GitLab itself, we recommend setting up your development environment with [the GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit).
 If you do not use the GitLab Development Kit you need to install and setup all the dependencies yourself, this is a lot of work and error prone.
-One small thing you also have to do when installing it yourself is to copy the example development Unicorn configuration file:
+One small thing you also have to do when installing it yourself is to copy the example development Puma configuration file:
 
-    cp config/unicorn.rb.example.development config/unicorn.rb
+    cp config/puma.rb.example.development config/puma.rb
 
 Instructions on how to start GitLab and how to run the tests can be found in the [getting started section of the GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit#getting-started).
 
diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md
index bd34a82f6881428f7bdbe096b3d54c1ba0c68c9a..828cdecb014999bb5a1d8c064b8117e263dcbb98 100644
--- a/doc/administration/database_load_balancing.md
+++ b/doc/administration/database_load_balancing.md
@@ -171,28 +171,6 @@ Some nameservers (like [Consul](https://www.consul.io/docs/discovery/dns#udp-bas
 queried over UDP. To overcome this issue, you can use TCP for querying by setting
 `use_tcp` to `true`.
 
-### Forking
-
-NOTE:
-Starting with GitLab 13.0, Puma is the default web server used in GitLab
-all-in-one package based installations as well as GitLab Helm chart deployments.
-
-If you use an application server that forks, such as Unicorn, you _have to_
-update your Unicorn configuration to start service discovery _after_ a fork.
-Failure to do so leads to service discovery only running in the parent
-process. If you are using Unicorn, then you can add the following to your
-Unicorn configuration file:
-
-```ruby
-after_fork do |server, worker|
-  defined?(Gitlab::Database::LoadBalancing) &&
-    Gitlab::Database::LoadBalancing.start_service_discovery
-end
-```
-
-This ensures that service discovery is started in both the parent and all
-child processes.
-
 ## Balancing queries
 
 Read-only `SELECT` queries balance among all the secondary hosts.
diff --git a/doc/administration/geo/replication/geo_validation_tests.md b/doc/administration/geo/replication/geo_validation_tests.md
index 8f67e70c9e2ebabf152cd77f861187ee3f3dc090..c6b1078ddf08f4d806fb7c56e7b3924676afc440 100644
--- a/doc/administration/geo/replication/geo_validation_tests.md
+++ b/doc/administration/geo/replication/geo_validation_tests.md
@@ -43,7 +43,7 @@ The following are GitLab upgrade validation tests we performed.
 - Outcome: Partial success because we observed downtime during the upgrade of the primary and secondary sites.
 - Follow up issues/actions:
   - [Fix zero-downtime upgrade process/instructions for multi-node Geo deployments](https://gitlab.com/gitlab-org/gitlab/-/issues/225684)
-  - [Geo:check Rake task: Exclude AuthorizedKeysCommand check if node not running Puma/Unicorn](https://gitlab.com/gitlab-org/gitlab/-/issues/225454)
+  - [Geo:check Rake task: Exclude AuthorizedKeysCommand check if node not running Puma](https://gitlab.com/gitlab-org/gitlab/-/issues/225454)
   - [Update instructions in the next upgrade issue to include monitoring HAProxy dashboards](https://gitlab.com/gitlab-org/gitlab/-/issues/225359)
 
 [Upgrade Geo multi-node installation](https://gitlab.com/gitlab-org/gitlab/-/issues/208104):
@@ -53,7 +53,7 @@ The following are GitLab upgrade validation tests we performed.
 - Outcome: Partial success because we did not run the looping pipeline during the demo to validate
   zero-downtime.
 - Follow up issues:
-  - [Clarify how Puma/Unicorn should include deploy node](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5460)
+  - [Clarify how Puma should include deploy node](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5460)
   - [Investigate MR creation failure after upgrade to 12.9.10](https://gitlab.com/gitlab-org/gitlab/-/issues/223282) Closed as false positive.
 
 ### February 2020
diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md
index 59bb3884a02788966be1d27abbb2f855c6d07db3..a11fa1241bf3a0736a5b92f2308781387bd81e84 100644
--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -222,7 +222,6 @@ the **primary** database. Use the following as a guide.
    sidekiq['enable'] = false
    sidekiq_cluster['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    ```
 
 After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
@@ -294,7 +293,6 @@ Configure the tracking database.
    sidekiq['enable'] = false
    sidekiq_cluster['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    ```
 
 After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
@@ -440,7 +438,6 @@ application servers above, with some changes to run only the `sidekiq` service:
    redis_exporter['enable'] = false
    repmgr['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
 
    ##
    ## The unique identifier for the Geo node.
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index c9b6fd4c5105d76c4d9dd48904213ab4ba9523b0..d79fcec336f52f13c1607977ef578db2aed9f160 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -82,7 +82,7 @@ The following list depicts the network architecture of Gitaly:
 - Gitaly addresses must be specified in such a way that they resolve correctly for **all** Gitaly
   clients.
 - Gitaly clients are:
-  - Puma or Unicorn.
+  - Puma.
   - Sidekiq.
   - GitLab Workhorse.
   - GitLab Shell.
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 3935e990590f08bd1d271b800482e714b9296009..8e8df73e58159400d6e3cae8282c13928808b1d1 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -346,7 +346,6 @@ When GitLab calls a function that has a "Rugged patch", it performs two checks:
   the GitLab use of "Rugged patch" code.
 - If the feature flag is not set, GitLab tries accessing the file system underneath the
   Gitaly server directly. If it can, it uses the "Rugged patch":
-  - If using Unicorn.
   - If using Puma and [thread count](../../install/requirements.md#puma-threads) is set
     to `1`.
 
diff --git a/doc/administration/logs.md b/doc/administration/logs.md
index 5921406973b1dc9187f52b01f5b02046f7e20ace..eb51cd8c33b7a587be56ee0cc40e5ba6427c9d32 100644
--- a/doc/administration/logs.md
+++ b/doc/administration/logs.md
@@ -739,7 +739,7 @@ When enabled, access logs are generated in
 packages or in `/home/git/gitlab/log/sidekiq_exporter.log` for
 installations from source.
 
-If Prometheus metrics and the Web Exporter are both enabled, Puma/Unicorn
+If Prometheus metrics and the Web Exporter are both enabled, Puma
 starts a Web server and listen to the defined port (default: `8083`), and access logs
 are generated:
 
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index 035c5b3ee7e0cca4d3601aba43b3c9e9d928252d..d0966e657d23ad591f892133422b0804bf715873 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -227,7 +227,7 @@ To use an external Prometheus server:
    gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
    ```
 
-1. On **all** GitLab Rails(Puma/Unicorn, Sidekiq) servers, set the Prometheus server IP address and listen port. For example:
+1. On **all** GitLab Rails(Puma, Sidekiq) servers, set the Prometheus server IP address and listen port. For example:
 
    ```ruby
    gitlab_rails['prometheus_address'] = '192.168.0.1:9090'
diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index c49a2c20ed260cec6bffe01cb0bde3fdc534955c..983f1df1b987292c9d2169f2bb1216dff28c11ec 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -445,11 +445,11 @@ In case of NFS-related problems, it can be helpful to trace
 the file system requests that are being made by using `perf`:
 
 ```shell
-sudo perf trace -e 'nfs4:*' -p $(pgrep -fd ',' puma && pgrep -fd ',' unicorn)
+sudo perf trace -e 'nfs4:*' -p $(pgrep -fd ',' puma)
 ```
 
 On Ubuntu 16.04, use:
 
 ```shell
-sudo perf trace --no-syscalls --event 'nfs4:*' -p $(pgrep -fd ',' puma && pgrep -fd ',' unicorn)
+sudo perf trace --no-syscalls --event 'nfs4:*' -p $(pgrep -fd ',' puma)
 ```
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index 980db9713ee6401321867c8c3cb023d86c1f5b7d..e88736ed282c764e95721662d568b4435c55b622 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -219,5 +219,5 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 GitLab supports `authorized_keys` database lookups with [SELinux](https://en.wikipedia.org/wiki/Security-Enhanced_Linux).
 
 Because the SELinux policy is static, GitLab doesn't support the ability to change
-internal Unicorn ports at the moment. Administrators would have to create a special `.te`
+internal webserver ports at the moment. Administrators would have to create a special `.te`
 file for the environment, since it isn't generated dynamically.
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index 3b676010bfe58df361e7638ad8233252f2edca98..06845fe79663da98115d2535aa0a88ce8b1db8c5 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -7,8 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Switching to Puma
 
 As of GitLab 12.9, [Puma](https://github.com/puma/puma) has replaced [Unicorn](https://yhbt.net/unicorn/)
-as the default web server. From GitLab 13.0, the following run Puma instead of Unicorn unless
-explicitly configured not to:
+as the default web server. From GitLab 14.0, the following run Puma:
 
 - All-in-one package-based installations.
 - Helm chart-based installations.
@@ -25,7 +24,7 @@ Multi-threaded Puma can therefore still serve more requests than a single proces
 
 ## Configuring Puma to replace Unicorn
 
-Beginning with GitLab 13.0, Puma is the default application server. We plan to remove support for
+Beginning with GitLab 13.0, Puma is the default application server. We removed support for
 Unicorn in GitLab 14.0.
 
 When switching to Puma, Unicorn server configuration
diff --git a/doc/administration/read_only_gitlab.md b/doc/administration/read_only_gitlab.md
index 698da80a07c8cc1fb2fc2dba8a35e93b7d8789f5..c8931eb79df9ccbdb43f706ceecf83062407c9eb 100644
--- a/doc/administration/read_only_gitlab.md
+++ b/doc/administration/read_only_gitlab.md
@@ -19,10 +19,10 @@ The configuration for doing so depends on your desired outcome.
 The first thing you'll want to accomplish is to ensure that no changes can be
 made to your repositories. There's two ways you can accomplish that:
 
-- Either stop Unicorn/Puma to make the internal API unreachable:
+- Either stop Puma to make the internal API unreachable:
 
   ```shell
-  sudo gitlab-ctl stop puma  # or unicorn
+  sudo gitlab-ctl stop puma
   ```
 
 - Or, open up a Rails console:
@@ -46,19 +46,19 @@ made to your repositories. There's two ways you can accomplish that:
 ## Shut down the GitLab UI
 
 If you don't mind shutting down the GitLab UI, then the easiest approach is to
-stop `sidekiq` and `puma`/`unicorn`, and you'll effectively ensure that no
+stop `sidekiq` and `puma`, and you'll effectively ensure that no
 changes can be made to GitLab:
 
 ```shell
 sudo gitlab-ctl stop sidekiq
-sudo gitlab-ctl stop puma  # or unicorn
+sudo gitlab-ctl stop puma
 ```
 
 When you're ready to revert this:
 
 ```shell
 sudo gitlab-ctl start sidekiq
-sudo gitlab-ctl start puma  # or unicorn
+sudo gitlab-ctl start puma
 ```
 
 ## Make the database read-only
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index c9beee19fda5348cad45224e0c74a1cd41baeb2b..9167045301e27ec9d114594d209f7c00f1488e49 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -157,7 +157,7 @@ To set up GitLab and its components to accommodate up to 10,000 users:
    provides access to the Git repositories.
 1. [Configure Sidekiq](#configure-sidekiq).
 1. [Configure the main GitLab Rails application](#configure-gitlab-rails)
-   to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend
+   to run Puma, Workhorse, GitLab Shell, and to serve all frontend
    requests (which include UI, API, and Git over HTTP/SSH).
 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab
    environment.
@@ -1538,7 +1538,6 @@ To configure the Praefect nodes, on each one:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -1667,7 +1666,6 @@ On each node:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -2235,7 +2233,6 @@ To configure the Monitoring node:
    redis_exporter['enable'] = false
    sidekiq['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    node_exporter['enable'] = false
    gitlab_exporter['enable'] = false
 
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 1474d1b54e34cb4b594f8ae01642d217ad49b12b..84a8767e8f2b76faddb1cd44fcd6fb16e8a66c61 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -157,7 +157,7 @@ To set up GitLab and its components to accommodate up to 25,000 users:
    provides access to the Git repositories.
 1. [Configure Sidekiq](#configure-sidekiq).
 1. [Configure the main GitLab Rails application](#configure-gitlab-rails)
-   to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend
+   to run Puma, Workhorse, GitLab Shell, and to serve all frontend
    requests (which include UI, API, and Git over HTTP/SSH).
 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab
    environment.
@@ -1540,7 +1540,6 @@ To configure the Praefect nodes, on each one:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -1669,7 +1668,6 @@ On each node:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -2239,7 +2237,6 @@ To configure the Monitoring node:
    redis_exporter['enable'] = false
    sidekiq['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    node_exporter['enable'] = false
    gitlab_exporter['enable'] = false
 
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index b653a57debab49e47e319e376d4ef650c5568e14..0ff0c6bb55090d07bdfb582e7804c6d0786ee616 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -84,7 +84,7 @@ To set up GitLab and its components to accommodate up to 2,000 users:
 1. [Configure Gitaly](#configure-gitaly), which provides access to the Git
    repositories.
 1. [Configure the main GitLab Rails application](#configure-gitlab-rails)
-   to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend
+   to run Puma, Workhorse, GitLab Shell, and to serve all frontend
    requests (which include UI, API, and Git over HTTP/SSH).
 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab
    environment.
@@ -351,7 +351,6 @@ Omnibus:
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    postgresql['enable'] = false
    nginx['enable'] = false
    prometheus['enable'] = false
@@ -457,7 +456,6 @@ To configure the Gitaly server, on the server node you want to use for Gitaly:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -791,7 +789,6 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    redis_exporter['enable'] = false
    sidekiq['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    node_exporter['enable'] = false
    gitlab_exporter['enable'] = false
 
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index 709420b9e24a1c41d33e4e8bdfbc372b586e0a5d..8f11c7f02d113e62e34807247aa5299815b656f2 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -169,7 +169,7 @@ To set up GitLab and its components to accommodate up to 3,000 users:
    provides access to the Git repositories.
 1. [Configure Sidekiq](#configure-sidekiq).
 1. [Configure the main GitLab Rails application](#configure-gitlab-rails)
-   to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend
+   to run Puma, Workhorse, GitLab Shell, and to serve all frontend
    requests (which include UI, API, and Git over HTTP/SSH).
 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab
    environment.
@@ -1238,7 +1238,6 @@ To configure the Praefect nodes, on each one:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -1367,7 +1366,6 @@ On each node:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -1916,7 +1914,6 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    redis_exporter['enable'] = false
    sidekiq['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    node_exporter['enable'] = false
    gitlab_exporter['enable'] = false
 
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index f492f82f9024c1ae0672399ba9395055589ccec9..35ecb914440173d1ebdf82f06e00bf5bc85130a7 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -157,7 +157,7 @@ To set up GitLab and its components to accommodate up to 50,000 users:
    provides access to the Git repositories.
 1. [Configure Sidekiq](#configure-sidekiq).
 1. [Configure the main GitLab Rails application](#configure-gitlab-rails)
-   to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend
+   to run Puma, Workhorse, GitLab Shell, and to serve all frontend
    requests (which include UI, API, and Git over HTTP/SSH).
 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab
    environment.
@@ -1547,7 +1547,6 @@ To configure the Praefect nodes, on each one:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -1676,7 +1675,6 @@ On each node:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -2253,7 +2251,6 @@ To configure the Monitoring node:
    redis_exporter['enable'] = false
    sidekiq['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    node_exporter['enable'] = false
    gitlab_exporter['enable'] = false
 
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 36d8b1021017f011ad30ae885890952a747da581..b9a938cec188658f4da7c6e32be65e264a61a9c0 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -161,7 +161,7 @@ To set up GitLab and its components to accommodate up to 5,000 users:
    provides access to the Git repositories.
 1. [Configure Sidekiq](#configure-sidekiq).
 1. [Configure the main GitLab Rails application](#configure-gitlab-rails)
-   to run Puma/Unicorn, Workhorse, GitLab Shell, and to serve all frontend
+   to run Puma, Workhorse, GitLab Shell, and to serve all frontend
    requests (which include UI, API, and Git over HTTP/SSH).
 1. [Configure Prometheus](#configure-prometheus) to monitor your GitLab
    environment.
@@ -1229,7 +1229,6 @@ To configure the Praefect nodes, on each one:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -1358,7 +1357,6 @@ On each node:
    redis['enable'] = false
    nginx['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
    grafana['enable'] = false
@@ -1904,7 +1902,6 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    redis_exporter['enable'] = false
    sidekiq['enable'] = false
    puma['enable'] = false
-   unicorn['enable'] = false
    node_exporter['enable'] = false
    gitlab_exporter['enable'] = false
 
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index 5a8ee1c5c94888323c4b74bb4a0169d859cf4409..d8e3a69c2adeb92fde257b3e64638d80021ada70 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -155,7 +155,7 @@ and more. However, this is not enabled by default. To enable it, define the
 gitlab_rails['env'] = {"ENABLE_RBTRACE" => "1"}
 ```
 
-Then reconfigure the system and restart Unicorn and Sidekiq. To run this
+Then reconfigure the system and restart Puma and Sidekiq. To run this
 in Omnibus, run as root:
 
 ```ruby
diff --git a/doc/administration/troubleshooting/linux_cheat_sheet.md b/doc/administration/troubleshooting/linux_cheat_sheet.md
index c4e991ccc1b97b7645a829e4ce1237f6f89e4250..9de095e0560cc3ce1230d1cece122632fcdec614 100644
--- a/doc/administration/troubleshooting/linux_cheat_sheet.md
+++ b/doc/administration/troubleshooting/linux_cheat_sheet.md
@@ -177,8 +177,8 @@ strace -tt -T -f -y -yy -s 1024 -p <pid>
 
 # -o    output file
 
-# run strace on all unicorn processes
-ps auwx | grep unicorn | awk '{ print " -p " $2}' | xargs strace -tt -T -f -y -yy -s 1024 -o /tmp/unicorn.txt
+# run strace on all puma processes
+ps auwx | grep puma | awk '{ print " -p " $2}' | xargs strace -tt -T -f -y -yy -s 1024 -o /tmp/puma.txt
 ```
 
 Be aware that strace can have major impacts to system performance when it is running.
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index d8d452240ff38250fd6b4e091a8777695deeb41d..e82ce1cc2dc0863e65e142ae02350e3a45257717 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -695,8 +695,7 @@ Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue
 
 #### Puma
 
-Starting with GitLab 13.0, Puma is the default web server and Unicorn has been
-disabled by default.
+Starting with GitLab 13.0, Puma is the default web server.
 
 - [Project page](https://gitlab.com/gitlab-org/gitlab/blob/master/README.md)
 - Configuration:
diff --git a/doc/development/chaos_endpoints.md b/doc/development/chaos_endpoints.md
index 56e91acbc4ac7cde3efd0e356806f528fd497974..ae53a39c4c503054dbc606bfb0dadcf4c40f4c87 100644
--- a/doc/development/chaos_endpoints.md
+++ b/doc/development/chaos_endpoints.md
@@ -47,7 +47,7 @@ Replace `secret` with your own secret token.
 After you have enabled the chaos endpoints and restarted the application, you can start testing using the endpoints.
 
 By default, when invoking a chaos endpoint, the web worker process which receives the request handles it. This means, for example, that if the Kill
-operation is invoked, the Puma or Unicorn worker process handling the request is killed. To test these operations in Sidekiq, the `async` parameter on
+operation is invoked, the Puma worker process handling the request is killed. To test these operations in Sidekiq, the `async` parameter on
 each endpoint can be set to `true`. This runs the chaos process in a Sidekiq worker.
 
 ## Memory leaks
@@ -79,7 +79,6 @@ curl "http://localhost:3000/-/chaos/leakmem?memory_mb=1024&duration_s=10&token=s
 This endpoint attempts to fully utilise a single core, at 100%, for the given period.
 
 Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
-If you're using Unicorn, this is done by killing the worker process.
 
 ```plaintext
 GET /-/chaos/cpu_spin
@@ -103,7 +102,6 @@ This endpoint attempts to fully utilise a single core, and interleave it with DB
 This endpoint can be used to model yielding execution to another threads when running concurrently.
 
 Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
-If you're using Unicorn, this is done by killing the worker process.
 
 ```plaintext
 GET /-/chaos/db_spin
diff --git a/doc/development/db_dump.md b/doc/development/db_dump.md
index 505305c860a74c19984e03cb052f96f1b99cbd73..0c63bf06e0786ab185914e1b70fcc25a5e850bc9 100644
--- a/doc/development/db_dump.md
+++ b/doc/development/db_dump.md
@@ -21,7 +21,7 @@ large database imports.
 echo "postgresql['checkpoint_segments'] = 64" | sudo tee -a /etc/gitlab/gitlab.rb
 sudo touch /etc/gitlab/skip-auto-reconfigure
 sudo gitlab-ctl reconfigure
-sudo gitlab-ctl stop unicorn
+sudo gitlab-ctl stop puma
 sudo gitlab-ctl stop sidekiq
 ```
 
diff --git a/doc/development/kubernetes.md b/doc/development/kubernetes.md
index 5be2080eb644572075d902da9f451c7ce93e5bf1..20e66fe8a307df762c38e0ce283284f20319193d 100644
--- a/doc/development/kubernetes.md
+++ b/doc/development/kubernetes.md
@@ -50,7 +50,7 @@ to the relevant internal client.
 
 All calls to the Kubernetes API must be in a background process. Don't
 perform Kubernetes API calls within a web request. This blocks
-Unicorn, and can lead to a denial-of-service (DoS) attack in GitLab as
+webserver, and can lead to a denial-of-service (DoS) attack in GitLab as
 the Kubernetes cluster response times are outside of our control.
 
 The easiest way to ensure your calls happen a background process is to
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index 543ca809f4502059361c809233ff413bbe37ae37..973d4042cdaa74f4d272ae36ea928b82f2c3de29 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -292,13 +292,13 @@ in a batch style.
 
 **Summary:** You should set a reasonable timeout when the system invokes HTTP calls
 to external services (such as Kubernetes), and it should be executed in Sidekiq, not
-in Puma/Unicorn threads.
+in Puma threads.
 
 Often, GitLab needs to communicate with an external service such as Kubernetes
 clusters. In this case, it's hard to estimate when the external service finishes
 the requested process, for example, if it's a user-owned cluster that's inactive for some reason,
 GitLab might wait for the response forever ([Example](https://gitlab.com/gitlab-org/gitlab/-/issues/31475)).
-This could result in Puma/Unicorn timeout and should be avoided at all cost.
+This could result in Puma timeout and should be avoided at all cost.
 
 You should set a reasonable timeout, gracefully handle exceptions and surface the
 errors in UI or logging internally.
@@ -598,10 +598,10 @@ Each feature that accepts data uploads or allows to download them needs to use
 saved directly to Object Storage by Workhorse, and all downloads needs to be served
 by Workhorse.
 
-Performing uploads/downloads via Unicorn/Puma is an expensive operation,
-as it blocks the whole processing slot (worker or thread) for the duration of the upload.
+Performing uploads/downloads via Puma is an expensive operation,
+as it blocks the whole processing slot (thread) for the duration of the upload.
 
-Performing uploads/downloads via Unicorn/Puma also has a problem where the operation
+Performing uploads/downloads via Puma also has a problem where the operation
 can time out, which is especially problematic for slow clients. If clients take a long time
 to upload/download the processing slot might be killed due to request processing
 timeout (usually between 30s-60s).
diff --git a/doc/development/performance.md b/doc/development/performance.md
index c6fe9f29b53b1317b22a4693c26cc758ce8af21a..84b3a8f10926e9b2392c30ee0b98e3152d700f4a 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -283,8 +283,8 @@ Currently supported profiling targets are:
 - Sidekiq
 
 NOTE:
-The Puma master process is not supported. Neither is Unicorn.
-Sending SIGUSR2 to either of those triggers restarts. In the case of Puma,
+The Puma master process is not supported.
+Sending SIGUSR2 to it triggers restarts. In the case of Puma,
 take care to only send the signal to Puma workers.
 
 This can be done via `pkill -USR2 puma:`. The `:` distinguishes between `puma
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index 62cc2543fc49f6f26c7cf7af0d62bcc5764b4f55..9c7927978b366d09c3f464ed4d57fd3010b1d75e 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -129,7 +129,7 @@ way that increases execution time by several orders of magnitude.
 
 ### Impact
 
-The resource, for example Unicorn, Puma, or Sidekiq, can be made to hang as it takes
+The resource, for example Puma, or Sidekiq, can be made to hang as it takes
 a long time to evaluate the bad regex match. The evaluation time may require manual
 termination of the resource.
 
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index abacb9a0c873e0c41871c4c9e6cad67adb2c9b57..630b32daba2b79030e34b27d77004739f99fb5ad 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -48,7 +48,7 @@ records should use stubs/doubles as much as possible.
 | `config/` | `spec/config/` | RSpec | |
 | `config/initializers/` | `spec/initializers/` | RSpec | |
 | `config/routes.rb`, `config/routes/` | `spec/routing/` | RSpec | |
-| `config/puma.example.development.rb`, `config/unicorn.rb.example` | `spec/rack_servers/` | RSpec | |
+| `config/puma.example.development.rb` | `spec/rack_servers/` | RSpec | |
 | `db/` | `spec/db/` | RSpec | |
 | `db/{post_,}migrate/` | `spec/migrations/` | RSpec | More details in the [Testing Rails migrations guide](testing_migrations_guide.md). |
 | `Gemfile` | `spec/dependencies/`, `spec/sidekiq/` | RSpec | |
diff --git a/doc/install/installation.md b/doc/install/installation.md
index b9bde01c2fac6d3f256749f0fe49f7c4ddbb4abe..c5a30024a7b393d720a436ad5f5371ec401084fb 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -545,7 +545,6 @@ sudo -u git -H editor config/resque.yml
 ```
 
 Make sure to edit both `gitlab.yml` and `puma.rb` to match your setup.
-If you want to use the Unicorn web server, see [Using Unicorn](#using-unicorn) for the additional steps.
 
 If you want to use HTTPS, see [Using HTTPS](#using-https) for the additional steps.
 
@@ -996,24 +995,6 @@ You also need to change the corresponding options (e.g. `ssh_user`, `ssh_host`,
 
 Apart from the always supported Markdown style, there are other rich text files that GitLab can display. But you might have to install a dependency to do so. See the [`github-markup` gem README](https://github.com/gitlabhq/markup#markups) for more information.
 
-### Using Unicorn
-
-As of GitLab 12.9, [Puma](https://github.com/puma/puma) has replaced Unicorn as the default web server for installations from source.
-If you want to switch back to Unicorn, follow these steps:
-
-1. Finish the GitLab setup so you have it up and running.
-1. Copy the supplied example Unicorn configuration file into place:
-
-   ```shell
-   cd /home/git/gitlab
-
-   # Copy config file for the web server
-   sudo -u git -H cp config/unicorn.rb.example config/unicorn.rb
-   ```
-
-1. Edit the system `init.d` script and set `USE_WEB_SERVER="unicorn"`. If you have `/etc/default/gitlab`, then you should edit it instead.
-1. Restart GitLab.
-
 ### Using Sidekiq instead of Sidekiq Cluster
 
 As of GitLab 12.10, Source installations are using `bin/sidekiq-cluster` for managing Sidekiq processes.
diff --git a/doc/install/relative_url.md b/doc/install/relative_url.md
index d04f55c43a352bba83eeaccead20db137f27a1e3..8b629e9084e46355dcf24c54082c62753e8520c9 100644
--- a/doc/install/relative_url.md
+++ b/doc/install/relative_url.md
@@ -29,7 +29,7 @@ relative URL is:
 
 - `/home/git/gitlab/config/initializers/relative_url.rb`
 - `/home/git/gitlab/config/gitlab.yml`
-- `/home/git/gitlab/config/unicorn.rb`
+- `/home/git/gitlab/config/puma.rb`
 - `/home/git/gitlab-shell/config.yml`
 - `/etc/default/gitlab`
 
@@ -88,7 +88,7 @@ Make sure to follow all steps below:
    relative_url_root: /gitlab
    ```
 
-1. Edit `/home/git/gitlab/config/unicorn.rb` and uncomment/change the
+1. Edit `/home/git/gitlab/config/puma.rb` and uncomment/change the
    following line:
 
    ```ruby
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 8accf0947958580a69c1e2f11586afde3e1debbc..00de9dbbfea1dc9399e1d364c969d49d7fcd359c 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -201,22 +201,6 @@ of [legacy Rugged code](../administration/gitaly/index.md#direct-access-to-git-i
 higher, due to how [Ruby MRI multi-threading](https://en.wikipedia.org/wiki/Global_interpreter_lock)
 works.
 
-## Unicorn Workers
-
-For most instances we recommend using: (CPU cores * 1.5) + 1 = Unicorn workers.
-For example a node with 4 cores would have 7 Unicorn workers.
-
-For all machines that have 2GB and up we recommend a minimum of three Unicorn workers.
-If you have a 1GB machine we recommend to configure only two Unicorn workers to prevent excessive
-swapping.
-
-As long as you have enough available CPU and memory capacity, it's okay to increase the number of
-Unicorn workers and this usually helps to reduce the response time of the applications and
-increase the ability to handle parallel requests.
-
-To change the Unicorn workers when you have the Omnibus package (which defaults to the
-recommendation above) please see [the Unicorn settings in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/unicorn.html).
-
 ## Redis and Sidekiq
 
 Redis stores all user sessions and the background task queue.
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index da1278b9edd961e5ae882e1ea527e871fac63eb3..927dd3cd714cf51b8334aadb512e4f190d3819e6 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -813,13 +813,13 @@ the CSRF check.
 
 To bypass this you can add `skip_before_action :verify_authenticity_token` to the
 `omniauth_callbacks_controller.rb` file immediately after the `class` line and
-comment out the `protect_from_forgery` line using a `#`. Restart Unicorn for this
+comment out the `protect_from_forgery` line using a `#`. Restart Puma for this
 change to take effect. This allows the error to hit GitLab, where it can then
 be seen in the usual logs, or as a flash message on the login screen.
 
 That file is located in `/opt/gitlab/embedded/service/gitlab-rails/app/controllers`
 for Omnibus installations and by default in `/home/git/gitlab/app/controllers` for
-installations from source. Restart Unicorn using the `sudo gitlab-ctl restart unicorn`
+installations from source. Restart Puma using the `sudo gitlab-ctl restart puma`
 command on Omnibus installations and `sudo service gitlab restart` on installations
 from source.
 
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index fc1c7838fd5237b04e73394cc8e95c2afc3f2fda..592ddb298e58884dbcf060747abe3943445acdcf 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -122,7 +122,7 @@ Similar to the Kubernetes case, if you have scaled out your GitLab cluster to
 use multiple application servers, you should pick a designated node (that isn't
 auto-scaled away) for running the backup Rake task. Because the backup Rake
 task is tightly coupled to the main Rails application, this is typically a node
-on which you're also running Unicorn/Puma or Sidekiq.
+on which you're also running Puma or Sidekiq.
 
 Example output:
 
@@ -928,7 +928,6 @@ Stop the processes that are connected to the database. Leave the rest of GitLab
 running:
 
 ```shell
-sudo gitlab-ctl stop unicorn
 sudo gitlab-ctl stop puma
 sudo gitlab-ctl stop sidekiq
 # Verify
@@ -996,7 +995,6 @@ For Docker installations, the restore task can be run from host:
 
 ```shell
 # Stop the processes that are connected to the database
-docker exec -it <name of container> gitlab-ctl stop unicorn
 docker exec -it <name of container> gitlab-ctl stop puma
 docker exec -it <name of container> gitlab-ctl stop sidekiq
 
diff --git a/doc/update/mysql_to_postgresql.md b/doc/update/mysql_to_postgresql.md
index cbe2381e8db22633b198635dc2bc0e819dd043d4..92337f279d630334ce52c40780868792b26b260f 100644
--- a/doc/update/mysql_to_postgresql.md
+++ b/doc/update/mysql_to_postgresql.md
@@ -91,10 +91,10 @@ need to enable the bundled PostgreSQL:
 1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure)
    for the changes to take effect.
 
-1. Start Unicorn and PostgreSQL so that we can prepare the schema:
+1. Start Puma and PostgreSQL so that we can prepare the schema:
 
    ```shell
-   sudo gitlab-ctl start unicorn
+   sudo gitlab-ctl start puma
    sudo gitlab-ctl start postgresql
    ```
 
@@ -104,10 +104,10 @@ need to enable the bundled PostgreSQL:
    sudo gitlab-rake db:create db:migrate
    ```
 
-1. Stop Unicorn to prevent other database access from interfering with the loading of data:
+1. Stop Puma to prevent other database access from interfering with the loading of data:
 
    ```shell
-   sudo gitlab-ctl stop unicorn
+   sudo gitlab-ctl stop puma
    ```
 
 After these steps, you have a fresh PostgreSQL database with up-to-date schema.
diff --git a/doc/update/upgrading_postgresql_using_slony.md b/doc/update/upgrading_postgresql_using_slony.md
index 2cddaa5da8b8d6d92a9b3e87eb35152678467875..3e977749207353c1fab47d2a1421f7ac035abf81 100644
--- a/doc/update/upgrading_postgresql_using_slony.md
+++ b/doc/update/upgrading_postgresql_using_slony.md
@@ -371,7 +371,7 @@ First, let's stop all of GitLab. Omnibus users can do so by running the
 following on their GitLab servers:
 
 ```shell
-sudo gitlab-ctl stop unicorn
+sudo gitlab-ctl stop puma
 sudo gitlab-ctl stop sidekiq
 sudo gitlab-ctl stop mailroom
 ```
diff --git a/doc/user/admin_area/geo_nodes.md b/doc/user/admin_area/geo_nodes.md
index e5132ef4e96fe8572e676209c6f1508f3ecea310..32b1555c33d49ff214ce4f0ed1c315f4d670cb04 100644
--- a/doc/user/admin_area/geo_nodes.md
+++ b/doc/user/admin_area/geo_nodes.md
@@ -82,7 +82,7 @@ In GitLab 11.11, **secondary** nodes can use identical external URLs as long as
 a unique `name` is set for each Geo node. The `gitlab.rb` setting
 `gitlab_rails['geo_node_name']` must:
 
-- Be set for each GitLab instance that runs `unicorn`, `sidekiq`, or `geo_logcursor`.
+- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`.
 - Match a Geo node name.
 
 The load balancer must use sticky sessions in order to avoid authentication
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index 5d1fde1c76781f3c95c2bf3e0f52feb531a7c625..6c7f985dce645c5aefc87c9004b85a8eef51235c 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -344,7 +344,7 @@ For multi-node systems we recommend ingesting the logs into services like Elasti
 |:------------------------|:---------|
 | `application.log`       | GitLab user activity |
 | `git_json.log`          | Failed GitLab interaction with Git repositories |
-| `production.log`        | Requests received from Unicorn, and the actions taken to serve those requests |
+| `production.log`        | Requests received from Puma, and the actions taken to serve those requests |
 | `sidekiq.log`           | Background jobs |
 | `repocheck.log`         | Repository activity |
 | `integrations_json.log` | Activity between GitLab and integrated systems |
diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md
index 3570634b9baa28f55f081010b207311df71a48b6..1643ad0effa4294c048423b75516308c6673d2e0 100644
--- a/doc/user/admin_area/settings/gitaly_timeouts.md
+++ b/doc/user/admin_area/settings/gitaly_timeouts.md
@@ -20,9 +20,8 @@ To access Gitaly timeout settings:
 The following timeouts can be modified:
 
 - **Default Timeout Period**. This timeout is the default for most Gitaly calls. It should be shorter than the
-  worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings)
-  or [Unicorn](https://docs.gitlab.com/omnibus/settings/unicorn.html). Used to make sure that Gitaly
-  calls made within a web request cannot exceed the entire request timeout.
+  worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings).
+  Used to make sure that Gitaly calls made within a web request cannot exceed the entire request timeout.
   Defaults to 55 seconds.
 
 - **Fast Timeout Period**. This is the timeout for very short Gitaly calls. Defaults to 10 seconds.