Great. There’s two volumes there - firefly_iii_upload & firefly_iii_db.

You’ll definitely want to docker compose down first (to ensure the database is not being updated), then:

docker run --rm \
  -v firefly_iii_db:/from \
  -v $(pwd):/to \
  alpine sh -c "cd /from && tar cf /to/firefly_iii_db.tar ."

and

docker run --rm \
  -v firefly_iii_upload:/from \
  -v $(pwd):/to \
  alpine sh -c "cd /from && tar cf /to/firefly_iii_upload.tar ."

Then copy those two .tar files to the new VM. Then create the new empty volumes with:

docker volume create firefly_iii_db
docker volume create firefly_iii_upload

And untar your data into the volumes:

docker run --rm \
  -v firefly_iii_db:/to \
  -v $(pwd):/from \
  alpine sh -c "cd /to && tar xf /from/firefly_iii_db.tar"

docker run --rm \
  -v firefly_iii_upload:/to \
  -v $(pwd):/from \
  alpine sh -c "cd /to && tar xf /from/firefly_iii_upload.tar"

Then make sure you’ve manually brought over the compose file and those two .env files, and you should be able to docker compose up and be in business again. Good choice with Proxmox in my opinion.

I’m not clear from your question, but I’m guessing you’re talking about data stored in Docker volumes? (if they are bind mounts you’re all good - you can just copy it). The compose files I found online for FireflyIII use volumes, but Hammond looked like bind mounts. If you’re not sure, post your compose files here with the secrets redacted.

To move data out of a Docker volume, a common way is to mount the volume into a temporary container to copy it out. Something like:

docker run --rm \
  -v myvolume:/from \
  -v $(pwd):/to \
  alpine sh -c "cd /from && tar cf /to/myvolume.tar ."

Then on the machine you’re moving to, create the new empty Docker volume and do the temporary copy back in:

docker volume create myvolume
docker run --rm \
  -v myvolume:/to \
  -v $(pwd):/from \
  alpine sh -c "cd /to && tar xf /from/myvolume.tar"

Or, even better, just untar it into a data directory under your compose file and bind mount it so you don’t have this problem in future. Perhaps there’s some reason why Docker volumes are good, but I’m not sure what it is.

I’m local first - stuff I’m testing, playing with, or “production” stuff like Jellyfin, Forgeo, AudioBookshelf, Kavita etc etc. Local is faster, more secure, and storage is cheap. But then some of my other stuff that needs 24/7 access from the internet - websites and web apps - they go on the VPS.

I just do one Docker container per LXC. All the convenience of compose, plus those sweet Proxmox snapshots.

Is there a reason not to use Tailscale for this?

Forgejo - actively developed open source. It’s what powers Codeberg. Easy to set up and manage with Docker. I moved to it from Gogs and skipped Gitea after reading about the forks.

Yes, this.

Thanks - this is exactly what I needed.

Yes - we’re “I’ll let you use my electricity for your computer thing” friends, not “I’m okay with seeing your printer on my home network” friends.

Kavita is for ebooks - it’s not perfect, has some weirdness with series sometimes because of it’s manga heritage.

For me, AudioBookShelf is the clear standout for audio books, and I ended up going with Kavita for ebooks.

I have it in a git repo, broken down by the nodes and vps names. In each of these folders is a mixture of Ansible playbooks, docker compose or just markdown files with the descriptions. Some is random stuff - my VPS allows the export of the cloud firewalls as JSON for instance. All the secrets needed by Ansible are in an Ansible vault, the rest in KeePass.

I like data, I like tech, I like investing large amounts of time and energy to self-host things that muggles would not bother with.

I mean, yes, I could. But I’m committed to the #selfhosted life where I spend hours building unnecessarily complicated systems to make my life easier in small ways.

The process for this is to obtain an EPS32 with bluetooth and wifi, pair it to the scale with bluetooth then keep it powered on in range of the scale, then the data goes into HA?

I have the opposite experience of this. All of my local services are a single docker container inside an LXC. I don’t like that it’s conceptually messy, but in practice it’s easy to manage. What I love about it is the simplicity of backing up or moving the entire LXC between servers.

I’ve not had any drama with things breaking across Proxmox updates. The only non-gui thing I need to do during the process is adding two lines to the LXC conf to have Tailscale work correctly.

No one’s mentioned Forgejo yet? Solid git and artifact repository.

Two good points here OP. Type docker image ls to see all the images you currently have locally - you’ll possibly be surprised how many. All the ones tagged <none> are old versions.

If you’re already using github, it includes an package repository you could push retagged images to, or for more self-hosty, a local instance of Forgejo would be a good option.

Guide to Self Hosting LLMs with Ollama.

• Download and run Ollama
• Open a terminal, type ollama run llama3.2