Signal's attachment storage architecture has evolved through several iterations, traceable in its codebase from `AttachmentControllerV2` (AWS S3) to `AttachmentControllerV3` (GCS), and currently to `AttachmentControllerV4` (TUS protocol). The latest implementation combines Google Cloud Storage with the TUS resumable upload protocol. According to the code snippet below, TUS uploads are currently limited to internal testers while most users continue with GCS:

this.attachmentGenerators = Map.of(
    2, gcsAttachmentGenerator,
    3, tusAttachmentGenerator
);

final boolean useTusProtocol = this.experimentManager.isEnrolled(user.getUuid(), TUS_TRIAL_NAME);
int selectedProtocol = useTusProtocol ? 3 : 2;

The V4 server implementation resides at https://github.com/signalapp/tus-server, designed as a Cloudflare Worker application utilizing their R2 storage engine. This deployment approach requires Cloudflare's infrastructure or Wrangler emulator for testing. Unlike previous solutions where AWS or GCS handled storage operations automatically, this new approach introduces significant operational overhead with custom code maintenance.

While the motivation for migrating from AWS to GCS remains unclear (possibly cost-related), the transition to R2 provides definite advantages in both bandwidth costs and user experience, justifying the additional engineering and operational complexity despite the implementation requirements.

For organizations seeking private Signal deployments, replicating Cloudflare's infrastructure isn't practical. Using Wrangler would only provide an emulation environment with potential performance limitations. Meanwhile, GCS might be unfamiliar or inaccessible for certain deployment scenarios.

Two independent approaches can successfully address private Signal attachment storage requirements. Either solution can be implemented independently or combined:

Approach 1: Synchronized Server-Client Modification
Modify the server by reintroducing AWS S3 support within the `AttachmentControllerV4` framework, replacing the existing `gcsAttachmentGenerator` with an `awsAttachmentGenerator`. This requires corresponding client modifications, though changes are minimal - primarily disabling the resumable upload functionality in the attachment transfer logic.

Approach 2: Server-Side TUS Implementation
Reimplement the TUS server component independently. An example implementation is available at: https://github.com/alexsunday/tus-storage

Deployment via Docker Compose is straightforward:

docker run -d --rm --name tus-server --network signal-backend \
  -e AWS_ACCESS_KEY_ID=AKIAEXAMPLEKEY \
  -e AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
  -e AWS_REGION=us-west-2 \
  tuss:latest /app/tuss \
  -redis redis://redis:6379/1 \
  -secret base64EncodedSecretKey1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ

This approach maintains full compatibility with the existing Signal client without requiring any modifications. However, upload speeds may not match direct AWS S3 transfers from the client. The official implementation leverages Cloudflare's global CDN network for optimal performance. For private deployments, Approach 1 with direct AWS S3 uploads might provide better throughput.

Both solutions successfully achieve private attachment storage, with the optimal choice depending on existing infrastructure, performance requirements, and operational preferences.