I’ve been wanting to set up gitea on fly for a while, but their lack of disaster recovery options has prevented me from doing so. I don’t want to have to open a support request to get a volume restored.
Author here, this is definitely something that I’d like to be more prepared for. I’d be interested in trying to put together a proof of concept of a more cohesive disaster recovery plan for Gitea-on-fly (and maybe fly generally… e.g. I want to be confident I won’t lose my Vaultwarden data), do you have any pointers to a comparable platform with a really good story for this sort of thing?
No, I don’t have any pointers to other good stories that I can think of currently. Fly also is a bit unique in my perspective when it comes to platforms. I really like that uniqueness, but it also means they’re pushing some boundaries that others aren’t.
Gitea should be relatively trivial to backup and restore when using the sqlite db you have configured. They do appear to have a backup/restore doc: https://docs.gitea.io/en-us/backup-and-restore/
For my current on-prem instance I’ve just been taking filesystem backups without those dump steps. I’m mostly concerned about the repos themselves, which are just stored in bare repos on the filesystem from what I can tell.
Thanks for the post. I really like Gitea and hope it inspires more people to use it.
I agree that workflow with Proxmox is not easy, but also not impossible. I have had good success with using Terraform and the Telmate Proxmox plugin, but the available tools are still lacking in certain features.
I have struggled with this many times of putting it in the “cloud” vs. my box at home…. the box at home always seems to win for me in the end.
I tried following this guide, but my gitea instance just ran out of memory when I tried pushing my first commit to it.
But thanks for pointing out fly.io! I discovered a lot of nice use cases (like hosting uptime kuma, testing to host my static blog et c) which seems to work fine this far.
Oh man, I totally need to update the guide to mention this. The same thing happened to me when setting this up. Gitea needs JUST BARELY over 256 MB for certain operations, so you can use the Fly dashboard or flyctl to scale it to a 512 MB instance. Technically, you will start accruing a bill, but the cost will be so small that you will probably get an email from Fly at the end of the month saying they won’t charge you at all (assuming your other usage is modest as well).
I’ve been wanting to set up gitea on fly for a while, but their lack of disaster recovery options has prevented me from doing so. I don’t want to have to open a support request to get a volume restored.
They’ve made progress in this area, but it still feels very immature to me. https://fly.io/blog/volumes-expand-restore/
Author here, this is definitely something that I’d like to be more prepared for. I’d be interested in trying to put together a proof of concept of a more cohesive disaster recovery plan for Gitea-on-fly (and maybe fly generally… e.g. I want to be confident I won’t lose my Vaultwarden data), do you have any pointers to a comparable platform with a really good story for this sort of thing?
No, I don’t have any pointers to other good stories that I can think of currently. Fly also is a bit unique in my perspective when it comes to platforms. I really like that uniqueness, but it also means they’re pushing some boundaries that others aren’t.
Gitea should be relatively trivial to backup and restore when using the sqlite db you have configured. They do appear to have a backup/restore doc: https://docs.gitea.io/en-us/backup-and-restore/
For my current on-prem instance I’ve just been taking filesystem backups without those dump steps. I’m mostly concerned about the repos themselves, which are just stored in bare repos on the filesystem from what I can tell.
Thanks for the post. I really like Gitea and hope it inspires more people to use it.
I agree that workflow with Proxmox is not easy, but also not impossible. I have had good success with using Terraform and the Telmate Proxmox plugin, but the available tools are still lacking in certain features.
I have struggled with this many times of putting it in the “cloud” vs. my box at home…. the box at home always seems to win for me in the end.
Nice. This makes me wish flyctl would build and run on OpenBSD. I can see how it has it uses.
I tried following this guide, but my gitea instance just ran out of memory when I tried pushing my first commit to it.
But thanks for pointing out fly.io! I discovered a lot of nice use cases (like hosting uptime kuma, testing to host my static blog et c) which seems to work fine this far.
Ok, I added a new section at the end to address this issue:
https://mat.services/posts/gitea-on-fly-io/#the-first-push-or-256mb-just-isn-t-enough-sometimes
Oh man, I totally need to update the guide to mention this. The same thing happened to me when setting this up. Gitea needs JUST BARELY over 256 MB for certain operations, so you can use the Fly dashboard or flyctl to scale it to a 512 MB instance. Technically, you will start accruing a bill, but the cost will be so small that you will probably get an email from Fly at the end of the month saying they won’t charge you at all (assuming your other usage is modest as well).