Kali Linux on a VPS for pentesting: the setup that works

You almost never need Kali itself on a server. What you want is Kali’s toolset, and the practical way to get it on a VPS is to start from a stable, patched Debian, harden the host, and run Kali’s official container image for the tools — installing only the metapackages the job needs. Many of the tools are in Debian’s own repositories too. All of it is only for systems you own or have written permission to assess.

Do you need Kali itself on the server?

Kali is a rolling distribution built on Debian testing, designed as an interactive pentesting workstation: a desktop, hundreds of preinstalled tools, and packages that move fast. Those are exactly the wrong properties for a server you leave running on a public IP. A server should be a stable, predictable, patched OS with only what it needs installed. So the goal is the tools, not the desktop — and a headless remote box has no use for the desktop anyway.

How do I run Kali in Docker on a VPS?

Run Debian 12 or 13 as the host and pull Kali’s official image for the tools. This keeps the rolling, fast-moving toolset inside a container you can rebuild or throw away, on top of a stable host you keep patched.

1. 1Install Docker

   If Docker is not on the box yet, install it from Docker’s own repository — docker: command not found walks through it, and the socket permission-denied follow-up covers running it without sudo.

2. 2Pull the image and keep a persistent volume

   docker pull docker.io/kalilinux/kali-rolling
   
   # a named volume keeps your work when the container is recreated
   docker volume create kali-work
   docker run -it --name kali \
     -v kali-work:/root/work \
     kalilinux/kali-rolling

3. 3Install only the metapackage you need

   The image is minimal and ships with almost no tools. Add a headless metapackage — take the exact name from the Kali metapackages list. kali-linux-headless is the usual choice for a server; the tools-specific ones (kali-tools-web, kali-tools-information-gathering, and so on) are smaller if you only need one area.

   apt update
   apt -y install kali-linux-headless

Most security tools work from a container as-is. Two cases are worth knowing, and anything you add loosens isolation, so grant it only when a specific tool needs it:

• Raw sockets — a SYN scan (nmap -sS), masscan or anything crafting packets needs the NET_RAW capability. Docker grants it to root in a container by default; you only need --cap-add=NET_RAW if you run with --cap-drop=ALL, as a non-root user, or under rootless Podman. Tools that change interfaces or routes also need --cap-add=NET_ADMIN.
• Host networking — --network host lets the container use the VPS’s own interface directly, which some capture and scanning tools expect. It also removes the network isolation the container gave you, so use it deliberately and only on a box dedicated to the engagement.

Can I install the tools from Debian instead?

If you only need a handful of well-known tools, you may not need the Kali image at all — a lot of them are packaged in Debian itself. Checked in Debian 12 and 13:

sudo apt install -y \
  nmap masscan zmap \
  sqlmap whatweb wfuzz dirb ffuf gobuster \
  hydra john hashcat aircrack-ng \
  tshark tcpdump sslscan testssl.sh \
  socat netcat-openbsd python3-impacket

nikto is packaged too, but in Debian’s non-free component, which a default Debian 12 or 13 install does not enable. Add non-free to your sources, or run nikto from the Kali container.

Some of the bigger frameworks — Metasploit, Burp Suite, wpscan, nuclei, responder — are not in Debian’s repositories and come from their own vendors or from the Kali image. For those, the container is the cleaner route than hand-installing each one.

One honest caveat: Debian ships a fixed version of each tool for the life of a release, so its nmap or sqlmap can be a version or two behind the one in Kali’s rolling image. For most work that does not matter; when you need the very latest build of a specific tool, run it from the Kali container instead.

How do I keep the Kali tools up to date?

Kali is a rolling distribution, so the tools move constantly. Refresh the image rather than letting a months-old container drift, and rebuild a clean one between engagements so nothing from the last client lingers:

# pull the newest image
docker pull docker.io/kalilinux/kali-rolling

# update tools inside a running container
apt update && apt -y full-upgrade

# or just discard it and start fresh for the next engagement
docker rm -f kali
docker run -it --name kali -v kali-work:/root/work kalilinux/kali-rolling

A throwaway container per engagement is the container version of the throwaway-box practice the scanning guide recommends: findings from one client never sit next to another’s, and a rebuild costs a minute.

Why not convert Debian into Kali?

Because Kali’s own documentation tells you not to, and it is the single most common way people break both systems. Kali’s repository documentation is explicit that adding Kali’s repositories to a non-Kali install (or another distribution’s repositories to Kali) will very likely break the system, often without warning. The container keeps Kali’s rolling packages in their own world, on top of a Debian host whose packages stay Debian’s. Do not mix the two apt sources.

How should I secure the VPS first?

A box full of offensive tooling on a public IP is a target. Before you run anything, do the ordinary server hardening:

• Key-only SSH, no password login, a non-root user — secure SSH access and the base setup.
• A firewall closed by default, opening only what you serve — UFW setup.
• Bind tool web UIs to localhost. A web interface — a proxy’s UI, a dashboard — should listen on 127.0.0.1 only, and you reach it over an SSH tunnel (ssh -L 8080:127.0.0.1:8080 user@host), never by opening the port to the internet.

Is it legal to run Kali on a VPS?

The tools are legal. Pointing them at a system you are not authorised to test is not. Before any packet leaves the box, have written permission that names the exact hosts and ranges in scope, with a start and end date, from someone with authority over them. Keep an out-of-scope list too — a target’s CDN, payment processor and SaaS mail belong to other people.

How you scan matters as much as what you scan: rate limits, exclusion files and the reverse-DNS and abuse-contact setup that keeps a legitimate scan from being read as an attack are all in running nmap, masscan and zmap from a VPS. Read it before the first run, not after the first complaint.

Will my VPS host allow scanning?

Often not. On an ordinary host a scan looks like an attack to the automated abuse systems watching a shared IP range, and suspensions are common, so read the acceptable-use policy before the first run and pick a line that permits the work. Our Pentesting KVM line, for example, explicitly allows web scraping and zmap/masscan scanning, from an isolated network segment rather than the regular customer ranges. A DMCA-ignored plan is not the same thing: it changes how copyright notices are handled, not how abuse reports about scanning are.

Frequently asked