T-Pot fetches its installer from master and runs tpotinit with NET_ADMIN and the Docker socket

The installer is a curl pipe from the master branch, so it is not tied to a release

The documented installation is two steps and one of them is a remote script executed on the spot. curl is installed first if it is missing:

$ sudo [apt, dnf, zypper] install curl

and then the installer runs as a non-root user from $HOME:

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

Look at the URL rather than at the command. It ends in /raw/master/install.sh, so the script your host executes is whatever sits on the master branch at the moment you run it, while the project's releases are tags: 24.04.1 dated December 11, 2024, 24.04.0 dated April 22, 2024, and a 24.04.0beta marked deprecated. The last push to the repository is dated November 2, 2026, well after those tags. The consequence for an auditor is straightforward: there is no released artifact in that command to hash, pin or diff, and a host installed today is not necessarily the same system as one installed from the same instructions last month. The directory you run it from is the other lever, since the instructions are explicit about running as non-root from $HOME.

tpotinit runs in host networking with NET_ADMIN and the Docker socket attached

The compose file describes the whole platform's shape in one service. The tpotinit container is the piece the documentation tells you never to delete, and it is configured like this:

  tpotinit:
    container_name: tpotinit
    env_file:
      - .env
    restart: always
    stop_grace_period: 60s
    network_mode: "host"
    cap_add:
     - NET_ADMIN
    image: ${TPOT_REPO}/tpotinit:${TPOT_VERSION}
    pull_policy: ${TPOT_PULL_POLICY}

Its volume list ends with the Docker socket, mounted read-only at /var/run/docker.sock, alongside the compose file mounted read-only at /tmp/tpot/docker-compose.yml and the data path bind-mounted at /data. Host networking plus NET_ADMIN plus a Docker daemon handle is a privileged-adjacent posture, and the project's own disclaimer says the software is installed and run within your responsibility and that a system compromise can never be ruled out. That sentence is not boilerplate here, it is a description of this service definition. If the host is shared, multi-tenant or under someone else's change control, this configuration is the first thing to argue about.

Every honeypot waits for tpotinit to report healthy before it starts

The other services are written to be strictly downstream of init. The adbhoney service is representative:

  adbhoney:
    container_name: adbhoney
    restart: always
    depends_on:
      tpotinit:
        condition: service_healthy
    networks:
     - adbhoney_local
    ports:
     - "5555:5555"
    image: ${TPOT_REPO}/adbhoney:${TPOT_VERSION}
    pull_policy: ${TPOT_PULL_POLICY}
    read_only: true

Three details matter for operations. The dependency uses condition: service_healthy rather than a plain start order, so a slow init holds back every honeypot and you get an empty-looking platform rather than partial deception. Many honeypots get their own Docker network, named per service in the networks block, which keeps container-to-container traffic separated even though the published ports all land on the same host address. And read_only: true on the filesystem, with explicit volume mounts for logs and downloads, is what lets attacker-written files persist without giving the container a writable layer. The installer's own instruction to check for possible port conflicts and reboot makes sense in this context, since the port map is the part of this file that can collide with something already listening on the machine.

Image tags come from .env variables, so the version is decided in one file

No image reference in the compose file hardcodes a tag. Every service follows the same pattern, including tpotinit:

    image: ${TPOT_REPO}/tpotinit:${TPOT_VERSION}

with pull_policy driven by its own variable, and the environment supplied from a .env file. The repository carries both .env and env.example at the top level, alongside a file named version, a docker/ directory and a compose/ directory, and the shipped docker-compose.yml opens with a comment identifying it as the standard variant, which lines up with the Standard, Hive and Distributed installation types the documentation covers. The advantage is that swapping a repository or a version is a one-file edit. The cost is that the effective version of every running honeypot lives outside the compose file, so a .env left over from an earlier install quietly pins a whole platform to an old tag while the compose file looks current. This is why the documentation carries both an Updating From an Older Release section and a known issue entry for the update script looping.

Data submission to a public dashboard is on until you delete the ewsposter section

The disclaimer states that by default your data is submitted to Sicherheitstacho, and that you can disable it in the config at ~/tpotce/docker-compose.yml by removing the ewsposter section, closing with the remark that sharing is caring. That is the wrong default for most deployments and the compose file shows why it exists: there is a dedicated ewsposter_local network defined alongside the honeypot networks, alongside a separate documented path for opt-in HPFEEDS data submission. If you deploy from the quick start and skim past the disclaimer, your honeypot traffic leaves the host until someone edits a YAML file by hand, and there is no first-run prompt in the compose file asking you to decide. Two consequences follow for a reader. Anything you consider sensitive should never be placed on the platform at all, since the disclaimer says honeypots by design should not host sensitive data. And if you disable community submission, you lose the shared view that makes this kind of deployment more useful than a private one.

The install asks for 8 to 16 GB RAM, 128 GB of disk, and unfiltered egress

The system requirements are stated up front rather than discovered later: the installation needs at least 8 to 16 GB RAM, 128 GB free disk space, and a working outgoing non-filtered internet connection. The disk figure is a floor for a platform that pulls and unpacks 20 or more container images and then retains attacker-supplied payloads and logs. The project also asks you to install the ISO with as few packages and services as possible, keeping ssh, which means the base image is deliberately thin and the honeypot set arrives as containers rather than as installed daemons. The README also has a separate Raspberry Pi 4 (8GB) Support section.

macOS and Windows support is stated as limited to the Docker Desktop feature set

The technical concept section explains that T-Pot's main components were moved into the tpotinit Docker image, which is what allows the platform to support multiple Linux distributions and even macOS and Windows, both limited to the feature set of Docker Desktop. That hedge matters more than it sounds, because the init service depends on network_mode host and NET_ADMIN, and those are exactly the capabilities that behave differently under a desktop container runtime than on a Linux host. The repository reflects the split at the file level, with genuser.sh and genuserwin.ps1 for user creation, a dps.ps1 script, and install.sh, update.sh, restore.sh, uninstall.sh and deploy.sh on the Unix side. So Mac and Windows are supported within that limit. Treat the Desktop limitation as a documented constraint on where you place the sensor rather than as a preference.

The maintenance surface is a set of scripts, and the documentation names its own known failures

The root of the repository is a wall of operational scripts: install.sh, update.sh, restore.sh, uninstall.sh, deploy.sh, genuser.sh, plus PowerShell variants, with installer/, compose/, docker/ and doc/ carrying the supporting pieces. The documentation matches that shape with sections for general updates, the update script, updating from an older release, a restore script, daily reboot, the T-Pot data folder, log persistence, factory reset, starting and stopping T-Pot, the blackhole directory, adding users to the Nginx web interface, and importing and exporting Kibana objects. It also lists its own known issues by name: Docker images failing to download, T-Pot networking failing, and the update script looping. That last entry is the one to read before your first upgrade, because a loop in the update path on a host whose traffic is publicly reachable turns a maintenance task into an outage with a stale dataset. The troubleshooting sections for logs and for RAM and storage exist for the same reason.

Editorial conclusion

Use T-Pot when you have a spare machine, 8 to 16 GB of RAM, 128 GB of free disk and an unfiltered outbound connection, and you are comfortable that a honeypot host gets probed by design. Read the compose file before the first boot rather than after it, because the init service runs in host networking with NET_ADMIN and the Docker socket, and community data submission is on until you remove the ewsposter section. Check which tag you are actually installing: the installer pulls from master while the newest release is 24.04.1 from December 11, 2024, and a copy restored from a data folder is not the same as an upgraded host.

Frequently asked questions

Official sources

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