T-Pot: a multi-honeypot platform that runs 20+ sensors on one Docker host

What T-Pot collects that a single honeypot cannot

A single honeypot answers one protocol. Cowrie covers SSH and Telnet, Dionaea covers a set of network services, and each of the others targets something narrower: ADB, Citrix, DICOM, Redis, IPP printing, IEC 104 in Conpot. Running one of them gives you a log file and a narrow view of who is scanning that one port.

T-Pot's answer is to run many of them at once on the same host, behind the same network interfaces, and to normalise what they emit into one searchable store. The README lists the honeypots it ships images for, including adbhoney, beelzebub, ciscoasa, citrixhoneypot, conpot, cowrie, ddospot, dicompot, dionaea, elasticpot, endlessh, galah, go-pot, glutton, h0neytr4p, hellpot and heralding. The audience is anyone who wants to observe exploitation attempts across protocols rather than read a single sensor's output: a security team building threat intelligence, a researcher studying scanning behaviour, or a lab that needs a target network with realistic services.

The platform also bundles the tooling around the data. The README points to Kibana dashboards, an animated attack map, Cyberchef, Elasticvue and Spiderfoot as part of the deployment, so the collection and the reading of the collection ship together. That is the actual product: not a honeypot, but the assembly of many honeypots plus the pipeline that makes their output usable.

How T-Pot is wired: tpotinit, per-honeypot networks and a shared data path

The architecture is Docker Compose with a bootstrap container at the centre. The README states that T-Pot's main components moved into the `tpotinit` Docker image, which is what allows the platform to support multiple Linux distributions and, with limits, macOS and Windows through Docker Desktop.

The `docker-compose.yml` at the repository root shows the shape. A `tpotinit` service runs with `network_mode: "host"`, gets `NET_ADMIN`, mounts the Docker socket read-only, and mounts `${TPOT_DATA_PATH}` at `/data`. It is marked in the file as the service that must never be deleted. Every honeypot service declares `depends_on: tpotinit` with `condition: service_healthy`, so the bootstrap has to report healthy before sensors start.

Each honeypot gets its own Compose network: `adbhoney_local`, `cowrie_local`, `dionaea_local`, `conpot_local_IEC104`, `conpot_local_guardian_ast`, `conpot_local_ipmi`, `conpot_local_kamstrup_382`, `dicompot_local`, `elasticpot_local`, `h0neytr4p_local`, `heralding_local`, `honeyaml_local`, `ipphoney_local`, `mailoney_local`, `medpot_local`, `miniprint_local`, `rdphoneypot_local`, `redishoneypot_local`, `sentrypeer_local`, `tanner_local`, `wordpot_local`, plus `nginx_local` and `ewsposter_local`. Sensors are isolated from each other on those networks; the adbhoney service, for example, publishes only port 5555 and writes logs to `${TPOT_DATA_PATH}/adbhoney/log` and downloads to `${TPOT_DATA_PATH}/adbhoney/downloads`.

The data flow follows the mounts. A honeypot writes into its directory under the data path, and the Elastic Stack components read from there. Because the sensors are separate containers with separate networks, one honeypot crashing does not take the others down with it, but the shared data path means disk consumption is the sum of every sensor's logging, which is why the storage requirement is stated in the tens of gigabytes.

Installing T-Pot and getting to the dashboard

The README's TL;DR is the install path. You need a supported distribution installed with as few packages and services as possible, with `ssh` present, at least 8-16 GB RAM, 128 GB free disk and a working outgoing connection that is not filtered. Install `curl` first if the minimal install did not include it.

sudo [apt, dnf, zypper] install curl

The installer itself runs as a non-root user from `$HOME`. The README gives this exact command:

env bash -c "$(curl -sL https://github.com/telekom-security/tpotce/raw/master/install.sh)"

Follow the prompts, read the messages, and watch for port conflicts, since the honeypots bind well-known ports and anything already listening will collide. The README says to reboot afterwards.

There is also an unattended installation path and a way to test a branch, both documented under Installation, and the installer supports Standard/Hive and Distributed types. After first start, the README lists the landing page, the Kibana dashboard, the attack map, Cyberchef, Elasticvue and Spiderfoot as the access points, with SSH as the remote access method. If you are looking for a T-Pot tutorial, that sequence (requirements, install, reboot, landing page, Kibana) is the whole of it; there is no separate configuration wizard beyond the installer and the config file.

The installer is also available as `install.sh` in the repository root if you prefer to read it before running it, which is the sensible move for a script that will reconfigure the host's networking and start a large set of containers.

The defaults you should change before the host touches the internet

Two defaults deserve attention before deployment. The first is data submission. The README's disclaimer states that by default your data is submitted to Sicherheitstacho, and that you can disable this in `~/tpotce/docker-compose.yml` by removing the `ewsposter` section. The disclaimer then adds, in its own words, that in this case sharing really is caring. That is a clear editorial position from the maintainers, and it is worth being aware that the default is opt-out rather than opt-in. There is a separate opt-in HPFEEDS data submission described in the README.

The second is the honesty of the README about risk. It states that you install and run T-Pot within your responsibility, that a system compromise can never be ruled out, and that honeypots by design should not host sensitive data, with an instruction not to add any. Those are not boilerplate lines. A host running twenty-plus intentionally vulnerable services is a host you should treat as expendable, and the README says so.

Placement matters for the same reason. The README has a System Placement section and sections for running in a VM, on hardware, and in a cloud, plus a Required Ports list. The port list is the practical constraint: if the host already runs a web server, a mail server or a database, you will be reconciling conflicts during install. A dedicated VM or a dedicated piece of hardware avoids the argument entirely.

Where T-Pot is the wrong tool

T-Pot is a collector, not a defence. Nothing in the README describes blocking, filtering or alerting on live traffic; the honeypots log what arrives, and the Elastic Stack makes it searchable. If your goal is to stop an attack in progress, a firewall rule or an IDS rule does that job and T-Pot does not.

The resource floor is the second limit. 8-16 GB RAM and 128 GB free disk is the stated requirement, and that is before you have accumulated much data. On a Raspberry Pi 4 with 8 GB the README documents support, which tells you the platform can run small, but the documentation also has a Troubleshooting section covering RAM and storage and a Log Persistence section, both of which exist because data accumulates. A shared workstation with a few gigabytes free is not a candidate.

The third limit is that this is a target, not a service. The README's disclaimer is explicit that a system compromise can never be ruled out and that honeypots should not host sensitive data. Running T-Pot on the same machine as your build server, your CI credentials or your internal wiki is a category error, regardless of how well the containers are isolated.

Finally, the update path has known rough edges. The README documents a Maintenance section with a General Updates procedure, an Update Script, instructions for updating from an older release, a Restore Script, a daily reboot, and a Known Issues subsection listing Docker images failing to download, T-Pot networking failing, and the update script looping. Those are the maintainers' own reported failure modes, and they are the ones to read before you commit a host.

T-Pot against a plain Cowrie deployment

The obvious alternative is to run one honeypot yourself. Cowrie is a Python SSH and Telnet honeypot, and it is one of the images T-Pot ships. A standalone Cowrie install is a Python application plus a configuration file, and it can run on a small VM with a fraction of T-Pot's footprint. You get SSH and Telnet sessions logged, and you can ship those logs wherever you like.

The difference in approach is scope against weight. T-Pot's value is the breadth of protocols and the pre-built analysis layer: the README lists honeypots for ADB, Citrix, DICOM, Redis, IPP, IEC 104, ICS-related protocols and more, plus Kibana dashboards and an attack map that you would otherwise assemble yourself. What you pay for that is the Compose stack, the tpotinit bootstrap, the data path, the RAM and disk floor, and the update machinery.

A middle option is the distributed deployment type. The README describes a Distributed installation with planning and certificates, sensor deployment and sensor removal, which lets you put sensors in one place and the aggregation elsewhere. That is the right shape if you want the T-Pot collection stack without putting every honeypot on one box.

There is no case in the README for running T-Pot as a library or embedding a single honeypot from it. If you want one sensor, install that sensor.

Licence, updates and the cost of keeping T-Pot current

T-Pot is GPL-3.0. That is the licence of the platform itself, and the README has a Licenses section and a Credits section listing the developers and communities of the bundled software plus the companies and organisations involved. The bundled honeypots and tools carry their own licences, and the README points at them rather than restating them. If you plan to redistribute a modified T-Pot, or to ship it inside a product, read the bundled components' licences as well as the GPL-3.0 text; this is a description of what the repository states, not legal advice.

The maintenance cost is real. The README documents an Update Script, a General Updates procedure, an Updating From an Older Release path and a Restore Script, and it lists the update script looping as a known issue. Releases are infrequent rather than continuous: the most recent listed release is 24.04.1 from 2024-12-11, preceded by 24.04.0 on 2024-04-22 and a deprecated 24.04.0beta on 2024-03-24. The repository itself was last pushed on 2026-09-04, so development activity is more recent than the release tags suggest, but the tagged release you install is not refreshed on a monthly cadence.

Budget for the operational work: a daily reboot is documented, log persistence is a documented concern, and a factory reset and restore path exist because things go wrong. T-Pot is a system you maintain, not a container you start once.

Editorial conclusion

Adopt T-Pot if you have a dedicated host with 8-16 GB RAM, 128 GB of free disk and an unfiltered outbound connection, and you intend to study attack traffic rather than block it. Do not adopt it on a machine that holds production data or credentials: the README states honeypots should not host sensitive data and that a system compromise can never be ruled out. Before you install, check the required ports against whatever else runs on the host, and decide whether you will remove the ewsposter section from docker-compose.yml to stop the default submission to Sicherheitstacho.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. telekom-security/tpotce on GitHub