TIL: Optimize Red Hat Quay – John Goh's blog

The default Quay configuration is a solid starting point for a standard, single-node or small private registry deployment. For performance, especially as your registry usage or image sizes grow, there are several areas in which you can improve, depending on your infrastructure, available resources, and intended traffic. Here’s an actionable review tailored for your setup:

Table of Contents

1. Storage Backend Improvements

If you’re still using default storage path, you’re likely like me who is using filesystems available on my docker container, Local disk storage (LocalStorage) works but is not optimal for performance or reliability, especially with large images or concurrent users. Here’s a few suggestions:-

Faster Disks: Use SSDs/NVMe for /datastorage to reduce image push/pull latency.
Distributed/Object Storage: Consider S3, Ceph, or another distributed backend. They scale better and offload storage management from your local disks.
Multiple Workers: For high-throughput scenarios, run multiple Quay containers behind a load balancer (requires shared storage/object storage).

2. Database/Redis Tuning

Database Connection Pooling. By default, Quay will open connections as needed. You can explicitly set pooling parameters for high concurrency:

DB_CONNECTION_ARGS:
  pool_size: 20
  max_overflow: 30

Tune these based on your container host’s resources and usage pattern.

PostgreSQL Tweaks:

Tune PostgreSQL for large object storage, shared buffers, WAL settings, and disable fsync (only for non-production/testing!), and monitor database CPU and IO utilization. If the database is on the same host, separation may improve performance.

3. Redis Performance & Scaling

Ensure Redis has enough memory for your workload. Monitor eviction and cache hit rates.

For heavy use, deploy Redis on a separate, resource-dedicated VM or container.

4. Nginx (Proxy) Optimizations

Increase buffer sizes to improve performance for large pushes/pulls:

proxy_buffer_size 128k;
proxy_buffers 8 256k;
proxy_busy_buffers_size 256k;

5. Quay Features/Options

Consider enabling FEATURE_STORAGE_REPLICATION (if you add a second storage backend for geo-redundancy/performance).

6. Image GC (Garbage Collection)

Set up and aggressively schedule repository GC to reclaim space and improve DB/query performance. and consider reducing DEFAULT_TAG_EXPIRATION if your retention needs allow.

7. Search Performance

Default search limits are low for large deployments. If you need faster/broader search, consider raising the following values below. (But higher values may increase DB/CPU load.)

SEARCH_MAX_RESULT_PAGE_COUNT: 20
SEARCH_RESULTS_PER_PAGE: 50

8. Other Tips

Ensure host OS limits (e.g., open files, ulimits) are raised so Quay processes are not throttled.
Monitor log files for any repeated warnings/errors.
Consider deploying a replica of Quay for load balancing (requires shared or object storage).

9. Quay Upgrades

Consider upgrading to a newer release if feasible. Newer versions bring bugfixes and may improve performance/scaling (3.7.8 is not the latest).

If your registry gets moderate to heavy usage, these changes will yield improved performance and better user experience.