Node64 in the Homelab: A Honeypot That Reads the Caddy Log, Plus Ten Service Checks

On 6 November 2026 we started Node64 on the Caddy gateway of our homelab. The honeypot does not open a single port. It reads Caddy's access log, the same way CrowdSec does. Ten checks run beside it, and their results show up in the same dashboard. This post covers how we built it, what already works, and what we cannot prove yet.

What Node64 is

Node64 is an open-source container from ipv64.net with several modules: checks for services and certificates, a honeypot, a reverse proxy, a DNS filter and a dynamic DNS client. It ships as a single program, stores its data in one SQLite file and is licensed under Apache 2.0. We use only the checks and the honeypot, both locally and without an account.

We read the license in the LICENSE file of the repository. On 6 November 2026 the repository showed 17 stars, 3 forks and a last push on 5 November; version 1.0.0 came out on 4 November. The project is very young, so we treat this as an experiment.

How it is wired

Node64 runs as a container in the same Docker project as Caddy and CrowdSec on the gateway. Its web interface sits behind the Caddy snippet (trusted), a list of allowed source addresses. Every other address gets an empty response. We checked this from a server that is not on the list: status 200 with zero bytes.

The log reaches Node64 through a directory that we mount read-only into the container. Two things had to change for that. By default Caddy writes its log with mode 0600, which the container cannot read. The Caddy documentation describes a mode option for this, and ours is now 0640. The container also joins the group of the Caddy user.

The honeypot profile is "Only via PROXY64", the one without trap services of its own. Reporting to ipv64 is set to "off" and no API key is stored. According to the documentation, Node64 sends nothing without a key unless you switch it on explicitly.

What a honeypot is

A honeypot is a service or an analysis step that exists only to make attacks visible. Nobody with a legitimate purpose ever calls it, so every hit is suspicious and shows which addresses, paths and credentials attackers try. It does not protect anything by itself. It gives early warning and raw material for blocklists.

What ran on 6 November 2026

In the Healthchecks 2.52.2 interface we created twelve checks. Ten are running and two were deleted again.

Own measurement on 6 November 2026. Test bed: Alpine Linux container on the homelab gateway, Node64 1.0.1, Honeypot64 0.19.0.

The two deleted checks pointed at DNS servers in the company network. Nothing there answers requests from the homelab, not even SSH. That is the firewall between the two zones, and it is meant to be that way. Checks for those servers belong in a monitor inside the company network.

The last row of the table links the two parts. It queries the honeypot's API and counts as failed as soon as it reports at least one hit. An alert then only needs a notification channel, which we have not set up yet.

What we cannot prove yet

After the start the log sensor had read 73 lines, shortly afterwards 278, so it has found the file and follows it as traffic arrives. Up to the time of writing it had zero hits. As a test we requested /.env and /wp-login.php on our website from an allowed address. Both returned 404, and the honeypot still reported nothing. Possible reasons are a threshold for repeated requests or an exception for known addresses. The documentation does not say which, and we did not want to repeat the test from our own address, because CrowdSec on the same gateway blocks scanner patterns. We are waiting for real scan traffic from the internet and will report whether it finds any.

How updates behave is also open. We no longer pin the image to a digest, so the nightly update run renews it together with the other containers. If a new version breaks something, the only way back is to pin the old digest again.

Related

How we block requests at the gateway is covered in CrowdSec instead of fail2ban. The reverse proxy itself is described in Reverse Proxy with Caddy: HTTPS by Default. More on hardening and privacy sits in the Security and Privacy section. If you want a setup like this for your network, see our IT services.

Thanks

Thanks to Prox IT and the team behind ipv64.net and Node64. They publish the project under Apache 2.0, describe in the documentation exactly what is reported and what is not, and let you run all of it without an account.

Further sources

Primary sources

• Node64, Honeypot64 documentation: node64.de
• Node64, source code and Apache 2.0 license: github.com/ipv64net/node64
• Node64, changelog with version 1.0.0: node64.de
• Caddy, the log directive with the mode option: caddyserver.com

Own measurement

• All values in this post come from our homelab on 6 November 2026. We did not take over any vendor figures on performance or detection rate.