An offline reading feature would be great. Start the reader, mark some books for offline access, download them, go offline, read them, sync the page number with the server when back online.

Setting up a reverse proxy is a good way to access the server or container but I would recommend that nobody do this. I did a quick look through of the code on github and I would strongly advocate against exposing this server to the internet at this time even if it were situated behind a reverse proxy with an encrypted connection. The code is immature and not particularly well hardended, many error messages just spew out to Console and catch clauses are empty/non-logging and don't handle the error. There were several places in the repository pattern that gave me pause, and whilst there was only a limited number of ExecuteCommand invocations wrapped in a helper function, that is not to say there isn't a way to ExecuteCommand or perform other attacks. A malformed PDF, CBR or epub could easily fuzz this server. A VPN connecting to the server, or at the very least, symmetric challenge/response HTTPS with a client key requirement on the reverse proxy, with the server running in an isolated Docker container is the only way I'd expose this service.

P.S. I know you are the author of the code and not trying to state anything about the code, but merely that I would be careful exposing it to the internet at this time.

Wireguard to your home network is a must if you're into homelab/self-hosting, and no harder to set up than any one of the services you'll have set up on your home network. I love having direct access to my home network from my phone.

I do have a 'public' homeserver for two years now, so far so good.

Lets see if this jinxes it!