Okay so your post inspired me to make the switch. All I had to do was switch out the image to the forgejo one. Everything worked right away. To try to make things as clean as possible, I went ahead and renamed my bind volume paths and app.ini stuff from gitea to forgejo but no matter what I tried, once I started the container, the container would create a gitea directory with a new app.ini. I even tried to run the forgejo compose on another host and the app still creates a gitea directory within the bind mount. Am I doing something wrong. I understand it’s a drop in replacement but I’m sure there’s a way to get a cleaner cut over.
compose.yml
volumes:
./data:/data
Host directories
~/forgejo
data
- forgejo - renamed for the migration
- git
- ssh
- gitea - gets created by the app no matter what I do or what paths are set in app.ini
compose.yml
How do I keep forgejo from creating this gitea directory? Why doesn’t it create a forgejo directory???
Edit: gitea version was - 1.21.7 and forgejo replacement image is 1.21.7-0
This does look super nice but I need to have it centralized. We use multiple devices to do various things and will need to access this from all machines. So close!!!
“Just to be clear I just need to track my sales/revenue (even if input is manual) and track expenses (bonus if I could upload a picture of a receipt).
I don’t need to actually send an invoice (I do this straight from my website and it’s a seamless integration so not looking to reinvent this wheel, yet!)
Given the above, is in InvoiceNinja still a good candidate?”
Just to be clear I just need to track my sales/revenue (even if input is manual) and track expenses (bonus if I could upload a picture of a receipt).
I don’t need to actually send an invoice (I do this straight from my website and it’s a seamless integration so not looking to reinvent this wheel, yet!)
Given the above, is in InvoiceNinja still a good candidate?
Great suggestion. Not sure why I didn’t think of it. It’s one of my first stops for this kind of stuff. I did check out this site which is how I found Akaunting.
Honestly, if you have never used containers before I would suggest starting with docker as it has more readily accessible beginner walk through and tutorials. From there, you will have a good idea as to switching to podman is the right move for you or not.
Personally, I started with docker and haven’t moved from there since I don’t see a need (yet). I have dozens of services running on docker. I don’t know how heavy of a lift it would be to learn podman but like I said, I don’t feel the need to do so.
Maybe try out both and see which one you like more?
Interesting tidbit about the performance. It has been a bit of challenge getting “up to speed” with Incus/LXD from a guide and walkthrough perspective. Although I do find their documentation pretty well organized and useful.
Well that’s kinda why I came here to the greater community as I wasn’t really sure if there would be any performance gains or other upsides I’m not aware of. Based on general feedback, it appears that there’s no clear upside to incus.
That’s another fair point. I do have a couple of pi’s collecting dust. As someone else stated, I need to consider the time it takes me to get up to speed with incus. Can you elaborate on your experience going “from 0 to hero” with incus? Just curious.
Fair point. I’m most familiar with docker and proxmox. Sorta doing it for educational purposes but I also have critical services (critical to me) running that must be available.
Strictly from a container perspective, wouldn’t this workflow create more overhead? For example, an incus cluster for me it would be Debian hosts (layer 1), incus (layer 2), lxd container (layer 3), docker (layer 4), app/service (layer 5). A Docker Swarm cluster (for me) would be Debian hosts (layer 1), docker (layer 2), app/service (layer 3).
Granted a docker swarm cluster would negate the possibility of VMs without having to install something else on the hosts but asking since I’m trying to keep my services in containers.
Haven’t really looked into Podman as I read somewhere (if I remember correctly) that it takes quite a bit of rewrite (from docker compose to podman). Again, might be speaking out of turn here.
You are probably right. Judging by their GitHub repo, their first release was in October of 2023. If I understand correctly, Incus is a fork of Canonical LXDs which is not so new??? Idk. Their documentation is quite good but there aren’t a lot of “guides” out there so yea.
Okay so your post inspired me to make the switch. All I had to do was switch out the image to the forgejo one. Everything worked right away. To try to make things as clean as possible, I went ahead and renamed my bind volume paths and app.ini stuff from gitea to forgejo but no matter what I tried, once I started the container, the container would create a gitea directory with a new app.ini. I even tried to run the forgejo compose on another host and the app still creates a gitea directory within the bind mount. Am I doing something wrong. I understand it’s a drop in replacement but I’m sure there’s a way to get a cleaner cut over.
compose.yml
volumes:
Host directories
~/forgejo
How do I keep forgejo from creating this gitea directory? Why doesn’t it create a forgejo directory???
Edit: gitea version was - 1.21.7 and forgejo replacement image is 1.21.7-0