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.
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
Are you asking me what i plan to set the cap to? I guess just me. I cant see anyone else wanting to run off a pi from my house and there are so many other instances to join.
I’m a newbie here but what would be the benefit of running an instance just for yourself?
The ability to host your own data - both for privacy, and insurance that the instance you host your account in won’t suddenly disappear.
That, and somehow I think it's nice to be able to federate with a username within your own domain when you have one. (or multiple, decisions, decisions, which one to pick ;) )
I would also add that Lemmy is part of the fediverse, meaning it is federated. Federation means all instances "talk" to all instances (unless they defederate), so you aren't limited only to the content on one instance (or in some cases not even Lemmy, case in point: I'm posting this from my kbin.social account).
same!
What happens to posts/comments and any media/content that is hosted on a server that just goes away (for example if I created one virtually and then deleted it or if a sdcard on a pi is corrupted)
If you upload an image to that server, the image will be gone. Your comments will still exist on other federated instances, assuming that instance was federated in the first place. But any replies to those communities will not propagate once the hosting instance is offline.
For example assume you have 3 instances, A, B, and C. You have an account on A and create a post to a community on A. At some point A goes away, but those posts and that community will still exist on B and C. So you create a new account on B, and reply to one of those posts... users on C won't be able to see those replies as A isn't there to broadcast those replies out. And if someone on C creates a new post on that community from A, you wouldn't be able to see it on B either.
P.S. The same is true if A just decides to defederate instead of shutting down. (other than the images and accounts would still exist obviously).
No, I meant what is the user limit based on the power of the raspberry pi tech specs.
Basically the limit would be the speed of the database and the drive it runs on. If you connect a SATA SSD via usb3 it shouldn't be too bad. Can't tell you exact figures but a few hundred users is probably ok if you don't expect the site to be super responsive.
Thanks. Might be useful for there to be a table outling diffrent hardware configs and acceptable user loads as more people people consider creating instances.
its difficult because different users have different usage patterns.
for example, two users who never post and are never online at the same time really take no resources from each other. they are effectively "one" user.
one user who posts 10gb of content a day, and is constantly posting would be equivalent to hundreds of "normal" users.
Yes, sure, didn't want to complicate the question by adding that :)