[Feature] Support binding to Unix domain sockets #2797

New Issue

GiteaMirror · 2026-02-28T20:28:34-06:00

GiteaMirror commented

2026-02-28 20:28:34 -06:00

Originally created by @Valloric on GitHub (Jan 9, 2026).

Verified feature request does not already exist?

I have searched and found no existing issue

💻

Would you like to implement this feature?

Pitch: what problem are you trying to solve?

I have a reverse proxy (Caddy) running with a service-specific unprivileged user (caddy). I want to limit connections to the Actual Budget server to processes owned by the caddy user, to improve security in case of system compromise.

If a process is listening on localhost:1234, then any local process can connect to it, no matter which (Unix) user is the owner of the server or client process. This increases the attack surface for Actual Budget if some process on the host is compromised.

Describe your ideal solution to this problem

Looking at the Actual Budget server configuration, it does not appear to be possible to configure the Actual Budget server to listen on a Unix domain socket instead of an IP and port number.

The usecase for UDS connection is connecting Actual over UDS to a reverse proxy running on the same host.

A UDS is the best way to connect processes running on the same host as it is 2-3x faster (it skips all the TCP and IP overhead since the kernel can just copy bytes from one process to the other) and more secure than listening on localhost. A UDS is represented as a file on the filesystem and can be protected with common filesystem permissions (or even POSIX ACLs). Note: no bytes actually pass through the filesystem or end up on disk; the UDS “file” is just a reference to an in-kernel object.

If some process on the host is compromised, when Actual is listening on a UDS that is configured to be accessible only to the user running the reverse proxy, Actual remains inaccessible to the compromised process (unless that process is the reverse proxy itself).

Please disregard any HTTP level authentication for a moment as the UDS provides a different and lower level of protection which is great for defense-in-depth and the principle of least privilege. For instance, even with Actual’s authentication, it would be unwise to expose a homelab Actual to the Internet; reducing access to only what is necessary results in more secure systems.

This should be simple to implement because Node supports binding to UDS; Actual just needs to support passing a socket path down to Node.

Teaching and learning

The Actual configuration docs should mention that Actual can bind to UDS and should recommend this approach when using a reverse proxy on the same host due to performance and security benefits. Every popular reverse proxy already supports connecting to UDS endpoints.

Originally created by @Valloric on GitHub (Jan 9, 2026). ### Verified feature request does not already exist? - [x] I have searched and found no existing issue ### 💻 - [ ] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? I have a reverse proxy (Caddy) running with a service-specific unprivileged user (caddy). I want to limit connections to the Actual Budget server to processes owned by the caddy user, to improve security in case of system compromise. If a process is listening on `localhost:1234`, then _any_ local process can connect to it, no matter which (Unix) user is the owner of the server or client process. This increases the attack surface for Actual Budget if some process on the host is compromised. ### Describe your ideal solution to this problem Looking at the [Actual Budget server configuration](https://actualbudget.org/docs/config/), it does not appear to be possible to configure the Actual Budget server to listen on a [Unix domain socket](https://en.wikipedia.org/wiki/Unix_domain_socket) instead of an IP and port number. The usecase for UDS connection is connecting Actual over UDS to a reverse proxy running on the same host. A UDS is the best way to connect processes running on the same host as it is **2-3x faster** (it skips all the TCP and IP overhead since the kernel can just copy bytes from one process to the other) and **more secure** than listening on localhost. A UDS is represented as a file on the filesystem and can be protected with common filesystem permissions (or even POSIX ACLs). Note: no bytes actually pass through the filesystem or end up on disk; the UDS “file” is just a reference to an in-kernel object. If some process on the host is compromised, when Actual is listening on a UDS that is configured to be accessible only to the user running the reverse proxy, Actual remains inaccessible to the compromised process (unless that process is the reverse proxy itself). Please disregard any HTTP level authentication for a moment as the UDS provides a different and lower level of protection which is great for defense-in-depth and the principle of least privilege. For instance, even with Actual’s authentication, it would be unwise to expose a homelab Actual to the Internet; reducing access to only what is necessary results in more secure systems. This should be simple to implement because Node supports binding to UDS; Actual just needs to support passing a socket path down to Node. ### Teaching and learning The Actual configuration docs should mention that Actual can bind to UDS and should recommend this approach when using a reverse proxy on the same host due to performance and security benefits. Every popular reverse proxy already supports connecting to UDS endpoints.

GiteaMirror added the needs votes feature labels 2026-02-28 20:28:34 -06:00

GiteaMirror closed this issue

2026-02-28 20:28:34 -06:00

GiteaMirror commented

2026-02-28 20:28:35 -06:00

@github-actions[bot] commented on GitHub (Jan 9, 2026):

✨ Thanks for sharing your idea! ✨

This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don't forget to upvote the top comment with 👍!

@github-actions[bot] commented on GitHub (Jan 9, 2026): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don't forget to upvote the top comment with 👍!