DHCP / static IP for App containers in internal network

RouterOS Containers
1

Currently, App containers (installed via the App store) running in the isolated internal network get an auto-assigned IP using the host+1 scheme — and the App has no way to influence this address. There is no:

  1. Way for the container to obtain an address via DHCP
  2. Way to declare a static IP in the App manifest

The problem:
Apps manage the veth lifecycle themselves — creating, removing, and recreating it on startup. The container IP is therefore unstable: it can change after every restart. Any RouterOS configuration that depends on that IP breaks.

Concrete example: a WireGuard peer has its endpoint pointing to an App container's IP. After a reboot, the App recreates the veth, the IP changes, and the handshake fails. Scheduler scripts can work around this, but that's a hack, not a solution.

Meanwhile, the RouterOS DHCP server already supports Add DNS entries for leases — automatically creating local DNS records for DHCP clients. If an App container could obtain its address via DHCP (or have a hostname permanently tied to it), the problem would be solved natively:

/interface/wireguard/peers/set [find] endpoint-address=my-container.local

Proposed solution:

Let App developers declare in the manifest (or let users configure in App settings) one of:

  • dhcp=yes — container obtains an address via DHCP, appears in the leases table, and with "Add DNS entries for leases" enabled, gets a stable DNS name
  • static-ip=x.x.x.x — a fixed IP that survives veth recreation
  • hostname=my-app — a hostname registered in the router's DNS, always resolving to the container's current IP

Even the simplest option — a DNS hostname for the container — would eliminate the need for scheduler workarounds and make App containers first-class citizens of the router's internal network.

2 Likes