OpenCanary Honeypot on Ubuntu: 2026 Home Lab Setup Guide

I first wrote about OpenCanary years ago, and that old version badly needed an update. The tool is still useful, but the way I would deploy it in a home lab today is different: newer Ubuntu versions, Python 3, Docker as an option, cleaner logging, and no copy-pasted example credentials that look like something someone might actually reuse.

This guide is the updated version: how I would set up an OpenCanary honeypot on Ubuntu in 2026 for a small home network or homelab. The goal is not to trap random people on the internet. The goal is to create a quiet internal warning system: a fake service that should never be touched, so any connection to it deserves attention.

Important: this is a defensive security guide. Run OpenCanary only on systems and networks you own or have permission to monitor. Do not expose a honeypot to the public internet unless you understand the logging, legal, abuse and maintenance implications.

If you are building a Linux home server security setup from scratch, start with the broader Linux Home Server Security Guide and the Linux Home Server Security Checklist. OpenCanary is useful, but it is not a replacement for basic hardening.

What OpenCanary is

OpenCanary is a lightweight honeypot. It pretends to be one or more network services, such as SSH, FTP, HTTP, MySQL, Redis, Telnet, VNC or other common targets. If something connects to one of those fake services, OpenCanary logs the event and can alert you.

In normal language: it is a tripwire.

On my own network, a honeypot is useful because there are very few legitimate reasons for a laptop, phone, IoT device or random container to connect to a fake SSH or Telnet service. If it happens, I want to know. It might be a misconfigured script, a compromised device, an over-curious scanner, or just me testing something and forgetting about it. Either way, the alert is useful.

OpenCanary is maintained by Thinkst Canary. The official project describes it as a daemon that runs canary services and sends alerts when those services are used. The current project documentation also notes that Linux gives the most complete feature set, and that OpenCanary has very low resource requirements, making it suitable for a small VM, old laptop or Raspberry Pi-class host. OpenCanary GitHub

What OpenCanary is not

OpenCanary is not a firewall, not an intrusion prevention system, and not a magic security box. It will not harden SSH for you, block brute force attempts, patch Docker containers or replace backups.

I treat it as one layer in a small defensive stack:

UFW decides what should be reachable.
Fail2ban reacts to repeated login failures.
Lynis helps find hardening gaps.
Docker security basics reduce avoidable container mistakes.
OpenCanary tells me when something touches a service that should be fake and quiet.

Where to place a honeypot in a home lab

A honeypot works best when it looks slightly interesting but does not hold anything important.

For a home lab, I would place OpenCanary on a small Ubuntu VM, an old laptop, a low-power mini PC, or a dedicated container host. I would not install it on the same machine that stores my important files, password manager data, backup disks or production containers.

Good placement

A small Ubuntu VM on your homelab server.
An old laptop connected by Ethernet.
A low-power mini PC on the same LAN as your other servers.
A separate VLAN or isolated network segment if you already use VLANs.

Bad placement

Your main NAS with real family photos and documents.
Your Docker host running all production services.
Your router or firewall.
A machine directly exposed to the internet “just to see what happens”.

The most useful home-lab setup is boring: OpenCanary sits on the LAN, pretending to be a few services. Nothing in your house should normally touch it. When something does, you investigate.

Network safety before installing

Before deploying a honeypot, decide what you want to learn from it. I usually keep the first setup simple:

One small Ubuntu host.
One static IP address.
No port forwarding from the internet.
A few fake services enabled.
Logs written locally first.
Email or webhook alerts added only after the basic logs work.

If you already have a firewall policy, document it. If you do not, this is a good moment to read UFW Firewall Rules for Home Servers before opening extra ports.

Install option 1: Docker Compose

Docker is the easiest way to experiment because it keeps the OpenCanary files together and makes cleanup simple. The official OpenCanary project notes that Docker images are useful on Linux Docker hosts and that the host network engine is needed for accurate network information.

I would use this method for a lab machine where Docker is already part of the setup.

Install Docker on Ubuntu

sudo apt update
sudo apt install -y docker.io docker-compose-plugin git
sudo systemctl enable --now docker

Add your user to the Docker group if you want to run Docker commands without sudo:

sudo usermod -aG docker "$USER"

Log out and back in after that. If this is a remote SSH session, be careful not to interrupt anything important.

Clone the OpenCanary repository

cd ~
git clone https://github.com/thinkst/opencanary.git
cd opencanary

The repository includes a Docker Compose file and a sample data directory. The official instructions say to edit the data/.opencanary.conf file and then start the container with Docker Compose.

Back up the sample config

cp data/.opencanary.conf data/.opencanary.conf.original

Now edit the configuration:

nano data/.opencanary.conf

Start OpenCanary with Docker Compose

docker compose up latest

In another terminal, watch the logs:

docker compose logs latest

To stop it:

docker compose down

Note: Dockerized OpenCanary is very convenient, but not every OpenCanary feature behaves the same way in Docker. The official documentation notes that the portscan module is automatically disabled for Dockerized OpenCanary. If you specifically want portscan detection, use the direct Linux install and read the project documentation carefully.

Install option 2: Python virtual environment on Ubuntu

If you do not want Docker, install OpenCanary directly in a Python virtual environment. This is closer to the traditional deployment method and gives you more direct control.

The current OpenCanary README lists Python 3.10+ as a prerequisite and gives Ubuntu 22.04/24.04 installation commands using Python 3 packages, not the older Python 2-era packages that used to appear in many old guides.

Install dependencies

sudo apt update
sudo apt install -y python3-dev python3-pip python3-virtualenv python3-venv python3-scapy libssl-dev libpcap-dev

Create a virtual environment

mkdir -p ~/opencanary-venv
cd ~/opencanary-venv
python3 -m venv env
. env/bin/activate

Install OpenCanary

pip install --upgrade pip
pip install opencanary

Create the initial configuration

sudo env "PATH=$PATH" opencanaryd --copyconfig

This should create:

/etc/opencanaryd/opencanary.conf

Edit it:

sudo nano /etc/opencanaryd/opencanary.conf

A safe starter configuration

OpenCanary can emulate many services. The official configuration reference lists services such as SSH, FTP, HTTP, HTTPS, MySQL, MSSQL, Telnet, SNMP, VNC, Redis, TFTP, NTP and TCP banner services. OpenCanary configuration reference

For a first home lab deployment, resist the temptation to enable everything. Start with a few services that make sense for your network.

Example idea:

Fake SSH on a non-standard port if your real SSH is already on 22.
Fake HTTP to look like a forgotten admin panel.
Fake Telnet only if you want to detect old-device style probing.
Local file logging first, email/webhook later.

Here is a simplified configuration fragment. Do not paste it blindly over the whole file. Use it to understand the settings, then adapt the generated config.

{
  "device.node_id": "homelab-opencanary-01",
  "ip.ignorelist": [
    "127.0.0.1"
  ],
  "ssh.enabled": true,
  "ssh.port": 2222,
  "http.enabled": true,
  "http.port": 8080,
  "http.skin": "nasLogin",
  "telnet.enabled": true,
  "telnet.port": 2323,
  "logger": {
    "class": "PyLogger",
    "kwargs": {
      "handlers": {
        "file": {
          "class": "logging.FileHandler",
          "filename": "/var/tmp/opencanary.log"
        }
      }
    }
  }
}

Notice that I am not publishing a real username/password pair here. If you use honey credentials, make them obvious placeholders in documentation and never reuse passwords from your real systems.

About honey credentials

A honey credential is a fake credential that should never be used legitimately. If something tries to use it, that is interesting.

The dangerous mistake is to publish a real-looking credential in a public blog post, then forget where it came from. That is why this guide uses placeholders only.

"telnet.honeycreds": [
  {
    "username": "example-user",
    "password": "REDACTED_EXAMPLE_PASSWORD"
  }
]

If you create your own honey credentials, keep them fake, unique and clearly labelled. Never use them on a real account. Never reuse them from another lab. Never paste private tokens, SSH keys or real passwords into OpenCanary examples.

Run OpenCanary directly

For the Python virtual environment install, start OpenCanary like this:

cd ~/opencanary-venv
. env/bin/activate
sudo env "PATH=$PATH" opencanaryd --start --uid=nobody --gid=nogroup

The --uid and --gid options tell OpenCanary to drop privileges after binding to ports. The official README also uses this pattern. It is a small detail, but it is worth keeping.

Check whether it is running:

ps aux | grep opencanary

Check the log file:

sudo tail -f /var/tmp/opencanary.log

Test from another machine

Do not only test from the OpenCanary machine itself. Use another machine on the same LAN.

Replace 192.168.1.50 with your OpenCanary host IP:

nc -vz 192.168.1.50 2222
nc -vz 192.168.1.50 8080
nc -vz 192.168.1.50 2323

Then check the OpenCanary logs. You should see events with the source IP of the testing machine.

If you do not see anything:

Confirm the OpenCanary process/container is running.
Confirm the ports in the config match the ports you tested.
Check whether UFW is blocking access.
Check whether Docker networking is configured as expected.
Check the log file path in the config.

Firewall rules

If this honeypot is only for your LAN, allow only your local subnet to reach it. Do not open it to the world.

Example for a LAN using 192.168.1.0/24:

sudo ufw allow from 192.168.1.0/24 to any port 2222 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 8080 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 2323 proto tcp
sudo ufw status verbose

If you need a UFW refresher, I have a full guide here: UFW Firewall Rules for Home Servers.

What alerts mean

An OpenCanary alert does not automatically mean you have been hacked. It means something touched a fake service.

I would triage alerts like this:

Source IP: which device made the connection?
Service: which fake service was touched?
Time: did it happen during your own testing?
Pattern: was it one connection or repeated probing?
Context: did a new device, container or script appear recently?

In a home lab, many alerts will be boring. A monitoring container, a phone app, a vulnerability scanner you forgot about, or a script from another server can all produce noise. That is fine. The point is to learn what normal looks like, so abnormal stands out.

Where to send alerts

Start with local logs. Once you trust the setup, you can add alerting.

Good alert destinations:

A local log file.
Syslog to another machine.
Email alerts.
A webhook to a private notification system.

Do not start by wiring alerts to every possible notification channel. You will just train yourself to ignore them. Run the honeypot for a few days, see how noisy it is, then decide what deserves an immediate alert.

Common mistakes

Putting the honeypot on a valuable machine

Do not combine your honeypot with your main file server, backup server or password manager host. Keep it boring and disposable.

Exposing it to the internet too early

Public honeypots attract noise fast. That can be interesting, but it is a different project. For a normal home lab, start internally.

Enabling every service

If everything is enabled, the logs become messy and the honeypot looks less believable. Pick a small personality. A forgotten NAS, a fake admin panel or an old Linux box is more believable than a machine pretending to be everything at once.

Publishing real-looking credentials

Documentation should use placeholders. Your real lab should use fake credentials that are unique to the honeypot and never reused anywhere else.

Not checking the logs

A honeypot you never check is just another service running on your network. At minimum, look at the logs after the first day, then weekly, then whenever you change the network.

How I would use this in a small home lab

My practical setup would be:

A small Ubuntu VM called homelab-canary-01.
Static IP outside the DHCP pool.
No public port forwarding.
Fake SSH on 2222.
Fake HTTP on 8080.
Maybe fake Telnet on 2323 if I want to detect old-device style scans.
Local logs first.
Email/webhook alerts only after I know the noise level.

I would then add it to my normal security routine:

Review OpenCanary logs once a week.
Review UFW rules after adding new services.
Run Lynis after major OS changes.
Test backups, because detection is not recovery.

If you have Docker services on the same network, read Docker Security for Homelab Beginners and Backing Up Docker Containers. A honeypot is useful, but it should sit beside good hardening and recovery habits.

Quick troubleshooting

OpenCanary starts but I see no alerts

Test from another host, not from the same machine.
Check that the service is enabled in the config.
Check that the port in the config is the port you are testing.
Check UFW or any upstream firewall.
Check Docker logs if running with Docker Compose.

The service will not bind to a low port

Ports below 1024 usually require elevated privileges. For a lab, using high ports such as 2222, 8080 and 2323 is simpler and safer.

Docker logs are empty

Confirm the container is running:

docker compose ps
docker compose logs latest

Then confirm the config file is mounted and edited in the expected location.

I get too many alerts

Reduce the number of enabled services. Add known safe management hosts to an ignore list only if you understand the trade-off. Do not ignore entire subnets just to make the logs quiet.

Final thoughts

OpenCanary is one of those tools that is easy to overcomplicate. The best home-lab setup is simple: one small host, a few fake services, logs you actually read, and no public exposure until you know what you are doing.

Used that way, it is a nice addition to a defensive Linux home server setup. It will not secure the network by itself, but it can tell you when something unexpected is poking around.

If you are building the full security baseline, I would read these next:

References used while updating this guide:

Written by MS

MS is a Linux homelab and cybersecurity enthusiast who documents practical experiments with home servers, Docker, firewalls, backups, Lynis, Fail2ban, honeypots and old hardware. The guides on IT Random Stuff are based on hands-on testing, real configurations and lessons learned from running Linux systems at home.