Linux version planned for Darling Edition?

[markallisongit]

It would be great to be able to host the Darling edition as a Linux service and bundle postgres/timescale with it. Any plans for this? I don't want to provision a Windows VM and pay for another Windows license.

[erikdarlingdata]

Short answer: closer than you might think, and it's a direction I want to go.

The collector service is compiled cross-platform on purpose. The Windows-only piece is the zero-admin bundled Postgres/TimescaleDB runtime (Windows binaries, DPAPI-protected credentials, firewall handling). If you point the service at your own Postgres with TimescaleDB installed (postgres.managed = false plus a connection string), nothing in the collection, alerting, analysis, web dashboard, or MCP path depends on Windows.

What's missing before I'd call Linux supported:

1. Actually testing and documenting that path: systemd unit, install docs, linux-x64 builds in CI
2. Secrets. Encrypted passwords use DPAPI today, which is Windows-only. Linux needs env var or secrets-file support so you aren't putting plaintext in darling.json. Authenticated SMTP has the same problem right now.
3. For "bundled" Postgres on Linux, the realistic answer is a Docker image or compose file that pairs the service with the timescale/timescaledb image, rather than shipping raw Linux binaries

Which shape would you actually deploy: a systemd service pointing at Postgres you manage, or Docker/compose? That decides what gets built first.

[markallisongit]

I'd want the whole stack, backend included, as a single deployment rather than pointing the service at a Postgres I run separately. So I'm leaning towards docker/compose for this on a Linux VM. Although I'm sure others will have different requirements 😅. This is great work, thanks for doing this.

[erikdarlingdata]

Compose it is. Tracking issue: #1804 - the shape is the service container paired with the official timescale/timescaledb image as a single deployment, with the secrets story (DPAPI is Windows-only) as the biggest real piece of work. The systemd + bring-your-own-Postgres path will get documented too, since the service already runs against any Postgres you point it at.

No timeline promises, but the direction is set. Thanks for answering the deployment-shape question - it genuinely decided what gets built first.