Proton’s server is closed source so I don’t trust it as much as Bitwarden.

My Epyc 7702 does have onboard TPM, but my supermicro H11DSi-NT doesn’t pass it through to the OS, for some reason

Huh… That’s interesting. At my workplace we have Linux EPYC servers with working TPM (it’s mandated that all computers, both clients and servers, must have TPM 2.0), but I’m not a hardware person and don’t know exactly how they’re configured.

This is good to know. I haven’t had issues with using a USB drive though, since it doesn’t receive many reads or writes - the system is copied to a RAM drive on boot and runs off that rather than the USB.

I assume this means I’d need another drive to boot it from? My current setup is that I have 2 x 22TB drives in a ZFS mirror for data storage, and 2 x 2TB NVMe SSDs in a ZFS mirror for things like VMs, Docker containers, documents, etc.

I had to get a Supermicro AOM-TPM-9665V TPM chip for my motherboard

How old is your CPU that it doesn’t have onboard TPM? It’s been a standard feature for quite a while now

Bitwarden’s the only “cloud-based” password manager I trust, since their entire stack is open-source.

For self-hosting, they recently released Bitwarden Lite, which is a lot simpler to host than their regular server. One Docker image and you can use SQLite for the database. Different design decisions compared to the regular server which is designed to scale up to handle businesses with tens or hundreds of thousands of employees.

There’s also Vaultwarden, which is an unofficial third-party server implementation.

This isn’t too bad if you’re running Docker in rootless mode.

Adding a user to the docker group while running Docker as root doesn’t really make sense though, since it makes it trivial to run things as root.

You need to use hooks to actually block it from doing things. CLAUDE.md files are just guidance, and it’s not guaranteed to follow everything (and the longer the file gets, the more likely it’ll ignore stuff - it should be kept as short as possible)

https://code.claude.com/docs/en/hooks

Hooks are code that runs at a certain point (eg after you submit a prompt, before a tool call, after a turn, etc) that can do some validation, verification, logging, etc.

It does still try to work around the blocks though, but it’s not as bad as trying to put the restrictions in the prompt.

Giving Docker access to Claude is certainly a choice.

Unfortunately the search tooling is specific to our internal systems. It’s essentially just a cronjob that periodically indexes the entire repo and a backend service to do the search.

ag / rg don’t work well in this particular scenario either. Because files are loaded on-demand, they end up trying to load the entire repo.

It makes sense… There’s a LOT of examples of using CLI tools in the training data. At work we’re moving away from MCP tools to instead using CLIs for everything.

Claude is very good at figuring out how to work around limitations (which is probably one reason why it’s also good at finding security issues).

At work, the monorepo is enormous and files are loaded on-demand as needed. This isn’t uncommon with huge repos - Microsoft have VFS for Git (although I hear that’s deprecated now), Meta have EdenFS, and Google has some proprietary solution.

We have a hook that blocks find and grep because they can be extremely slow, and tells it to instead use some significantly faster MCP tools to search the codebase, powered by a search index with local changes overlaid.

GPT-5.5 has no problem with this. Claude Opus mostly does it, but sometimes it loves to find workarounds rather than following the instructions. Things like: Try alternative commands like egrep. Create a symlink to grep and run that to see if it bypasses the filtering. Run it with a different shell like zsh. Write a Python script that execs grep. Write a Python script to reimplement grep.

I’m trying Hermes Agent at home, but I have it in its own VM with restricted permissions.

Claude is very good at figuring out how to work around limitations (which is probably one reason why it’s also good at finding security issues).

At work, the monorepo is enormous and files are loaded on-demand as needed. This isn’t uncommon with huge repos - Microsoft have VFS for Git (although I hear that’s deprecated now), Meta have EdenFS, and Google has some proprietary solution.

We have a hook that blocks find and grep because they can be extremely slow, and tells it to instead use some significantly faster MCP tools to search the codebase, powered by a search index with local changes overlaid.

GPT-5.5 has no problem with this. Claude Opus mostly does it, but sometimes it loves to find workarounds rather than following the instructions. Things like: Try alternative commands like egrep. Create a symlink to grep and run that to see if it bypasses the filtering. Run it with a different shell like zsh. Write a Python script that execs grep. Write a Python script to reimplement grep.

I’m trying Hermes Agent at home, but I have it in its own VM with restricted permissions.

Interesting… The file sharing is extremely quick for me at home.

I haven’t figured out how to get it working at work though (between my work phone and my work PC, both on the same network). Might not be possible with their firewalls.

Have you tried KDE Connect? It’s cross platform and works on Linux, Windows, MacOS, Android, and iOS. It’s what I use for sharing files from my phone to my computer and vice versa. It supports a lot more than just file sharing though.

I never said anything about using the VPN as an ACL. All I said was to only expose the service over the VPN. That doesn’t necessarily mean that the app doesn’t have authentication or authorization.

I’m also only talking about residential use cases, where it’s a common practice (when not using a VPN) to just expose everything via port forwarding. Businesses aren’t setting up Jellyfin on their servers.

true, fun fact a VPN is also an application with an auth layer. dun dun dun!

Sure, but someone would have to first get on the VPN, and then find vulnerable apps once on the internal network, as opposed to just scanning the internet for public-facing vulnerable systems. Wireguard (and thus Tailscale) doesn’t respond to port scans at all - it only responds to packets that are signed with a known key.

Admittedly, networking and network security isn’t my specialty so I’m absolutely sure you’ve got more knowledge in this area.

If a service is publicly accessible, anyone can access it. Even if it’s secured, there can be security issues in the auth layer of the app, improperly secured endpoints, etc.

If a service is only available over VPN, nobody can access it unless they’re on the VPN. The service isn’t visible over the public internet and other people won’t even know it exists. You can require two factor auth to connect to the VPN.

I’m not sure why you seem to think that a private network isn’t more secure than a public network. There’s a reason why practically every company requires people working remotely to connect to a VPN to access company resources.

It’s a good practice to NOT expose services to the internet unless it’s really needed. If they’re only for your use, then the entire world doesn’t need access. This isn’t specific to Jellyfin.

All software has the potential to have security issues.

It’s not really a hassle though. It’s just a one time setup. Tailscale can stay connected all the time, since by default only Tailscale IPs are routed via it (so it won’t affect LAN or internet access)

If you want less hassle then use a Debrid service like Premiumize or Real-Debrid.

You can avoid most security issues (with any sort of server) by not exposing it publicly. Use a VPN like Tailscale to connect remotely. If you share the server with friends or family, share it with them over Tailscale and use an ACL to configure which services they can access on your server.