Rackpad Automation Roadmap

[Kobii-git]

Rackpad’s next major direction is infrastructure automation.

The goal is for Rackpad to automatically discover, update, monitor, and reconcile as much infrastructure information as possible—including devices, ports, networks, VLANs, IP addresses, DHCP, DNS, compute, Wi-Fi, storage, and health.

This is a directional roadmap rather than a commitment to specific dates or release numbers.

Guiding principles

• Rackpad remains simple to self-host.
• The existing single-container deployment remains supported.
• Automation is introduced safely and progressively.
• Rackpad distinguishes documented intent from live observed state.
• Manual information must not be overwritten unexpectedly.
• External configuration changes require appropriate safeguards and approval.
• All major Rackpad functionality should eventually be accessible through a stable API.

Phase 1 — Automation foundations and public API

Build the shared foundation for every integration:

• Stable object identity and duplicate prevention
• Tracking where automated information came from
• Desired state versus observed state
• Reconciliation and conflict handling
• Durable scheduled jobs
• A versioned public API
• Secure API keys, permissions, webhooks, and credential management

Phase 2 — Optional Rackpad agents

Introduce optional Linux and Windows agents for remote sites, isolated networks, privileged discovery, SNMP, Hyper-V, Windows DHCP/DNS, Redfish, and local monitoring.

Agents will connect outward to Rackpad and will never access the Rackpad database directly. The normal single-container installation will continue to work without an agent.

Phase 3 — Expand existing integrations

Move the existing integrations onto the shared automation foundation and expand what they collect.

Initial focus:

• Proxmox VE
• UniFi Network
• TP-Link Omada
• OPNsense
• Dockhand and Docker
• Microsoft Hyper-V
• VMware vSphere
• Generic SNMP and Redfish

This phase will deepen collection across devices, guests, virtual switches, ports, VLANs, Wi-Fi, storage, firmware, health, and topology.

Phase 4 — Network and IPAM automation

Make Rackpad’s network model continuously self-updating.

Planned capabilities include:

• Switch ports, aggregates, and link state
• Access and trunk VLAN configuration
• LLDP and CDP topology
• PoE and optical information
• DHCP scopes, reservations, and live leases
• DNS zones and records
• IP conflicts and stale assignments
• Scope capacity warnings
• VRFs, overlapping address spaces, and IPv6 foundations

Rackpad IPAM will represent intended allocation, while DHCP and DNS integrations report live state. Observed network links will remain separate from manually confirmed physical cables.

Phase 5 — Major provider coverage

Expand support across major infrastructure platforms, including:

• Cisco, Meraki, Aruba, Juniper, MikroTik, and Arista
• Fortinet, Palo Alto, pfSense, Sophos, Check Point, and VyOS
• Nutanix, XCP-ng, OpenStack, and Kubernetes
• TrueNAS, Synology, QNAP, and Ceph
• Infoblox, BlueCat, NetBox, Technitium, Kea, and PowerDNS
• Dell iDRAC, HPE iLO, Lenovo XClarity, and other Redfish platforms
• Azure, AWS, Google Cloud, UPS, PDU, and environmental systems

Providers will have published support levels so users can distinguish first-class, compatible, community, and experimental integrations.

Phase 6 — Operations and controlled management

Turn collected information into useful operational automation:

• Adoption and conflict workflows
• Infrastructure drift detection
• Dependency and impact mapping
• Maintenance windows
• Configuration backup and comparison
• Firmware, warranty, lifecycle, capacity, and health summaries
• Automation policies and circuit breakers
• Previewable change plans
• Approval workflows
• Verified and audited write-back

Early external actions may include DHCP reservations, DNS records, provider metadata, and approved descriptions.

Higher-risk changes—such as firewall rules, routing, VLANs, port configuration, firmware updates, and destructive VM or storage operations—will require stronger approval and verification.

Long-term outcome

Rackpad should understand what infrastructure is supposed to exist, continuously observe what actually exists, identify differences, explain their impact, and safely perform approved work.

Rackpad will not attempt to replace every hypervisor, network controller, monitoring system, or automation platform. It will coordinate information and automation across them.

The detailed engineering plan is available in docs/AUTOMATION_ROADMAP.md.

Community feedback

1. Which providers should be prioritised?
2. Which public API use cases matter most?
3. Would you deploy a lightweight Rackpad agent?
4. Which changes would you trust Rackpad to automate?
5. Which actions should always require approval?

[afsabresfan]

What are your thoughts on tying to potentially existing infrastructure? For example, I’m running Uptime Kuma for uptime monitoring and Glances on most of my machines to monitor individual server stats. Could there be a way to feed that information to Rackpad rather than running a separate agent?