Pueue: a shell command queue that survives your SSH session
:stars: Manage your shell commands.
At a glance
- What is it?
- Pueue puts shell commands in a queue managed by a background daemon, so long jobs keep running after you disconnect. It is built for interactive human use, not for orchestrating hundreds of tasks.
- Who is it for?
- Pueue fits engineers who run long shell jobs on a machine they keep coming back to, especially over SSH, and who want pueue status, pueue log and pueue restart without a terminal multiplexer. It is the wrong tool if you need hundreds of concurrent tasks, a programmable API, or scheduling logic that outlives a person's attention; the README says the project is not designed for heavy-duty programmable scheduling.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem Pueue solves: commands that must outlive the terminal
A long rsync, a model training run, a batch conversion: the command is correct, but it is tied to the shell that started it. Close the laptop, drop the SSH connection, or hit Ctrl-C by accident, and the process goes with it. Terminal multiplexers solve part of this by keeping a session alive, but they keep the job attached to a pseudo-terminal you have to reattach to, and they give you no queue, no ordering, no dependency handling, and no persistent record of what ran.
Pueue separates the client from the execution. The README describes it as a command-line task management tool for sequential and parallel execution of long-running tasks, where the queue is processed by a background daemon rather than by your shell. Because of that split, the documentation states you can control tasks from any terminal on the same machine, and the queue will be continuously processed even when no SSH session is active. The audience is a person at a keyboard: the README is explicit that the focus lies on human interaction and that the tool is supposed to be used by a real person on some kind of OS.
How pueued executes your queue
Two binaries make up the system: pueue, the client you type into, and pueued, the daemon that owns the queue. The daemon runs in the background and is what makes execution independent of any terminal. When you enqueue a task, the client hands it to the daemon, and the daemon runs it later according to the queue state.
Several details about that execution model are documented. Commands are executed in their respective working directories, and the current environment variables are copied at the moment a task is added, not when it starts. Commands are run in a shell, which the README frames as a feature: it allows the full feature set of shell coding. The flip side is escaping. The README warns that scheduled commands are executed via your system shell, so the command needs proper shell escaping, and suggests surrounding the command with quotes, giving pueue add 'ls $HOME && echo "Some string"' as the safe form.
State is durable. The README states the queue is always saved to disk and restored on kill or system crash, and that logs are persisted onto disk and survive a crash. Groups act as separate queues, each with its own concurrency limit, and can be paused or started as a unit. Tasks can be ordered, given dependencies, or scheduled for a specific time. For inspection, log and status can emit JSON, and there is a wait subcommand that blocks until specific tasks, a group, or everything finishes.
Installing Pueue and running a first queued command
The README calls the system package manager the preferred installation route, because packaged builds usually deploy service files and completions automatically. Pueue is packaged for a number of distributions; the README points at the Repology table for the current list. If your distribution is not covered, release builds are the second option: statically linked binaries where possible are built for Linux including ARM, macOS and Windows on each release, and you download both the client and the daemon, rename them to pueue and pueued, and place them in your PATH.
With Rust installed, the crate route is a single command. The README notes this installs to $CARGO_HOME/bin/pueue, which defaults to ~/.cargo/bin/pueue.
cargo install --locked pueueBuilding from source uses the same stable toolchain expectation. The README says Pueue is built for the current stable Rust version and that older versions are not tested or officially supported.
git clone [email protected]:Nukesor/pueue
cd pueue
cargo build --release --locked --path ./pueueThat leaves the binaries in target/release/{pueue,pueued}. Once both are on your PATH, the daemon has to be running before the client can do anything useful; the README does not spell out a start command in the text above, so check the Get-started wiki page for the platform-specific way to launch pueued, including whether your package installed a service unit for you. After that, the first real use is enqueueing something and watching it.
pueue add 'ls $HOME && echo "Some string"'
pueue statusThe quoting matters, per the README's warning about shell escaping. pueue status then shows the queue, and pueue log gives you the output of a finished task. From there the documented surface widens: pause and resume tasks, send input to a running process, move tasks in the order, set dependencies, or wait for a group to drain.
Where Pueue is deliberately the wrong tool
The README spends an unusual amount of space telling you not to use the project for certain jobs, and that honesty is worth taking at face value. Pueue is not designed to be a heavy-duty programmable task scheduler or executor. The feature set and the architecture have been kept simple by design, and the README states plainly that it has not been built for heavy-duty work like hundreds of tasks, even though it can be scripted to some degree. If your workload is machine-generated, with hundreds of jobs, advanced API access and complex scheduling, the README itself says that is the job for another project.
There are smaller limits inside the design too. Environment variables are captured when a task is added, so a task enqueued before you export a variable will not see the new value when it eventually runs. Everything is local to one machine unless you follow the Connect to remote wiki page, which the README links but does not describe in the main text. And the project's own status is worth stating: the README declares Pueue feature-complete, with only minor improvements, bug fixes and regular maintenance work being merged. That is a stable tool, not one growing a large new surface area.
Pueue compared with Task Spooler and terminal multiplexers
The closest neighbour in the RELATED SEARCHES data is Task Spooler, and the two agree on the core idea: a queue that runs commands for you instead of you running them inline. The difference is in the shape of the tool. Task Spooler is a smaller, single-purpose queue; Pueue adds groups with independent concurrency, task dependencies, scheduled start times, a callback hook for things like desktop notifications, JSON output for log and status, and a wait subcommand for scripted follow-up. It also ships a client and a daemon as separate binaries, which is what lets the queue keep running with no terminal attached at all.
The other comparison the README raises is against terminal multiplexers, and it has a dedicated FAQ entry on the advantages over them. The distinction is that a multiplexer preserves a session; Pueue preserves a queue. With a multiplexer you reattach to a terminal and manage processes by hand. With Pueue the daemon owns execution, the queue is saved to disk and restored after a crash, and you interact through subcommands like status, log and restart rather than through a scrollback buffer. If you only ever need one command to survive a disconnect, a multiplexer is less machinery. If you want several commands ordered, grouped and inspectable after the fact, the queue model earns its extra component.
Maintenance, licensing and what an upgrade costs you
The repository is not archived, and the last push was on 2026-09-09, so the project is still receiving changes. The most recent release listed is v4.0.4 from 2026-03-02, with v4.0.3 and pueue-lib-v0.31.0 the day before. The README's own framing is that Pueue is feature-complete and that only minor improvements, bug fixes and regular maintenance work will be merged. Practically, that means upgrades should be small, but you should still read CHANGELOG.md before replacing binaries, because the client and the daemon are separate programs and a version skew between them is the kind of thing a changelog will call out.
On licensing, the repository ships both LICENSE.MIT and LICENSE.APACHE, and the workspace manifest declares license = "MIT OR Apache-2.0", so you choose between the two. The README badge says MIT. Note that the repository metadata field on this page lists Apache-2.0, which is only one half of the dual grant; the files in the repository are the authority. If you redistribute binaries or embed pueue_lib, confirm which of the two licences you are relying on and keep the corresponding notice. That is a packaging decision, not legal advice.
The other cost is operational. Because pueued is a long-running daemon that persists its queue and logs to disk, a crashed or killed daemon is not a lost job: the queue is restored. The price is that you now have a background process with state on the machine, and the README does not document rollback or downgrade behaviour, so treat a version change as something to test on a machine whose queue you do not mind losing.
Editorial conclusion
Pueue fits engineers who run long shell jobs on a machine they keep coming back to, especially over SSH, and who want pueue status, pueue log and pueue restart without a terminal multiplexer. It is the wrong tool if you need hundreds of concurrent tasks, a programmable API, or scheduling logic that outlives a person's attention; the README says the project is not designed for heavy-duty programmable scheduling. Before adopting it, read the Configuration wiki page and confirm where pueued stores its state on your platform, then run pueue add with a trivial command and check it with pueue status.
Frequently asked questions
How do I install Pueue?
The README prefers your system package manager, since packaged installs usually set up service files and completions. Otherwise you can download the pueue and pueued release binaries for Linux, macOS or Windows and put them in your PATH, or run cargo install --locked pueue.
Does Pueue keep running after I close my SSH session?
Yes. The README states that the pueued daemon runs in the background and that the queue is continuously processed even when you have no active SSH sessions, which is the main reason to use it instead of running commands directly in a terminal.
What does pueue status show?
The status subcommand reports the state of the queue and its tasks, and the README notes that status can also emit JSON if you want to display task information in another program. The README does not describe every column of the output.
Is Pueue suitable for running hundreds of tasks programmatically?
No. The README says Pueue is not designed to be a heavy-duty programmable task scheduler and that it has not been built for heavy-duty work like hundreds of tasks, even though it can be scripted to some degree.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/nukesor-pueue)