# How can I limit the bandwidth an application uses?
Source: https://vpsdime.com/knowledgebase/technical-questions/limit-bandwidth-usage
Last reviewed: 2026-07-02
Summary: Capping a process's network appetite, application-level limits first (they're the good ones: rsync, restic, wget all have flags), trickle for programs without one, Docker's per-container limits, and wondershaper/tc for whole-interface shaping, with the honest note about which layer to choose.

## What this is

A process is eating the pipe, [you've identified it](https://vpsdime.com/knowledgebase/technical-questions/per-app-bandwidth), and you want it slowed rather than stopped: a backup that saturates the uplink while the site serves, a sync job that [burns the monthly allowance](https://vpsdime.com/knowledgebase/acceptable-use/bandwidth-overage). Limits exist at four layers; pick the highest one available, they get cruder as you go down.

## 1. The application's own limit (always check first)

The tools that move bulk data almost all ship a throttle, and the built-in one is smooth, precise, and reliable:

- **rsync**: `--bwlimit=5000` (KB/s)
- **restic**: `--limit-upload 5120 --limit-download 5120` (KiB/s)
- **wget** / **curl**: `--limit-rate=5m` / `--limit-rate 5M`
- **scp**: `-l 40000` (Kbit/s)

If your heavy process is a backup or transfer, this section is the whole answer, cap the [scheduled job](https://vpsdime.com/knowledgebase/technical-questions/systemd-timers) at a rate that leaves headroom and move on.

## 2. trickle: a rate limit for programs without one

For an app with no built-in flag, **trickle** wraps it in userspace:

```
apt install trickle
trickle -d 2000 -u 500 some-command    # KB/s down/up
```

Honest limits: it only works on programs using standard sockets dynamically (most CLI tools yes, static binaries and some runtimes no), it's per-invocation, and it's approximate. Perfect for taming a one-off; wrong tool for infrastructure.

## 3. Docker: per-container limits

Containers make it clean at the runtime level, though Docker's native flags cover CPU/memory rather than network rates; the practical pattern is either the application-level flag inside the container (layer 1), or shaping the container's interface with `tc` (layer 4), most compose stacks just use layer 1.

## 4. The interface level: wondershaper and tc

When the goal is "this whole VPS should never exceed X" or per-port shaping, you're at Linux traffic control:

- **[wondershaper](https://github.com/magnific0/wondershaper)** is the simple wrapper: `wondershaper -a eth0 -d 50000 -u 50000` (Kbit/s) caps the interface, everything on it. Blunt, effective, easily removed (`-c`).
- **tc** itself (HTB classes, filters by port/mark) can shape *per service* at any granularity, and its syntax is famously hostile, this is the one place where [having an AI chatbot draft the tc script](https://vpsdime.com/knowledgebase/support-coverage/software-and-server-management) and reading it carefully beats writing it from the man page.

One thing shaping can't do: **inbound traffic has already crossed your line by the time you see it**, egress shaping is real, ingress "shaping" is polite packet-dropping. For inbound floods, the answer is [the bot guide](https://vpsdime.com/knowledgebase/troubleshooting/bot-traffic), not tc.

## Still need help?

You can [open a support ticket](https://vpsdime.com/open-ticket/). So we can help on the first reply, it's worth mentioning:

- the VPS hostname or IP,
- the process you're throttling, and the layer you tried (app flag, trickle, tc).

## Related questions

- "How do I throttle a backup so it doesn't saturate my server?"
- "How do I limit bandwidth for a program with no rate flag?"
- "How do I cap total bandwidth on my VPS?"
- "Can I limit a Docker container's bandwidth?"