

Yeah, at that point I wouldn’t worry. If someone has docker access on the server, it’s pretty much game over.
Just a regular Joe.
Yeah, at that point I wouldn’t worry. If someone has docker access on the server, it’s pretty much game over.
Encryption will typically be CPU bound, while many servers will be I/O bound (eg. File hosting, rather than computing stuff). So it will probably be fine.
Encryption can help with the case that someone gets physical access to the machine or hard disk. If they can login to the running system (or dump RAM, which is possible with VMs & containers), it won’t bring much value.
You will of course need to login and mount the encrypted volume after a restart.
At my work, we want to make sure that secrets are adequately protected at rest, and we follow good hygiene practices like regularly rotating credentials, time limited certificates, etc. We tend to trust AWS KMS to encrypt our data, except for a few special use cases.
Do you have a particular risk that you are worried about?
Normally you wouldn’t need a secrets store on the same server as you need the secrets, as they are often stored unencrypted by the service/app that needs it. An encrypted disk might be better in that case.
That said, Vault has some useful features like issuing temporary credentials (eg. for access to AWS, DBs, servers) or certificate management. If you have these use-cases, it could be useful, even on the same server.
At my work, we tend to store deployment-time secrets either in protected Gitlab variables or in Vault. Sometimes we use AWS KMS to encrypt values in config files, which we checkin to git repositories.
Additional SPoFs: Your upstream internet connection, your modem/router, electricity supply, your home (not burning, flooded, collapsed, etc.). And you.
Ha, mia samideano! Tre bon’!
25 or so years ago, I learnt Esperanto (my first second language) by chatting on the Internet. I’d have two windows open - one with the IRC client, and the other with a terminal and a shell script that would grep a txt file with consistent formatting. “esp esperantoVerbPrefix/” or “esp noun,” or “esp affix-” would typically return the correct result in a split second. Thanks to the simple grammar (that I had quickly memorized), I could hold conversations in near real time as a result.
I wish I could have learnt my other languages as easily.
</story time>
NFSv3 (udp, stateless) was always as reliable as the network infra under Linux, I found. NFSv4 made things a bit more complicated.
You don’t want any NAT / stateful connection tracking in the network path (anything that could hiccup and forget), and wired connections only for permanent storage mounts, of course.
Welcome to the world of Carrier Grade NAT. 100.64.0.0/10 is reserved for this.
If you are lucky, you also have an IPv6 address. The catch is you need IPv6 on the client-side too.
A VPS or similar running wireguard and a proxy might bridge the gap.
It might also be possible to ask your provider for some port forwarding. Probably not, but check anyway.
Good luck!
Dynamic DNS is probably still required, unless his ISP issues dedicated or very long term IPv6 leases.
IPv6 may also “just work” nowadays, too, especially if the aim is to connect from mobile or other consumer networks. Corporate environments are still hit & mostly miss.
But not Fire tablets (kids profile) or Samsung TV or many others that Plex currently supports.
JellyFin android phone app’s UI is a little weird at times, but does work pretty well for me.
…
What I would adore from any app would be an easy way to upload specific content and metadata via SFTP or to blob storage and accessible with auth (basic, token, or cloud) to more easily share it with friends/family/myself without having to host the whole damn library on the Internet or share my home Internet at inconvenient times.
Client-side encryption would be a great addition to that (eg. password required, that adds a key to the key ring). And of course native support in the JellyFin/other apps for this. It could even be made to work with a JS & WASM player.