this post was submitted on 07 Dec 2023
93 points (97.9% liked)

Selfhosted

40394 readers
329 users here now

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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Hey guys, I'm new to self-hosting; I'm trying to set up cloud storage to store pics and other content. However, I’m unsure whether to use my old computer, Buy NAS or ResberryPie to set up a home server.

Also, what is the best privacy-friendly OS to use with the home server?

Lastly, do’s and don’ts.

Any help would be appreciated (:

you are viewing a single comment's thread
view the rest of the comments
[–] juli@programming.dev 35 points 11 months ago (1 children)

Use docker compose . Like "everyone" uses it. If the service doesn't have a compose file, request it, or write it yourself as son as you are knowledgable enough.

Use podman as soon as people and services switch to it (you'll know when the latest tutorials talk about podman instead of docker).

Use ngingx proxy manager or another easy to use reverse proxy.

Don't think it's production ready after it was working 2 days. It may be, but it's unlikely you have enough knowledge how to fix things.

Automatic updates.

Don't install crap on the system.

[–] scrubbles@poptalk.scrubbles.tech 10 points 11 months ago (1 children)

This is a good way to get started.

Docker and Docker compose on whatever hardware you want to start on.

Don’t think it’s production ready after it was working 2 days. It may be, but it’s unlikely you have enough knowledge how to fix things.

Most important there. You aren't building a production system for corporate clients, you're doing this for fun. Focus on one thing, try to get that one thing running. Toy with it, make it work. Then start on your next thing. Slowly you'll build up a large system, but it won't be immediate.

I personally have been working on switching from compose to kubernetes, which is way more advanced than a starter needs - but I've been slowly migrating for about 4 weeks now, one service at a time. Just how homelabs are done

[–] Kaldo@kbin.social 3 points 11 months ago (2 children)

What's the benefit of kubernetes over docker for a home server setup?

[–] scrubbles@poptalk.scrubbles.tech 4 points 11 months ago (1 children)

For home use? Barely any. You can use multiple computers to spread out your load, which is nice for me because I have about 20ish containers running with differing workloads.

But I'm also a developer who needs to keep up on devops, so it's mostly a learning thing for me. But I gotta say it's real nice having everything laid out in a few yaml files that I can tear down and rebuild on a whim

[–] Kaldo@kbin.social 1 points 11 months ago

having everything laid out in a few yaml files that I can tear down and rebuild on a whim

Oh absolutely, but for me docker compose already does that. Kubernetes might be a good learning exercise but I don't think I need load balancing for 1 user, me, on the home network 😅

[–] sudneo@lemmy.world 3 points 11 months ago

Some additional benefits also are the management of secrets. In compose you will shove them inside a .ENV file if not directly inside the compose file, while in Kubernetes you can use the secrets resource or even plug in Vault relatively easily. Stateful storage is also better handled. Named volumes are nasty to keep track of, backup and it's not possible to spread them across multiple devices (as in disks) while bind mounts are insecure in general. Kubernetes provides a storage abstraction which is easier to manage.

Obviously the big advantage comes when you want to run stuff on multiple devices to spread the load (or because the one box is saturated), since with compose you would need completely custom and independent setups.

Finally, I would say that running compose makes it much harder to have a monitoring stack supporting your services, since you will need to do all the plumbing for metrics endpoints yourself. And - very last - you can have admission controllers in Kubernetes that prevent certain configuration (e.g. Kyverno with a bunch of default policies), while with compose you need to manually vet every compose file and image (for example, to ensure it doesn't run as root).

That said, compose is perfect to get started and to run stuff on one machine.