this post was submitted on 20 Dec 2025
82 points (83.1% liked)

Selfhosted

53833 readers
143 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
82
A self-hosted approach to long-term file storage and control (github.com)
submitted 2 days ago* (last edited 2 days ago) by expyth0n@lemmy.world to c/selfhosted@lemmy.world
27 comments fedilink hide all child comments
 

So, this whole thing kicked off because I hit a wall with local storage - it just doesn't grow with you forever, you know? Plus, putting all my eggs in the basket of other companies felt a bit risky with all the changing rules and government access stuff these days.

What I ended up with is pretty cool: a personal file vault where I'm in charge. It treats any outside storage like it can't be trusted, and all the encryption happens right on my computer. I can even use cloud storage like S3 if I need to, but I never lose control of my own data.

Honestly, it just kinda grew on its own; I never set out to build a product. I'm mainly sharing it here to see how other folks deal with these kinds of choices.

You can check it out at https://www.leyzen.com/

you are viewing a single comment's thread
view the rest of the comments
[–] expyth0n@lemmy.world 1 points 15 hours ago (1 children)

Here's a simple way to look at it: it's all about persistence. If someone sneaks a backdoor onto a server or inside a container, that backdoor usually needs the environment to stay put.

But with containers that are always changing, that persistence gets cut off. We log the bad stuff, the old container gets shut down, and a brand new one pops up. Your service keeps running smoothly for folks, but whatever the attacker put there vanishes with the old container.

It's not about saying hacks won't ever happen but making it way tougher for those hacks to stick around for long :)

[–] non_burglar@lemmy.world 1 points 14 hours ago (1 children)

That is not an answer.

Here's a simple way to look at it

I'm not looking for a simple way to look at it. I want a technical breakdown of why rebuilding back end instances is valuable in a security context.

  • When do the rebuilds occur? Are they triggered by some event?
  • what happens to session tokens?
  • do you have frontend / backend auth? What happens to that?
  • are you rotating secrets as well? Compromised back end would imply your secrets can no longer be trusted.
  • is data encrypted in massive blobs, or can one request only blocks of data?
  • can the app tune storage requirements depending on S3 configuration?

I'll be blunt with you: your answers to this and others have been very surface-level and scant on technical details, which gives a strong impression that you don't actually know how this thing works.

You are responsible for your output. If you want chatgpt or github ai tools to help you, that's fine, but you still need to understand how the whole thing works.

You are making something "secure", you need to be able to explain how that security works.

[–] expyth0n@lemmy.world 1 points 12 hours ago (1 children)

nobody here asked for technical details, so I didn’t respond with technical stuff. but now that you ask, I can respond:

  1. the rebuild occurs periodically. you set the period (in seconds) in the .env. a container named orchestrator stops and rebuilds vault containers by deleting every file that is not in the database and therefore not encrypted (like payloads). for event-based triggers, I haven’t implemented specific ones yet, but I plan to.

  2. session tokens are stored encrypted in the database, so when a vault container is rebuilt, sessions remain intact thanks to postgres.

  3. same as 2: auth tokens are stored in the database and are never lost, even when the whole stack is rebuilt.

  4. yes, but not everything. since one container (the orchestrator) needs access to the host’s docker socket, I don’t mount the socket directly. instead, I use a separate container with an allowlist to prevent the orchestrator from shutting down services like postgres. this container is authenticated with a token. I do rotate this token, and it is derived from a secret_key stored in the .env, regenerated each time using argon2id with random parameters. and i also use docker network to isolate containers that doesn't need to communicate between each other, like vault containers and the "docker socket guardian" container.

  5. every item has its own blob: one blob per file. for folders, I use a hierarchical tree in the database. each file has a parent id pointing to its folder, and files at the root have no parent id.

  6. can the app tune storage requirements depending on S3 configuration? not yet, S3 integration is a new feature, but I’ve added your idea to my personal roadmap. thanks.

and I understand perfectly why you’re asking this. No hate at all, I like feedback like this because it helps me improve.

[–] non_burglar@lemmy.world 2 points 12 hours ago

Thanks for the reply.