## Problem https://gitlab.com/groups/gitlab-org/-/epics/8819#note_1110632459: >>> A customer recently was testing the push-to-secondary proxy functionality with Geo pushing 200-500 MB repositories. They ran into several issues: 1. The default of Unicorn timeout 60 was too low to handle this. They bumped the timeout to 1000 seconds, but that's not ideal. If the API were handled in Workhorse, I think we could avoid this issue. 1. The payloads were read in entirely in RAM, causing huge memory spikes in Unicorn. (https://gitlab.com/gitlab-org/gitlab-ee/issues/12817). If we go down the Workhorse route, we should consider buffering the pack file and streaming it to the primary. >>> https://gitlab.com/groups/gitlab-org/-/epics/8819#note_1110632494: >>> the most recent ticket is in [ZD](https://gitlab.zendesk.com/agent/tickets/197869) (internal only) when trying to push the main branch on a repository with > 260k commits, 1.9k branches, 3.3k tags, 2.4GB `"/api/v4/geo/proxy_git_ssh/receive_pack"` was the endpoint timing out with the default Puma timeout - they ended up pushing directly to the Geo primary (which worked) >>> ## Background Currently the code for proxying SSH pushes to secondaries lives inside Rails, which is not ideal. https://gitlab.com/gitlab-org/gitlab/-/issues/6533 Current workflow for pushing on a secondary is described in detail in https://gitlab.com/gitlab-org/gitlab/-/issues/383498.