Skip to content

Conversation

@rogu-beta
Copy link

@rogu-beta rogu-beta commented Nov 14, 2025

This modification allows to establish a secure connection to an external Redis instance in scenarios where PurlDB is not deployed via docker compose. The current defaults are kept for compatibility reasons. This means by default no TLS is used, as is currently already the case, as a local deployment with docker compose is assumed where all services are runing on the same host. Similar fixes have been made in DejaCode (aboutcode-org/dejacode@1a4f703) and ScanCode.io (aboutcode-org/scancode.io@f0750d4).

This modification allows to establish a secure connection to an external Redis instance in scenarios where PurlDB is not deployed via docker compose. The current defaults are kept for compatibility reasons. This means by default no TLS is used, as is currently already the case, as a local deployment with docker compose assumed where all services are runing on the same host. Similar fixes have been made in DejaCode (aboutcode-org/dejacode@1a4f703) and ScanCode.io (aboutcode-org/scancode.io@f0750d4).

Signed-off-by: Robert Guetzkow <[email protected]>
@pombredanne
Copy link
Member

Thanks! @JonoYang ping :)

@pombredanne
Copy link
Member

@rogu-beta BTW, I am always wondering if we really need the baggage of Redis... and if using the DB as a queue would not be plenty enough.

@rogu-beta
Copy link
Author

@pombredanne That is certainly an option. It's difficult to judge such architectural choices as merely a contributor. Removing Redis as a dependency may simplify some aspects, but it would require the introduction of new abstractions and likely additional libraries to make PostgreSQL work as job queue. Performance impact may also be a concern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants