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.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
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
Running Qwen 3.8 27B dense on some R9700s, and Qwen 3.8 flash next on dgx sparks. I use it for code gen outside work, including an automated Dev pipeline that rubs on its own. When I did the math comparing to token API pricing of Opus 4.8, it covered its own costs in a few months. With the sparks I get about 40tg/s, 1500pp/s, but can get concurrency up to 5 stably. With the R9700s, I get ~100tg/s, 3000pp/s and can also get up to 5 concurrency.
I access it over wireguard to the network that it is on, and use termux to ssh into a build machine for dev over CLI using https://pi.dev/
I also started building https://fcli.dev/ to make integrations easier; the idea being that LLMs should just implement simple reusable functions instead of repeatedly making complex curl requests to integrate with a service.
I also use LLMs heavily for work; Qwen 3.8 seems almost on par to Opus 4.8 IMO. I also don't have to worry about token costs, and it often responds faster than Claude would because there usually isn't a queue on my machines. At this point, I wouldn't complain if my work provided me 2x B6000 instead of a Claude subscription; I'd still be able to get all my work done.
Would be interested to know your experience with fcli if you’d share more. Just hearing about it.
I mean, I haven't really started discussing it outside IRL friends, so not surprised you haven't heard of it 😅
In essence, the problem is twofold:
So fcli is intended to be an easily extended, configured, and authenticated CLI. The "one CLI" to do everything your LLM needs. Ideally, you set up a personal repo to store 'ucks' (f packages) in, and you set up credentials for that repo so your LLM can push any new ucks to it. You can then share that repo with other users if they could also benefit from any of that functionality.
As you go along in a session, when you notice the LLM repeatedly running similar verbose commands, you can have it create an uck for it instead and save those tokens.
Likewise, if, say, an MCP server doesn't have full functionality, you can have your LLM import the SDK from npm into an uck and write a basic fcli wrapper around it to start using.
The other nice thing is that it makes your tool configuration repeatable between LLMs and harnesses. You don't need to set up your MCP servers in both Claude and Codex and Pi, just in f and tell them to use f.
There's also a creds uck to make your secrets more portable and (a bit) safer.
In general, I'm trying to model it a bit like pi.dev, but as part of the tooling instead of the harness itself. I think they work quite well together :)
Interesting paper comparing MCP and CLI