Tracking issue for running the Darling service on Linux, spun out of Discussion #1641 (with #1153 as an earlier signal in the same direction).
The ask (markallisongit): host the Darling edition as a Linux service with Postgres/TimescaleDB bundled, without provisioning a Windows VM or paying for another Windows license. When asked which shape he would actually deploy - a systemd service pointing at Postgres he manages, or Docker/compose - the answer was: the whole stack, backend included, as a single deployment, so Docker/compose on a Linux VM.
Decision: compose-first. The deliverable is a compose file that pairs the service container with the timescale/timescaledb image as a single deployment. The systemd + bring-your-own-Postgres shape stays supported as the second path and mostly needs documentation, since the service already runs against any Postgres you point it at.
What already works in our favor: the collector service is cross-platform .NET on purpose. With postgres.managed = false and a connection string, nothing in the collection, alerting, analysis, web dashboard, or MCP path depends on Windows. The bundled zero-admin store is the Windows-only piece, and in the compose shape the official TimescaleDB image replaces it entirely - postgres.managed stays false inside the container.
The work:
- Secrets. Encrypted passwords (
--encrypt-password, SQL auth, SMTP) are DPAPI today, which is Windows-only. Linux needs env-var indirection and/or a secrets-file source (0600, compose secrets: friendly) so nothing lands plaintext in darling.json. This is the largest piece and it benefits Windows BYO-store shops too.
- File permission posture. The ACL hardening (
DarlingFileSecurity, config/credential lockdown) is Windows ACL API behind [SupportedOSPlatform("windows")]. Linux needs the chmod/umask equivalent posture, or the container boundary documented as the access boundary.
- linux-x64 in CI. Build + test the service on an ubuntu runner, publish linux-x64 artifacts, and build/push a service container image as part of the release pipeline.
- The compose file itself. Service +
timescale/timescaledb with healthchecks, a named volume for the store, env-based config injection, and ports for the web dashboard and MCP endpoint.
- Gate the Windows-only plumbing. Event Log source registration, the firewall verb, and the sc-based service lifetime need to no-op cleanly on Linux (most already sit behind platform guards; verify and pin).
- Docs. A compose quickstart in the Darling README, plus the systemd unit + BYO-Postgres walkthrough for shape two.
Viewer stays a Windows desktop app; Linux hosts read it over the web dashboard, which already exists.
Tracking issue for running the Darling service on Linux, spun out of Discussion #1641 (with #1153 as an earlier signal in the same direction).
The ask (markallisongit): host the Darling edition as a Linux service with Postgres/TimescaleDB bundled, without provisioning a Windows VM or paying for another Windows license. When asked which shape he would actually deploy - a systemd service pointing at Postgres he manages, or Docker/compose - the answer was: the whole stack, backend included, as a single deployment, so Docker/compose on a Linux VM.
Decision: compose-first. The deliverable is a compose file that pairs the service container with the
timescale/timescaledbimage as a single deployment. The systemd + bring-your-own-Postgres shape stays supported as the second path and mostly needs documentation, since the service already runs against any Postgres you point it at.What already works in our favor: the collector service is cross-platform .NET on purpose. With
postgres.managed = falseand a connection string, nothing in the collection, alerting, analysis, web dashboard, or MCP path depends on Windows. The bundled zero-admin store is the Windows-only piece, and in the compose shape the official TimescaleDB image replaces it entirely -postgres.managedstaysfalseinside the container.The work:
--encrypt-password, SQL auth, SMTP) are DPAPI today, which is Windows-only. Linux needs env-var indirection and/or a secrets-file source (0600, composesecrets:friendly) so nothing lands plaintext indarling.json. This is the largest piece and it benefits Windows BYO-store shops too.DarlingFileSecurity, config/credential lockdown) is Windows ACL API behind[SupportedOSPlatform("windows")]. Linux needs the chmod/umask equivalent posture, or the container boundary documented as the access boundary.timescale/timescaledbwith healthchecks, a named volume for the store, env-based config injection, and ports for the web dashboard and MCP endpoint.Viewer stays a Windows desktop app; Linux hosts read it over the web dashboard, which already exists.