Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Nope. Data directories and compose files only.
This is how i do it. I can delete everything, repull and redeploy like nothing ever happened.
I have one exception and thats my calibre-web container. I have all my books backed up separately and I'll be nuking that whole set up eventually.
Curious, have you tested rebuilding using this approach?
It makes sense to me, if the compose files are up-to-date, it should just work.
I'd only be concerned about ensuring I capture changes made to the container that happened after initial build.
I feel like if that's something you're doing, you're using containers wrong. At least docker ones. I expect a container to have no state from run to run except what is written to mounted volumes. I should always be able to blow away my containers and images, and rebuild them from scratch. Afaik docker compose always implicitly runs with
--rmfor this reason.That's the secret. I never change the container.
If you absolutely must do some config on the container, then have a container creation script that creates a new container with the right settings and use that.
#pipelines
I can attest to it. Lately my server needed to be repaired and got its entire disk wiped. Fortunately I managed to back up my compose files and bind mounts. After reinstalling the OS and transferring the backed up contents, I ran 'docker compose up' and eventually everything came back up exactly how they were when being backed up. Even the Postgres backup of Joplin was recovered purely from its bind mount.