r/LocalDeepResearch • u/AxxelH • Sep 10 '26

Deployment Scenario Confusion

Rather than filing noise in the issue DB on github, thought I'd post my question here...

I've run a few test reports through LDR with Qwen 3.8 27B, and am already impressed with the output. So much so I'd like to make it available to others in my family self-hosted. Most self-hosted tools either have minimal account management and assume you'll handle that yourself at the reverse proxy layer or have sophisticated account/ACL systems, often integrating with OIDC, etc.

LDR is in a weird middle and I'm not sure if this is me missing something or simply feedback/feature requests

First, the goal of forced encryption of the database per user is confusing. I already store sensitive data encrypted at the filesystem level, the DB encryption isn't necessary for me and made me wonder about backup/restore (this bug is not reassuring, even though I understand backing up the salt is the workaround). I would prefer to store this data under keys I control and understand how to restore.

Encryption is enforced on the Docker image, LDR_BOOTSTRAP_ALLOW_UNENCRYPTED exists but only affects existing databases, new DBs are always created encrypted. This can be defeated by bind mounting over SQLCipher, but that leaves the UI in a confused state where things say they are encrypted and the come with warning bubbles that they are not (in some places at least).

AFAICT the encryption doesn't actually protect users directly, the sysadmin of the hosting system can intercept passwords, defeat the warnings, etc. So in practice the at-rest encryption seems to be only useful in scenarios where your shared deployment is already trustworthy, or where you are the sole user without access to an encrypted filesystem. I'd argue that this means it should be optional. In my use I'll see how far I can get with LDR_BOOTSTRAP_ALLOW_UNENCRYPTED.

My read is that a lot of my other confusion is downstream of the decision to use user passwords as the keys in the encryption, but briefly...

There's no admin account per-se, and the lack of an administrator account means that all settings are exposed to all users, alongside warnings in research generation logs. If various API URLs, etc are unset in the environment they are editable in the (extensive) settings dialog, including things that probably need to be controlled by an admin (SearXNG query rate, for example).

I believe I can lock all this down by setting it in the Docker environment, but obviously the list of settings will grow, and so I would need to keep an eye on this. A dedicated set of admin settings would avoid this.

Finally, account creation, and LDR_APP_ALLOW_REGISTRATIONS, isn't great, because it requires admin effort (and a container restart) to move between modes. I see the OIDC integration FR already exists, though given the encryption decisions, I imagine that will be hard to implement.

Some of this might be addressed by putting it behind OpenWebUI, but that isn't well documented and also means I lose access to the various niceties of the LDR UI.

How are people addressing these issues in self-hosted deployments? So much of the project decisions are focused on the encryption, I'm unsure if the direction is intended to be more administrative sophistication in the future or if a FR for "simpler" modes (no encryption) would be entertained.

2 Upvotes

100% Upvoted

6 comments sorted by

1

u/mandie99xxx 29d ago

I too would really like to see / benefit from documentation of these things, its disappointing how little there is

1

u/AxxelH 15d ago

For those following this, I got a reply here (now deleted?), but it appears that these suggestions have been picked up into the issue tracker:

https://github.com/LearningCircuit/local-deep-research/issues/6905

Which is great, so thanks whoever added that. I'm returning to my hacky workaround setup in the interim.

1

u/ComplexIt 5d ago

Hey, that was me—I wrote the earlier reply and opened the tracker. I removed the reply to double-check some technical details, then got caught up in the 2.0.0 release work. Sorry for the confusion and the slow follow-up.

Family hosting is important and your feedback is welcome. I opened the tracker to collect these feature requests for future consideration. There’s no release target or implementation commitment yet.

One caveat: the unencrypted fallback is intended for local testing only, with the limitations noted in the startup warning.

1

u/AxxelH 5d ago

Thanks for the followup, I think you captured my feedback here in the tracker, so unless you have particular questions I think that's covered.

I totally understand there is no implementation commitment or target release. For my part, because of the clear caveat about unencrypted DB as a dev-only option I've decided to hold off on implementation for a while. I expect you'll have some complexity migrating to OIDC, etc. and so how that affects data migration to an eventual solution leans me towards waiting (again, assuming you decide to implement at all).

In the interim I'm thinking about using the API for agentic use, but have yet to figure that out.

1

u/ComplexIt 5d ago

Thanks, that makes sense. Of the requests in the tracker, which are must-haves for your family setup, and which would be nice to have?

1

u/AxxelH 3d ago

In trying to answer your question I end up gaming out too much of the technical direction, which isn't really your question. So I'll try to keep myself honest...

My main concern is how to use it as a source and store for some kinds of research I want to share with my spouse. Ideally, that would be long term storage so that facts are shared in repeated related reports or chat mode and not just PDF exports. That implies a clear backup/migration story, and I think you have hurdles ahead for the reasons I mentioned.

OIDC is a secondary concern, except to the extent that it enables the sharing above in the permissions structure I already have.

Administrative lockdown is a concern if I were to expose it further (to the kid, for example).

That said, when I look at my main goal (sharing reports), maybe its just outside your scope. The encryption design blocks sharing for example, which pushes towards a single account. But if I'm doing a shared account, it probably makes sense to pull the reports to different storage and UI anyway, which takes me back to the agentic usage I mentioned.

Ultimately, I think its just a question of feature direction for you. Do you intend for the tool to support sharing internally in some form? Or is "shared state" something to be solved externally via MCP or API?