

I don’t know where you’re seeing this, maybe this is a Fediverse thing, but I’m literally on Selfhosted@lemmy.world right now.


I don’t know where you’re seeing this, maybe this is a Fediverse thing, but I’m literally on Selfhosted@lemmy.world right now.


That’s great for production AWS managed services, but that still sounds like the opposite of self-hosting to me, I don’t need scaling like that, I’m not lying when I admit I’m using sshfs (which was a slightly tongue-in-cheek counterpoint to s3) and despite everyone dunking on it, it is in fact working perfectly at my scale. I know I’ve been downvoted to purgatory but I still stand by my original comment. I don’t understand why you would need S3 or S3 compatibility in a self-hosting context. The closest someone has come to explaining it is the guy who said choice is good… like, yeah, it’s good to have the choice I guess, but… still doesn’t seem like a great choice for self-hosting. I appreciate you trying to explain it but I feel like everyone is missing the self-hosting context here. For a little home lab I simply don’t see the value. Why are people promoting AWS and AWS-adjacent services here?


So enlighten me then, save me from my terrible hack that is working fine for me and tell me what it DOES have to do with. I thought S3 was a remote filesystem you can use, essentially Amazon’s proprietary version of webdav where you get a http bucket you can only access with aws proprietary tools. What’s the attraction? Clearly it seems like people love it, and I am getting dunked on for asking an honest question, which feels a bit unhealthy and unpleasant for the self-hosting community.
Am I supposed to be familiar with AWS infrastructure as a prerequisite for being here?


S3 compatibility is nice I guess if you need S3 compatibility but also… why would you need that?
sshfs does everything I need and compatibility is almost native.
He’s still right that it’s weird people like you are going to bat to defend them. Microsoft sucks. It must get tiring if you have to call out every inaccurate thing everyone says to try to tear them down. The important take-home message is that we need to tear them down, they suck.
You don’t see people bothering to defend Epstein, for example. Even though there’s lots of inaccurate stuff going around, there’s enough accurate stuff to be absolutely confident he was an absolute loathsome piece of shit not worth defending. Not worth the effort to defend. Why bother?
What do you see in Microsoft that you think is worth defending? Github is shit, and it’s evil. Let it go.
Private trackers are like the Matrix’s “zion”. When civilization collapses into a dystopian surveillance capitalism hellscape and the AIs and fascist governments take over the net, the last free humans will be hiding in private tracker communities, sharing freely and building a resistance. Will we have mechs with gatling guns? I don’t know, all I can say is I hope so because it looks like we’re going to need it.
Like nuclear fusion, IPv6 is one of those things that feels like it’s constantly about 20 years away, no matter how long we work on it.
homelab is a form of self-hosting and vice versa as far as I’m concerned. Ask away, I’ve never seen that rule being strictly enforced and I don’t think the lemmy community is honestly large enough to support such a rule. It was probably migrated over from Reddit where there were viable communities for all those things.


In that case I’d definitely recommend taking a look at pi, it’s a fairly minimal and controllable starting point where you’re in the driver’s seat at all times and most “features” are opt-in and handled responsibly. And since it’s extensible you can even use plugins like the ones here to do things like add more protections against undesired actions if you want and if that is too minimal and you eventually realize you want something a little bit more like OpenClaw you might want to look into Hermes-Agent, which has similar comprehensiveness to OpenClaw but seems to be a lot more responsibly designed. I don’t have any personal experience with it but that seems to be what most of the “security-thoughtful AI keeners” (which I feel is a bit of a contradiction but people seem to be having some success with it) are using these days.


Absolutely. There are tons of open-licenced, open-weight (the equivalent of open-source for AI models) models capable of what is called “tool usage”. The key thing to understand is that they’re never quite perfect, and they don’t all “use tools” quite as effectively or in the same way as each other. This is common to LLMs and it is critical to understand that at the end of the day they are just text generators, they do not “use tools” themselves. They create specific structured text that triggers some other software, typically called a harness but could also be called a client or frontend, to call those tools on your system. Openclaw is an example of such a harness (and not a great or particularly safe one in my opinion but if you want to be a lunatic and give an AI model free reign it seems to be the best choice) You can use commercial harnesses too by configuring or tricking them into connecting to a local model instead of their commercial one, although I don’t recommend this for a variety of reasons if you really want to use claude code itself people have done it but I don’t find it works very well since all its prompts and tool calling is optimized for Claude models. Besides OpenClaw, Other popular harnesses for local models include OpenCode (as close as you’re going to get to claude for local models) or Cursor, even Ollama has their own CLI harness now. Personally I use OpenCode a lot but I am starting to lean towards pi-mono (it’s just called pi but that’s ungoogleable) it is very minimal and modular, making it intentionally easy to customize with plugins and skills you can automatically install to make it exactly as safe or capable or visual as you wish it to be.
As a minor diversion we should also discuss what a “tool” is, in this context there are some common basic tools that some or most tool-use models will have or understand some variation of, out of the box. Things like editing files, running command-line tools, opening documents, searching the web, are common built-in skills that pretty much any model advertising itself capable of “tool use” or “tool calling” will support, although some agents will be able to use these skills more capably and effectively than others. Just like some people know the Linux commandline fluently and can completely operate their system with it, while others only know basic commands like ls or cat and need a GUI or guidance for anything more complex, AI models are similar, some (and the latest models in particular) are incredibly capable with even just their basic built-in tools. However they’re not limited by what’s built in, as like I said, they can accept guidance on what to use and how to use it. You can guide them explicitly if you happen to be fluent in their tools, but there are kind of two competing models for how to give them that guidance automatically. These are MCP (model context protocol) which is a separate server they can access that provides structured listings of different kinds of tools they can learn to use and how they work, basically allowing them to connect to a huge variety of APIs in almost any software or service. Some harnesses have an MCP built-in. The other approach is called “skills” and seems to be (to me) a more sensible and flexible approach to giving the AI model enough understanding to become more capable and expand the tools it can use. Again, providing skills is usually something handled by the harness you’re using.
To make this a little less abstract you can put it in perspective of Claude: Anthropic provides several different Claude models like Haiku, Sonnet, and Opus. These are the text-generation models and they have been trained to produce a particular tool usage format, but Opus tends to have more built-in capability than something like Haiku for example. Regardless of which model you choose though (and you can switch at any time) you’ll be using a harness, typically “claude code” which is typically the CLI tool most people use to interact with Claude in an agentic, tool calling capacity.
On the open and local side of the landscape, we don’t have anything quite as fast or capable as Claude code unfortunately, but we can do surprisingly okay considering we’re running small local models on consumer hardware, not massive data center farms being enticingly given away or rented for pennies on the dollar of what they’re actually costing these companies on the hopes of successful marketshare-capture and vendor-lock-in leading to future profits.
Here are some pretty capable tool-use models I would recommend (most should be available for download through ollama and other sources like huggingface)
Great news! Also thanks for providing the follow-up, hopefully it helps people who use Unraid in the future.
You can do all those things with proper routing and there is no difference from mobile devices (as long as they use DHCP and what mobile device wouldn’t?). What I’m suggesting does not change anything on the public side. You still authenticate publicly to renew your certificates. You still give the same certificates to both public and local networks. They’re still valid. Nothing changes.
The only difference is that when you’re local, your DNS gives you the correct local IP address where that service is hosted, say, 192.168.12.34 instead of using public DNS, getting an external IP that’s on the wrong side of the router, and having to go outside your own network and come back in. Hairpin is like that simpsons episode where Abe goes in the revolving door, takes off his hat, puts his hat back on, and goes back out the same revolving door in the span of 2 seconds. It’s pointless, why are you doing that? If you didn’t want to be on the outside of the network, why are you going to the outside of the network first? Just stay inside the network. Get the right IP. No hairpin routing needed. No certificate madness needed. Everything just works the way its supposed to (because this is in fact the way it’s supposed to work)
Convenience is great until it becomes inconvenient. But that’s a journey we all make :)
I’m not too familiar with unraid but from a little research I just did it seems like you’re right. That does seem like a really unfortunate design decision on their part, although it seems like the unraid fans defend it. Obviously, I guess I cannot be an unraid fan, and I probably can’t help you in that case. If it were me, I would try to move unraid to its own port (like all the other services) and install a proxy I control onto port 443 in its place, and treat it like any other service. But I have no idea if that is possible or practical in unraid. I do make opinionated choices and my opinion is that unraid is wrong here. Oh well.
I’d argue that your internally hosted site should not be published on ports other than 80/443. Published is the key word here, because the sites themselves can run on whatever port you want and if you want to access them directly on that port you can, but when you’re publishing them and exposing them to the public you don’t want to be dealing with dozens of different services each implementing their own TLS stack and certificate authorities and using god-knows-what rules for security and authentication. You use a proxy server to publish them properly. And there’s no reason you can’t or shouldn’t use that same interface internally too. Even though you technically might be able to directly access the actual ports the services are running on on your local network, you really probably shouldn’t, for a lot of reasons, and if you can, maybe consider locking that down and making those services ONLY listen on 127.0.0.1 or isolated docker networks so nothing outside the proxy host itself can reach them.
If you don’t want your services to listen on 80/443 themselves that’s reasonable and good practice, but something should be, and it should handle those ports responsibly and authoritatively to direct incoming traffic where it needs to go no matter the source. Even if (or especially if) you need to share that port with various other services for some reason, then either way you need it to operate that port as a proxy (caddy, nginx, even Apache can all do this easily). 443 is the https port, and in the https-only world we should all be living in, all https traffic should be using that port at least in public, and the https TLS connection should be properly terminated at that port by a service designed to do this. This simplifies all sorts of things, including domain name management and certificate management.
tl;dr You should have a proxy that publishes all your services on port 443 according to their domain name. When https://photos.mydomain.com/ comes in, it hits port 443 and the service on port 443 sees it’s looking for “photos”, handles the certificates for photos, and then decides that immich is where it is going and proxies it there, which is none of anyone else’s business. Everyone, internal or external, goes through the same, consistent, and secure port 443 entrance to your actual web of services.


Nextcloud, CalDAV, Thunderbird.
Opinionated wall of text incoming:
Hairpin is an annoying hack. It happens and is necessary when you are getting a public IP from DNS but the service is not actually listening on that address itself, because the router owns that address, and that address is actually on the other side of the router, the public-facing side, not the side you’re on, so now you have to go out to the public side of the router, turn around (the hairpin turn) and come back in as if you were a public user in order to get to a service that was literally sitting right next to you (on the private side) the whole time.
What you should do instead: You should have your own internal DNS for your own personal network that resolves the DNS properly within the context of that network. This avoids needing to use hairpin at all, because your traffic is never trying to go out to the public internet in the first place. If you get the correct, context-specific best path IP to your services at all times, you don’t have to use the naive, public IP for immich that doesn’t even actually exist on your local network.
The terminology around all this is confusing and sometimes stupid because private networks behind NAT never really existed when DNS was invented, and a lot of people deal with it in stupid and overcomplicated ways. If this same DNS server were then also going to be shared and used publicly to host your own domain names to other people, you would need a thing called “split zones” or “split DNS” but you don’t need to do that and you should avoid that too. Keep private DNS private, and leave public DNS out in public. Separate them intentionally and deliberately.
If you are getting the public IP for your Immich, then you are using its public DNS. I will try and make it simple for you, the way I think everyone should do it:
Your LAN/VPN environment is private. It should have its own dedicated authoritative private DNS server whose purpose is limited to completely and comprehensively servicing all the DNS IP lookup needs of that LAN/VPN environment and being the sole source of truth within that network. Often, the local network’s DNS is already correctly configured and provided by your router to handle all public IPs, and this is usually completely fine for self-hosting. What matters is that you should be able to add custom IP addresses to it, and it should be private to your network. Nobody else should have access to this DNS configuration, not because it’s really important for security but just because it is irrelevant outside the context of your local network, which is usually exactly what your router DNS provides. Your internal network DNS is responsible for two things within that environment:
You just have to implement and maintain the first part, usually in your router’s configuration. If you want more control or consistency over the DNS your local network is using it can also be self-hosted with something small like dnsmasq, or even big old granddaddy bind/named (not as complex as it seems and very standardized). Either way, that’s your responsibility, and once you’re providing correct local IPs for Immich on your local DNS (outside your network, you and the public will still use public DNS and get the public IP) everything will just work.
Hairpin may feel convenient. It’s not, it’s a workaround for a misconfiguration. Having private DNS that is separate and distinct from public DNS may feel like duplication of effort, but it’s not, it’s fundamental to even having a local network and puts you in the drivers seat for the layout of that network. Take responsibility for it instead of letting hairpin fix your mess.


This is the kind of nuanced usage of AI I like to see. Some would argue it’s not ideal to use any AI at all, and I agree, but we don’t live in an ideal world and I think this is realistically fine. AI writes better tests and docs than the ones I never write. Sure, maybe they’re not great objectively speaking, but they’re not worse than nothing. It’s better at keeping them up to date than I am too. Which is also probably not great, but strictly better than me.


Self host your own code repo. Forgejo is adding activitypub and federation features, not sure how far long they are, but someday if enough people start self-hosting we might have a viable decentralized way to collaborate on and contribute to each others’ projects.
Way too much. The Nvidia P40 I scavenged for my homemade AI server runs at 120W (throttled down from 250W default) on its own. Then I’ve got two more PCs running purely as redundant firewalls with automatic failover, pretty unnecessary but if that’s not the sort of thing homelabbing is for then I’m going to keep doing it wrong because I find it fun. Then there’s the minecraft server, which is pretty beefy and also eternally running at max CPU because my niece is a monster who loves spamming spawn eggs and should never be allowed access to creative mode. And I don’t even have the two rack units of disk arrays I bought at auction powered up yet because they need 240V which I don’t have handy. I guess someone could do the math on what 48 enterprise SAS drives will pull if they need to satisfy their curiosity, I’m not sure I want to. I will hook them up someday but for now ignorance is bliss. All I know is it’s a lot, and there’s stuff I’m not even including in this.