Launched this week
Livinity
Open-source homeserver OS with a built-in AI agent
113 followers
Open-source homeserver OS with a built-in AI agent
113 followers
One operating system, one quiet interfacTurn a spare PC into a private AI homeserver. 495+ one-click Docker apps, plus Liv, an AI agent with MCP that installs apps and runs your containers for you. Bring your own Claude or Gemini key. Open source and TypeScript.
The part I'm stuck on is the single-box risk. All my self-hosted setups eventually have a drive or PSU die on the spare PC, and that's usually fine because I just rebuild from a compose file. With Livinity, is there an export for the whole setup, app configs, data volumes, and whatever context Liv has built up, so a hardware failure doesn't mean starting over from zero? Or is backup something I'm expected to bolt on myself outside the OS.
ChatWebby AI
The bring-your-own-key model (Claude or Gemini) so data never leaves the hardware is exactly the tradeoff I want from a self-hosted setup. Curious about the Liv side: when it installs an app or edits a container via MCP, is there a confirmation/dry-run step before it changes state, or does it just execute? Would love to trust it with automations but want a guardrail on destructive actions.
@zain_sheikh Great question, and the right one to ask before you hand an agent root access.
Liv splits actions into two buckets. Read-only things like finding a file or checking a container status just run. Anything that changes state, installing an app, editing or removing a container, hits a confirmation step first. Liv shows you what it is about to do, then waits for your yes.
Destructive actions get extra friction. Nothing gets removed without you seeing exactly what and approving it.
And because everything goes through MCP tools you control, you decide what Liv is even allowed to touch in the first place.
So the pattern is simple. The agent proposes, you approve, then it executes.
Does Liv handle updates and security patches for the docker apps automatically, or is that on me to keep everything current?
@ozkur99489 Great question! honest answer: it's one click today, not fully automatic yet. The App Store flags when a newer version of an app is available and updating pulls the fresh image and recreates the container (your data volumes are untouched). System updates for Livinity itself work the same way one button. Scheduled/automatic app updates are on the roadmap; the nice middle ground right now is that you can just tell Liv "check my apps for updates and update them" instead of doing it app by app. Security-wise, apps run in isolated containers and by default nothing is exposed to the internet directly traffic comes in through a Cloudflare tunnel, so there are no open ports on your home network to worry about.
Curious how this holds up long-term on a modest spare PC like an old NUC, does it get sluggish once you stack a bunch of those Docker apps and keep Liv running at the same time?
@levent39344 The base system is deliberately light the daemon, reverse proxy and databases idle well under a gig of RAM. Idle Docker apps mostly cost RAM rather than CPU, so "stacking" them is fine until you actually run out of memory. The important detail for Liv: it doesn't run a local model on your box. The heavy AI inference happens via API or CLI, so having Liv open adds very little load locally. On an 8–16GB NUC you can comfortably run a dozen typical apps; the ones to watch are the genuinely heavy workloads (Jellyfin transcoding, photo indexing, etc.) those cost the same on any platform. Disk is the thing that creeps up over time (Docker images/layers), and there's cleanup for that built in.
Curious how it handles resource limits on lower-end spare PCs, especially when running a local LLM alongside 10+ Docker containers at the same time?
@nurtenkado1ot2 Livinity doesn't impose per-container CPU/RAM quotas today — containers get Docker's defaults, meaning they share everything. For most apps that's exactly what you want (idle apps take almost nothing). The exception is the scenario you describe: a local LLM will happily use every core while generating. Two things help there: (1) Liv itself doesn't need a local LLM — its intelligence runs via API or AI CLI, so it stays light on the box; running something like Ollama is optional, and if you do, size the model to your RAM (a 7B quant wants ~5–6GB by itself). (2) Per-app resource caps are on our roadmap precisely for lower-end hardware. On a modest box I'd run the LLM as the one "heavy tenant" and keep the rest of the stack to normal self-hosted apps — that combination works fine.
Spun up Livinity on an old NUC and was surprised how calm the whole thing feels, especially with Liv handling the container stuff instead of me poking around in terminal at midnight.
@engl637419 "Calm" is genuinely the word we design against, so this is great to hear. The whole point of Liv managing the containers is that midnight-terminal-debugging shouldn't be the price of self-hosting. If you hit anything that doesn't feel calm, tell us — that's exactly the feedback that shapes what gets fixed next.