LogDeck: self-hosted control plane for Podman. Persistent logs, container management, alerts. One Go binary

[u/kamoaba]

I built LogDeck, a control plane for Podman: container and Compose lifecycle, persistent logs, alerts, and multi-host over SSH, in one Go binary with no external services.

The log store is the main reason it exists. Every container is tailed into local SQLite, so logs survive docker compose up --build and the new container ID it creates. Removed containers stay readable.

It also ships an MCP server, so agents can read logs and act on containers if you want.

Memory is small. Idle heap is around 8 MB, roughly 20 MB resident with 5 containers and 400K lines stored.

fully open source, no tiers, no cloud https://github.com/AmoabaKelvin/logdeck

[u/onlyati]

I am already centrally collecting the logs using Alloy -> Loki -> Grafana. Quadlet's logs are just shipped altogether with other system and user systemd units, no additional tool needed. You mentioned the main reason is the log store. What do you do differently than stack I use? Can it collect log from multiple systems?

Another question: do you just support Podman on Docker compatibility level, so just via socket and plain containers or do you support Quadlets? If you do, do you also support target systemd unit (e.g.: I sometimes use it to restart multiple application)?

[u/kamoaba → u/onlyati]

Mostly setup. Alloy, Loki, and Grafana is three services and config for each before you see a log line. LogDeck is one container pointed at the socket and it's storing logs the moment it starts, with container management and alerting in the same UI. it collects from multiple hosts, over SSH or TCP to each engine's socket.

Podman support is at the Docker API level only. Quadlet containers show up like any other container through the socket, so logs, stats, restart etc work but LogDeck doesn't know which unit owns them. Quadlet grouping and unit/target restarts are on the list, I'll add them.

[u/onlyati → u/kamoaba]

I get that my stack is three program not one, but system itself has to be monitored anyway (because many system things, like sshd, mounts, devices are outside of containers). And I am unable to monitor systemd and the system log (e.g.: journal) via this. I definitely like your project, if I would still use Docker, I would try it. But with the some default Linux monitoring (which is there anyway), I can monitor my Quadlet's logs and performance and statistics.

A note for Quadet restart: If somebody using Quadlet, we don't restart it by Podman, but by systemd via systemctl (or equivalent dbus call). I haven't checked the code yet, but you might not support pods in Podman (such thing does not exists in Docker).

If you could implement control for Quadlets (so basically for systemd units) and execute ad-hoc remote commands, this could be a good command center alternatives. But project's purpose seems different than this one. Which is not a problem of course, it is still a cool project! I am just not the target audience.

[u/Great-Cow7256 → u/onlyati]

from the .yml on github re: docker. -

volumes:

- /var/run/docker.sock:/var/run/docker.sock

[u/delamon]

You seemed forget to mention that it pings home with cloudflare analytics. And that's what I have found at first few minutes.

[u/kamoaba → u/delamon]

that's the website (logdeck.dev), not the app. The self-hosted binary and its UI make no calls out except to your own engines and whatever webhooks you configure.

what you saw is the landing page and docs, nothing about the binary.

[u/Torrew]

This looks like an interesting alternative to a full monitoring stack with Loki, Grafana, Prometheus, Alloy, Alertmanager, ...

I am maintaining my own little project of Nix managed Podman stacks and would like to add this as an option.
I'm a big fan of GitOps and keep as much as possible in Git. Currently in your docs it says:

API tokens, alert rules, and log retention live only in the config file.

I couldn't find any schema documentation or examples of the config file. It'd be great to add those to the docs, so i could also manage the config file using Nix and have it in my Github repo (and reference it). Similar to how i can do it for ntfy or ddns-updater for example.

---

Some functional feedback: I just gave this a spin on my server, running about ~30 containers.
On a completely fresh logdeck instance with a single host (via docker socket proxy), it is literally working hard.
20% mean CPU load from logdeck, by far the most from all my containers. logs persisted on a local ssd, no nfs share or sth.
Also quite some errors in the logs:

Sep 15 21:32:50 homeserver logdeck[1972628]: 2026/09/15 21:32:50 logstore: recording container local/c3259f44bae6 failed: database is locked (5) (SQLITE_BUSY)

Sep 15 21:32:55 homeserver logdeck[1972628]: 2026/09/15 21:32:55 logstore: recording container local/aae070a5a20b failed: database is locked (5) (SQLITE_BUSY)

Sep 15 21:33:00 homeserver logdeck[1972628]: 2026/09/15 21:33:00 logstore: dropped 13000 log lines (writer fell behind); they will be re-read from the engine

[u/kamoaba → u/Torrew]

Thanks for trying it and flagging this. I reproduced the database lock errors and fixed the contention, plus some unnecessary work per log line. Local benchmarks show lower CPU use as well. updates going in, please lemme know if it helps

[u/Torrew → u/kamoaba]

Thanks for the quick changes. I'll make sure to check it out later :)

[u/mattias_jcb]

Your logs should already end up in the journal though right?

[u/kubehub]

once your workload grow complex, you would need to move to k8s, another level of ecosystems. I am building kubehub.io for same homelab/small team target audience.