Free tools Windows power users keep installed
One-click scans. No signup required.
Install Beanstalkd from Ubuntu’s package repository, bind it to a private address, run it under systemd, and let application workers reserve and acknowledge jobs over TCP port 11300. Beanstalkd is a small, generic work queue: producers enqueue slow tasks so web requests can finish quickly, while workers process those tasks asynchronously.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This guide covers a production-conscious Ubuntu VPS setup, network isolation, systemd configuration, the producer/worker lifecycle, priorities and delays, binlog persistence, sizing flags, upgrades, and the failure modes that matter when a queue runs on one server.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →What Beanstalkd does
Beanstalkd is a daemon that accepts jobs over a TCP connection and stores them in named tubes (queues). The Ubuntu Jammy manual describes it as a simple work-queue service designed to move time-consuming work out of a request path. A web application can enqueue an email, image conversion, report, webhook, or other slow operation and return a response immediately; a separate worker later performs the operation.
The daemon deliberately has a narrow scope. It is not a database, a scheduler with calendar rules, or a replicated high-availability cluster. Its protocol is line-oriented ASCII for commands plus unstructured byte chunks for job bodies. That simplicity makes it easy to run on a single VPS, but it also leaves durability, access control, retries, monitoring, and failover decisions to the operator and the client library.
#1 Best Overall
When it fits
- A single application or a small group of services needs a lightweight asynchronous queue.
- Jobs benefit from numeric priority, a delivery delay, and a time-to-run (TTR) lease.
- You can keep the queue on one VPS and accept local-disk recovery rather than synchronous replication.
- Your workers can safely retry a job if a process or host fails.
When to choose a different design
Use a replicated or managed queue when losing one VPS must not interrupt processing, when you need multi-node failover, or when queue state must survive a complete host loss. Beanstalkd’s binlog recovers local state after a restart; the documented options do not provide replication or automatic failover.
Before installing on the VPS
Network and operating-system prerequisites
- An Ubuntu VPS with administrative access through
sudo. - A private address reachable by the application and worker hosts, or a firewall policy that limits TCP port 11300 to those hosts.
- Persistent storage if you intend to use the binlog.
- A plan for running workers as services and for making their job handlers idempotent, because an unfinished reservation can be delivered again.
Beanstalkd’s documented defaults are address 0.0.0.0 and TCP port 11300. Binding that default on an Internet-facing VPS can expose the queue to every reachable network. Decide the listening address and firewall rule before starting the daemon.
Install the Ubuntu package
-
Refresh package metadata:
sudo apt-get update -
Install Beanstalkd:
sudo apt-get install beanstalkd -
Check which repository build your VPS will use:
apt policy beanstalkdUbuntu’s resolute package index lists version
1.13-1build1in the universe component, while other Ubuntu releases and mirrors can carry a different revision. Always read the candidate version shown on the target machine instead of assuming that index applies to your release.
The Debian and Ubuntu packages include an executable, a systemd service unit, a socket unit, a defaults file, and protocol documentation. Confirm the installed paths with:
dpkg -L beanstalkd | lessYou should see /etc/default/beanstalkd, /lib/systemd/system/beanstalkd.service, and /lib/systemd/system/beanstalkd.socket. The exact unit contents can vary by distribution release, so inspect them before overriding startup flags.
Start and verify the systemd service
-
Read the packaged unit and defaults file:
systemctl cat beanstalkd.service sudo sed -n '1,200p' /etc/default/beanstalkd -
Start the service now and enable it at boot:
sudo systemctl enable --now beanstalkd -
Check the service state and recent log messages:
systemctl status beanstalkd --no-pager sudo journalctl -u beanstalkd -n 50 --no-pager -
Confirm that a process is listening on the expected port:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.sudo ss -ltnp | grep 11300
Because the package ships both a service and a socket unit, inspect systemctl status beanstalkd.socket if the service appears inactive or the listener is owned by socket activation. Follow the unit supplied by your Ubuntu release rather than enabling competing custom units without checking which one owns port 11300.
Choose the bind address, port, and account
Bind privately whenever possible
The -l addr option selects the listening address and defaults to 0.0.0.0. The -p port option selects the TCP port and defaults to 11300. If the application and queue share a VPS, bind to 127.0.0.1. If they communicate over a private network, use that VPS interface address, such as 10.0.1.5, rather than all interfaces.
A manual foreground launch illustrates the choices:
beanstalkd -l 10.0.1.5 -p 11300Do not use a foreground launch as the long-term production supervisor; systemd should own the process, restart it, and record its logs.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Run with least privilege
The -u user option makes the daemon drop privileges to the named account. Create a dedicated system account if your package unit does not already define one:
sudo adduser --system --no-create-home --group beanstalkdEnsure that the account can read and write the binlog directory before enabling persistence. A service account limits the impact of a daemon compromise and avoids running queue code as root.
Apply flags through the distro configuration
Beanstalkd has no configuration file of its own; runtime behavior comes from command-line flags and the distribution’s service configuration. On Ubuntu, inspect /etc/default/beanstalkd and the unit’s ExecStart line. Edit the supported variables there, or create a systemd drop-in if the file is not used by your release.
For a drop-in, first locate the executable with command -v beanstalkd, then run:
sudo systemctl edit beanstalkdA drop-in can replace the startup command after clearing the packaged one:
[Service]
ExecStart=
ExecStart=/usr/bin/beanstalkd -l 10.0.1.5 -p 11300 -u beanstalkdUse the executable path shown by command -v; it may differ on a custom installation. Reload and restart after changing a unit:
sudo systemctl daemon-reload
sudo systemctl restart beanstalkd
systemctl status beanstalkd --no-pagerFirewall the queue
Beanstalkd does not replace a network firewall. If the application host is 10.0.1.10 and the daemon listens on a private interface, an uncomplicated firewall rule can restrict access to that source:
sudo ufw allow from 10.0.1.10 to any port 11300 proto tcp
sudo ufw status numberedUse the equivalent rule in your VPS provider’s security group if that firewall sits outside the guest. Do not open port 11300 to the whole Internet merely because the daemon’s default address is 0.0.0.0. Permit only application and worker networks, and verify the effective listener with ss.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsUnderstand the job lifecycle
Each job moves through states controlled by producer and worker commands. A producer selects a tube and sends put. A worker watches that tube, reserves a ready job, performs the work, and then acknowledges the result.
| Operation | What it does | What happens next |
|---|---|---|
put |
Creates a job with priority, delay, TTR, and a byte-counted body. | The job is delayed or enters the ready queue. |
reserve |
Leases the next ready job to a worker. | The job becomes reserved and its TTR countdown starts. |
reserve-with-timeout |
Waits for a ready job up to a specified number of seconds. | The client receives a timeout response if no job arrives. |
delete |
Confirms successful processing. | The job is removed permanently. |
release |
Returns a reserved job to the ready queue, optionally with a new delay and priority. | Another reservation can process it. |
bury |
Removes a job from normal delivery without deleting it. | It remains available for deliberate administrative recovery. |
If a worker reserves a job and neither deletes, releases, nor buries it before the TTR expires, the server places it back in the ready queue. This is why a worker must finish within its TTR or explicitly release the job, and why handlers should tolerate duplicate effects.
Set priority, delay, TTR, and body size
The wire command is:
put <pri> <delay> <ttr> <bytes>| Field | Meaning |
|---|---|
pri |
Numeric priority. Lower numbers are delivered before higher numbers. |
delay |
Seconds before the job becomes ready. |
ttr |
Time-to-run lease in seconds after reservation. |
bytes |
Exact number of bytes in the following job body. |
The body is an unstructured data chunk, so serialize application metadata consistently (for example, JSON with a job type and an identifier) and keep the actual payload small. A producer should set TTR longer than the normal processing time but short enough that a crashed worker’s job is eventually retried. If processing can legitimately exceed that lease, the worker must use the protocol’s job-touch mechanism through its client library or choose a longer TTR; otherwise the job can become ready while the first worker is still acting on it.
Rank #4
Producer flow
Using the project’s Ruby-style example, a producer connects to the queue address and calls put with its body:
queue = Beanstalk::Pool.new(['10.0.1.5:11300'])
queue.put('hello')The exact constructor and defaults depend on the client library. At the protocol level, a diagnostic producer could send a five-byte body like this:
printf 'put 1024 0 60 5rnhellorn' | nc 10.0.1.5 11300That command is useful for connectivity testing, not for an application that needs durable serialization, error handling, and reconnect logic.
Worker flow
- Connect to the queue and select or watch the tube used by the producer.
- Call
reserveorreserve-with-timeout. - Read the returned job identifier and body completely.
- Run the handler with a timeout that fits inside the job’s TTR.
- Call
deleteonly after the side effect has succeeded. - Call
releasefor a retryable failure, usually with a controlled delay, orburya job that requires inspection.
Do not acknowledge before committing the work. If a worker exits after reservation but before acknowledgement, TTR expiry is the recovery path and the job may be delivered again.
Make queue data recoverable with the binlog
Beanstalkd is memory-oriented by default. Add -b path to maintain a binlog on persistent storage. The daemon replays that log at startup and appends job and state changes while it runs.
sudo install -d -o beanstalkd -g beanstalkd /var/lib/beanstalkd
sudo systemctl edit beanstalkdThen include a binlog path in the service command or the package’s supported defaults setting:
-b /var/lib/beanstalkd/binlogVerify ownership and free space before restarting. A binlog on an ephemeral disk does not protect jobs when the VPS itself is destroyed.
Best Value
Choose the fsync policy
-f mscontrols how often the daemon callsfsync. A larger interval reduces disk activity but increases the amount of recent history that can be lost after a power failure.-Fdisables fsync. This favors throughput and leaves more recent changes vulnerable to an abrupt host or storage failure.
There is no universally correct interval. Select it according to the business cost of losing recently enqueued or acknowledged jobs, then test restart recovery on the same storage class used in production. Binlog recovery is local replay, not replication, quorum storage, or failover.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Control log rotation and job size
-s bytessets the binlog file size.-z bytessets the maximum job size. Producers must keep the body within this limit, counting bytes rather than characters.
Set a maximum body that leaves memory for the daemon, workers, and the operating system. Put large files in object or block storage and enqueue a reference instead of pushing the file itself through the queue.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Operate and monitor the VPS deployment
Routine checks
systemctl is-active beanstalkdconfirms whether systemd considers the service running.sudo journalctl -u beanstalkdshows startup failures, permission errors, and restarts.sudo ss -ltnp | grep 11300confirms the address and process attached to the listener.df -h /var/lib/beanstalkdchecks the filesystem that holds the binlog.apt policy beanstalkdrecords the installed and candidate package versions before maintenance.
Monitor worker health separately from daemon health. A listening queue can appear healthy while every worker is stopped, blocked on an external API, or repeatedly timing out.
Design workers for retries
Use an idempotency key in each job body or in the downstream database. A retry after TTR expiry should detect that an email, payment update, or record change already succeeded rather than performing it twice. Separate transient failures, which can be released for retry, from malformed or permanently impossible jobs, which are better buried for inspection.
Troubleshoot common failures
| Symptom | Likely cause | Fix |
|---|---|---|
| Client reports connection refused | The service is stopped, the address is wrong, or no process owns port 11300. | Check systemctl status, journalctl, and ss -ltnp; correct the bind address or restart the unit. |
| Client times out from another host | The daemon is bound to loopback or a firewall/security group blocks TCP 11300. | Bind to the private interface and allow only the application source address. |
Service fails after adding -b |
The binlog directory does not exist or the service account cannot write it. | Create the directory, assign ownership to the daemon account, and inspect the journal for the exact path error. |
| Jobs reappear unexpectedly | The worker exceeded TTR or crashed before delete/release/bury. | Increase TTR for legitimate runtimes, add progress handling where supported, and make the job idempotent. |
| Jobs remain delayed | The producer supplied a nonzero delay. | Check the delay argument and wait for its seconds to elapse before expecting reservation. |
| Large jobs are rejected | The body exceeds the daemon’s -z maximum or the declared byte count is wrong. |
Raise -z deliberately or enqueue a compact reference; ensure bytes equals the actual payload length. |
| Recent jobs disappear after power loss | Fsync was infrequent or disabled, so the binlog had not committed the latest history. | Use a shorter -f interval, avoid -F when durability matters, and document the resulting throughput trade-off. |
Build from upstream when the package is unsuitable
The Ubuntu package is the simplest maintenance path. If its version or compile-time choices do not meet your needs, the upstream project documents building with make, running ./beanstalkd directly, and installing with make install or make install PREFIX=/usr.
make
./beanstalkd
sudo make install PREFIX=/usrDo not mix an upstream binary with the distribution unit without checking paths, ownership, and upgrade procedures. Record the source version, install prefix, service command, and rollback package before replacing the managed executable.
Version and maintenance notes
Beanstalkd 1.13 was released on 12 March 2023. Distribution repositories can lag or apply their own packaging revision, so record apt policy beanstalkd and the output of beanstalkd -v (if supported by the installed build) during deployment. Test upgrades by stopping workers gracefully, preserving the binlog directory, upgrading the package, starting the daemon, and confirming that workers can reserve and delete a test job.
Quick Recap
Production checklist
- Install from the Ubuntu repository and verify the candidate version.
- Inspect
/etc/default/beanstalkd, the service unit, and the socket unit before changing startup behavior. - Bind to loopback or a private interface instead of leaving an Internet-facing
0.0.0.0listener. - Restrict TCP 11300 with the VPS firewall or security group.
- Run under a dedicated account and grant it ownership of the binlog directory.
- Set
-b, an appropriate fsync policy, binlog size, and maximum job size when local recovery is required. - Choose priority, delay, and TTR values from measured workload behavior.
- Delete only after successful processing; release retryable failures and bury jobs needing investigation.
- Make handlers idempotent because TTR expiry can cause redelivery.
- Monitor the daemon, worker pool, disk usage, and queue latency as separate signals.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
