When I was starting out I almost went down the same pathway. In the end, docker secrets are mainly useful when the same key needs to be distributed around multiple nodes.

Storing the keys locally in an env file that is only accessible to the docker user is close enough to the same thing for home use and greatly simplifies your setup.

I would suggest using a folder for each stack that contains 1 docker compose file and one env file. The env file contains passwords, the rest of the env variables are defined in the docker compose itself. Exclude the env files from your git repo (if you use this for version control) so you never check in a secret to your git repo (in practice I have one folder for compose files that is on git and my env files are stored in a different folder not in git).

I do this all via portainer, it will setup the above folder structure for you. Each stack is a compose file that portainer pulls from my self hosted gitea (on another machine). Portainer creates an env file itself when you add the env variables from the gui.

If someone gets access to your system and is able to access the env file, they already have high level access and your system is compromised regardless of if you have the secrets encrypted via swarm or not.

True, but the downside of cloudflare is that they are a reverse proxy and can see all your https traffic unencrypted.

I like finamp as my android music client for jellyfin

I world strongly suggest a second device like an RPI with Gitea. There what I have.

I use portainer to pull straight from git and deploy

Not to mention the advantage of infrastructure as code. All my docker configs are just a dozen or so text files (compose). I can recreate my server apps from a bare VM in just a few minutes then copy the data over to restore a backup, revert to a previous version or migrate to another server. Massive advantages compared to bare metal.

Yes, you should use something that makes sense to you but ignoring docker is likely going to cause more aggravation than not in the long term.

There is an issue with your database persistence. The file is being uploaded but it’s not being recorded in your database for some reason.

Describe in detail what your hardware and software setup is, particularly the storage and OS.

You can probably check this by trying to upload something and then checking the database files to see the last modified date.

If you are willing to spend a bit more upfront, I bought a mini PC in 2017 and installed opnsense on it. It’s still rock solid. For wifi, I use a separate ap (a ubiquity UAP that I bought in 2015) and it is also going strong. Almost a decade of rock solid performance easily beats out any other router I’ve owned in terms of both performance and cost.

Thanks! Makes sense if you can’t change file systems.

For what it’s worth, zfs let’s you dedup on a per dataset basis so you can easily choose to have some files deduped and not others. Same with compression.

For example, without building anything new the setup could have been to copy the data from the actual Minecraft server to the backup that has ZFS using rsync or some other tool. Then the back server just runs a snapshot every 5 mins or whatever. You now have a backup on another system that has snapshots with whatever frequency you want, with dedup.

Restoring an old backup just means you rsync from a snapshot back to the Minecraft server.

Rsync only needed if both servers don’t have ZFS. If they both have ZFS, send and recieve commands are built into zfs are are designed for exactly this use case. You can easily send a snap shot to another server if they both have ZFS.

Zfs also has samba and NFS export built in if you want to share the filesystem to another server.

I use zfs so not sure about others but I thought all cow file systems have deduplication already? Zfs has it turned on by default. Why make your own file deduplication system instead of just using a zfs filesystem and letting that do the work for you?

Snapshots are also extremely efficient on cow filesystems like zfs as they only store the diff between the previous state and the current one so taking a snapshot every 5 mins is not a big deal for my homelab.

I can easily explore any of the snapshots and pull any file from and of the snapshots.

I’m not trying to shit on your project, just trying to understand its usecase since it seems to me ZFS provides all the benefits already

Start with this to learn how snapshots work

https://fedoramagazine.org/working-with-btrfs-snapshots/

Then here the learn how to make automatic snapshots with retention

https://ounapuu.ee/posts/2022/04/05/btrfs-snapshots/

I do something very similar with zfs snapshots and deduplication on. I have one ever 5 mins and save 1 hr worth then save 24 hourlys every day and 1 day for a month etc

For backup to remote locations you can send a snapshot offsite

This is really amazing! In theory, can you can use 2gb with 4 different VMs?

The proper way of doing this is to have two separate systems in a cluster such as proxmox. The system with GPUs runs certain workloads and the non GPU system runs other workloads.

Each system can be connected (or not) to a ups and shut down with a power outage and then boot back up when power is back.

Don’t try hot-plugging a gpu, it will never be reliable.

Run a proxmox cluster or kubernetes cluster, it is designed for this type of application but will add a fair amount of complexity.

First thing I would do is boot a live Ubuntu image from a USB. Make sure the hardware all works as expected.

Seafile works very well for this. They have a traditional sync app for desktop (seafile client) and they also have on demand file browser that let’s you make some file local if you want (seadrive). Its quite slick.

Does anyone know if these ai chips will be good at transcoding (jellyfin) or facial detection on a security camera (frigate). Seems these might be good for homelabers.

I thought for sure the camera was toast when it went all purple, it looks like the lense was essentially gone and we are just seeing the raw output of the CCD but then the flap moved and there was a few frames where you could actually see the flap and the damage but it’s still actuating!

Amazing engineering.

There is essentially no better data that this regarding what the error tolerance is on the flaps. Should help create lots if reliability in future versions

These are prototype rockets. They iterate so fast the they already have new designs that make this one obsolete. It’s purpose was to gather data on the various things including heat tile performance so they know what to upgrade next.

The next one that flies will also be obsolete with a newer one already partially completed.

The Apollo compairaon above is even more ridiculous when you consider that starship made it to orbit and could’ve deployed a payload. The part that ‘failed’ was the soft landing and even that didn’t fail. Only reuse failed.

Every Saturn v that was launched is currently sitting at the bottom of the ocean.

Taking shots at starship for failing even though Saturn v didn’t even attempt the same mission parameters makes no sense.

Starship will have likely had 100+ missions before putting a human on it. Would you rather fly on something that’s proven itself 100 times or something that is flying for the first time?

I think the biggest thing you’re not taking into account is the amount hardware they have compared to anyone else.

Of course Apollo would be shut down if they were loosing Saturn Vs left and right. Each of those is 1.2 billion in 2019 dollars and they launched 13 of them I’m total. They are way to valuable.

The total estimate cost to date for the entire starship program is 5 billion and they have built around 30 starships. They already have another one ready to go now, only reason to not launch right away is because it needs upgrades based on the data they just collected.

You’re also assuming that with more time and analysis they could predict things they have just discovered from a real launch. No man made object of this size has ever made a controlled entry back to earth. Not by a long shot.

Closest is space shuttle which had lots of issues that couldn’t be fixed because each launch was so expensive it had to carry real payload (and people) and changes to human flight hardware is near impossible.

The main thing that’s different here is that the cost of a launch is way less than the cost of a year of lab testing and still not knowing the answer because it’s never been done before. That’s the hardest paradigm shift to accept and is true only of SpaceX and no one else right now until they go full force into reusable rockets.