Jacob Smythe · Security + Infrastructure
← Back to projects
Decepti-Node cover image

published

Decepti-Node

Ephemeral honeypot orchestration on Proxmox for repeatable defensive security testing in homelab conditions.

Published Mar 5, 2026

  • automation
  • honeypot
  • linux
  • proxmox
  • python

Short Summary

Decepti-Node automates repeatable honeypot deployment on Proxmox so defensive testing can start from clean, predictable infrastructure each run.

Problem

Manual VM and LXC setup slowed down lab resets, introduced drift, and made it harder to compare one defensive test run against next.

What I Built

I built repeatable provisioning flow that can deploy isolated targets from templates, apply baseline configuration, collect telemetry, and recycle environment cleanly.

Built With

  • Proxmox VE
  • Linux (LXC and VM targets)
  • Docker
  • Python

Architecture

Decepti-Node uses Proxmox as the orchestration base and Python automation to provision isolated targets from predefined templates.
Each target is configured with constrained compute resources, predictable network placement, and service-level configuration for honeypot scenarios.
The lifecycle flow is: provision -> configure -> monitor -> archive telemetry -> destroy/rebuild.

Decepti-Node architecture diagram

Security and Reliability Decisions

  • Standardized images and resource profiles to reduce environment drift.
  • Used Proxmox lifecycle control for fast rebuilds and predictable rollback to known state.
  • Tuned CPU and RAM allocations so parallel decoy services do not destabilize hypervisor.

Results

Decepti-Node turned ad hoc honeypot setup into a repeatable defensive workflow.
I improved consistency, reduced deployment time, and gained stronger practical experience in Proxmox lifecycle management under resource constraints.

What I Learned

  • Reproducible labs matter more than one-off clever setups.
  • Isolation and rebuild speed make defensive testing more useful.
  • Resource planning is part of security lab design, not separate ops cleanup.
  • Case study: /projects/decepti-node
  • Architecture diagram: /images/projects/decepti-node/architecture.svg

Technical Notes

I started by standardizing target images and defining resource profile for each scenario so deployment would remain predictable even under concurrent runs.
That reduced manual drift and made troubleshooting reproducible across rebuilds.

Then I automated provisioning and post-deploy configuration with Python, including service bootstrap and isolation checks.
I tuned CPU/RAM allocations against host capacity so multiple decoy services could run in parallel without starving hypervisor.

Next improvements: add richer telemetry exports and automated scenario profiles based on attack class.