Hello Community. I am considering using Ory Hydra as a library instead of self-hosting it directly, with a thin wrapper around the library, since I also want to support some additional endpoints in the same service and don't want to run two separate services. Since this doesn't seem to be a standard way of using Ory Hydra, what are the considerations I need to keep in mind before going ahead with this?

Hello @important-cartoon-77534 what additional endpoints would you introduce and why / what use cases do you want to solve? here are some quick thoughts why I would NOT recommend to run Ory Hydra as a library (if it is even possible?) - unsupported: There is no documentation or support for using Hydra as a library. All integration is expected to happen via its REST APIs, not by linking its code into your own application. - upgrades: Embedding Hydra would probably make it difficult to apply updates - security model: Hydra’s security model assumes it is running as an isolated service, with access control enforced at the network or API gateway level. Embedding it could break these assumptions and introduce new risks - architecture: Ory services are designed to be stateless, disposable, and to log to stdout/stderr. Embedding Hydra could complicate or break these patterns The recommended way to extend Hydra is to run additional services (such as login/consent apps) and integrate via APIs, not by modifying or embedding Hydra itself. The best practice is to run Hydra as a separate service and use an API gateway or reverse proxy to route requests between Hydra and your custom endpoints.