Skip to content

Automated Proxmox Homelab Monitoring & Update Pipeline with n8n

One configuration file. One weekly report. No need to check every container by hand.

As my homelab grew, checking each Linux container individually stopped being a useful routine and started becoming maintenance overhead. I wanted a system that could tell me what needed attention—without automatically making changes I had not reviewed.

The result is a weekly n8n workflow that turns a changing Proxmox container inventory into a concise, actionable Telegram report.

Project at a glance

Every Sunday at 9:00 AM, n8n reads a GitHub-hosted containers.json file, checks the listed APT-based LXCs on Proxmoxnik01, and turns the results into one Telegram digest. Available updates, clean systems, and failed checks are visible at a glance. Any maintenance action remains behind explicit human approval.
Role Homelab administrator and workflow builder
Environment Proxmox VE host Proxmoxnik01 with Linux LXCs
Schedule Weekly — Sunday at 9:00 AM
Source of truth GitHub-hosted containers.json
Notifications Telegram digest and approval flow
Availability monitoring Uptime Kuma
Status Working foundation; multi-host and platform-specific expansion deferred

Image placeholder — n8n workflow overview showing the scheduled scan, configuration fetch, container checks, and Telegram digest.

Why I built it

Maintaining several Linux containers one at a time is manageable at first. As the environment grows, however, logging into each container, refreshing APT metadata, reading the results, and remembering what needs attention becomes a repetitive weekly chore.

Simply automating those commands was not enough. Hard-coding every container into n8n would mean rebuilding the workflow whenever the environment changed. I wanted the automation to follow the infrastructure—not fall behind it.

The goal was to separate what should be managed from how it should be checked. A small JSON file defines the current inventory, while n8n provides the reusable orchestration around it.

This project focuses on three practical outcomes:

  • one place to maintain the list of managed containers;
  • one weekly summary instead of several disconnected checks; and
  • a deliberate approval point before maintenance is applied.
The challenge The response
Container inventory changes over time Read targets dynamically from containers.json
Individual checks create fragmented results Combine them into one weekly digest
Failed checks can be easy to overlook Report failures alongside successful results
Unattended updates can introduce risk Keep execution behind a Telegram approval step
Update status does not equal service health Use Uptime Kuma as a separate availability signal

Scope

The current workflow targets standard Debian/Ubuntu-style LXCs that use APT. Docker-aware update handling, OpenWrt support, and coordination across multiple Proxmox hosts are future extensions rather than capabilities claimed by this version.

Architecture

flowchart LR
    A["Sunday 9:00 AM<br/>n8n schedule"] --> B["Fetch containers.json<br/>from GitHub"]
    B --> C["Validate and expand<br/>container inventory"]
    C --> D["Proxmoxnik01"]
    D --> E1["APT-based LXC 1"]
    D --> E2["APT-based LXC 2"]
    D --> E3["APT-based LXC n"]
    E1 --> F["Collect update results"]
    E2 --> F
    E3 --> F
    F --> G["Build weekly digest"]
    G --> H["Telegram notification"]
    H --> I{"Approval received?"}
    I -->|Yes| J["Approved maintenance path"]
    I -->|No / no response| K["No changes applied"]

    U["Uptime Kuma"] -. "service availability" .-> D

The design keeps several concerns separate:

  1. Inventory — GitHub stores the container list.
  2. Orchestration — n8n schedules and coordinates the workflow.
  3. Execution — update checks run against the configured LXCs on Proxmoxnik01.
  4. Communication — Telegram presents a concise weekly digest and approval path.
  5. Availability — Uptime Kuma independently monitors whether services are reachable.

Monitoring and maintenance are different signals

Uptime Kuma answers, “Is the service reachable?” The n8n workflow answers, “Does this managed container report APT updates?” Keeping those responsibilities separate makes each tool easier to understand and troubleshoot.

Configuration as the source of truth

The workflow begins by dynamically fetching containers.json from GitHub. That file is intentionally small and human-readable, so adding an eligible LXC does not require rebuilding the workflow.

containers.json
{
  "proxmoxHost": "Proxmoxnik01",
  "containers": [
    {
      "id": 101,
      "name": "example-service",
      "platform": "apt",
      "enabled": true
    },
    {
      "id": 102,
      "name": "internal-tool",
      "platform": "apt",
      "enabled": true
    }
  ]
}

The example values above are illustrative. The real inventory can be updated without placing credentials or other secrets in the repository.

Secrets stay outside the inventory

Repository files should contain non-sensitive configuration only. Proxmox access details, Telegram tokens, and other credentials belong in n8n credentials or another protected secret store—not in containers.json or workflow exports committed to GitHub.

Weekly workflow

At a high level, the automation follows this sequence:

Schedule trigger
  → Download containers.json
  → Validate the configuration
  → Keep enabled APT targets
  → Check each LXC for available updates
  → Normalize success and failure results
  → Build one Telegram digest
  → Wait for explicit approval
  → Continue only on the approved path

A simplified n8n Code node can filter and expand the downloaded inventory:

Prepare enabled APT targets
const config = $json;

if (!config.proxmoxHost || !Array.isArray(config.containers)) {
  throw new Error('Invalid container configuration');
}

return config.containers
  .filter((container) => container.enabled && container.platform === 'apt')
  .map((container) => ({
    json: {
      host: config.proxmoxHost,
      containerId: container.id,
      containerName: container.name
    }
  }));

The update check is based on the standard APT workflow. In practice, the exact remote-execution wrapper depends on how access to the Proxmox environment is configured.

Representative APT update check
apt-get update -qq
apt list --upgradable 2>/dev/null | sed '1d'

Failure is data too

A container that cannot be reached should appear in the weekly report as a failed check. It should not silently disappear from the digest, because a missing result may be more important than a successful “no updates” result.

Telegram digest and approval

Instead of sending a message for every package or container, the workflow groups results into a weekly operational summary. A useful digest includes:

  • scan time and Proxmox host;
  • containers checked successfully;
  • number of available updates per container;
  • containers with no available updates;
  • checks that failed or timed out; and
  • an explicit approve/cancel choice for the maintenance path.
Example Telegram digest
Weekly LXC Update Digest — Proxmoxnik01

Checked: 5 containers
Updates available: 2 containers
No updates: 2 containers
Check failed: 1 container

• example-service — 6 packages available
• internal-tool — 2 packages available
• monitoring — no updates
• documentation — no updates
• sandbox — check failed

Review the results before approving maintenance.

Human-in-the-loop by design

The scheduled scan reports what it finds; it does not treat detection as permission to change systems. The approval flow preserves a review point before the maintenance branch proceeds.

Image placeholder — redacted Telegram update digest with the approval controls visible.

Reliability and operational safeguards

The project is small, but the workflow benefits from the same habits used in larger operations environments:

  • Validate input early. A missing host, malformed JSON document, or absent container list should stop the run with a clear error.
  • Keep targets explicit. Only enabled containers with the supported apt platform enter the current workflow.
  • Preserve per-container results. One failed check should be reported without hiding successful checks for the remaining containers.
  • Require approval. Discovery and reporting can run unattended; system changes require a separate decision.
  • Protect credentials. Tokens and access details remain outside the GitHub configuration file.
  • Monitor independently. Uptime Kuma provides an external view of service availability rather than relying on the update workflow as a health check.

Outcomes

The resulting foundation improves routine homelab maintenance without presenting it as a fully autonomous patch-management platform.

  • The managed LXC inventory is centralized in one readable file.
  • The weekly scan is repeatable and scheduled for a predictable maintenance cadence.
  • Telegram provides a single overview of update status and failed checks.
  • The workflow can add or remove supported containers through configuration rather than duplicated n8n branches.
  • Approval remains visible and intentional before the maintenance path continues.
  • Uptime Kuma complements the workflow with ongoing availability monitoring.

The most important outcome is not simply that commands run on a schedule. It is that the workflow converts several low-level checks into a single decision point: what needs attention this week, and am I ready to act on it?

What I learned

Configuration should drive orchestration

Moving the inventory into containers.json reduced coupling between the workflow and the environment. The n8n logic can stay stable while the homelab changes around it.

Automation still needs boundaries

Scheduling the discovery step is low risk; automatically applying every update is a different decision. Separating those stages made the workflow easier to trust and safer to expand.

Useful reports include exceptions

A clean “everything is fine” message is only valuable when failures are visible too. Normalizing timeouts and connection errors into the digest prevents incomplete runs from looking successful.

Platform differences matter

APT provides a consistent starting point for Linux LXCs, but OpenWrt and Docker workloads have different update models. Treating them as dedicated future workflows is clearer than forcing every system through one generic command path.

Future improvements

The next iterations are intentionally staged:

  • add support for multiple Proxmox hosts with host-specific routing;
  • create a dedicated OpenWrt update-check path;
  • add Docker-aware image and Compose update reporting;
  • record historical scan results for trend and audit views;
  • add maintenance-window rules and clearer approval expiry behavior;
  • produce post-maintenance verification that can be compared with Uptime Kuma status; and
  • add structured retry and escalation rules for unreachable containers.

Design principle

Start with observable, reviewable automation. Expand the level of autonomy only after the reporting and failure paths are dependable.

Tech stack

Technology Purpose in this project
Proxmox VE Hosts the Linux containers on Proxmoxnik01
n8n Schedules and orchestrates the weekly workflow
GitHub Stores the versioned containers.json inventory
Linux / APT Provides the update-check mechanism for supported LXCs
Telegram Delivers the weekly digest and approval interaction
Uptime Kuma Monitors service availability independently
JSON Defines a simple, portable source of truth

Closing note

This project demonstrates a practical approach to homelab operations: centralize configuration, automate repetitive checks, report exceptions clearly, and keep consequential actions reviewable. The current implementation has a deliberately narrow scope—one Proxmox host and standard APT-based LXCs—but its configuration-driven design provides a clean base for future expansion.

Interested in the workflow?

Want to learn more about the n8n workflow or discuss how the design works?

Email me at [email protected] and mention the “Proxmox n8n workflow.”