Treat provisioning as a safe migration
Restaurant routers are rarely blank. They may already contain provider settings, bridges, DHCP servers, cameras, POS routes or VPN tunnels. A universal installer must discover that state before applying changes and must never assume that the default configuration is disposable.
Separate connection setup from guest-network deployment. First establish a secure management path and verify read-only access. Then show the proposed bridge, port, address pool, DHCP, Hotspot and RADIUS changes before applying them.
Make bootstrap imports idempotent
Operators will import the same script more than once. Every command should find and update Nectifi-owned objects or create them only when missing. Existing matching addresses, WireGuard peers, firewall rules and API users should not turn a successful retry into a fatal error.
- Use stable comments and names to identify platform-owned objects.
- Adopt a matching previous object only after validating its address, key or purpose.
- Detect conflicts with non-platform objects and stop with an actionable message.
- Never delete the WAN path, provider route or an unrelated bridge automatically.
Verify remote management in stages
A fresh WireGuard handshake only proves that packets are exchanged with the peer. It does not prove that RouterOS API is reachable or that credentials are correct. Health checks should display the exact successful and failing stage.
- Route to the router WireGuard address
- TCP connection to the configured API port
- TLS handshake when API-SSL is selected
- RouterOS login with the configured service account
- Read-only /system/resource request
Build the guest bridge deliberately
Create a dedicated guest bridge and move only the confirmed guest port into it. If an external access point is used, connect its LAN port, enable access-point mode and disable DHCP on the access point. The MikroTik should remain the gateway for guest DHCP, Hotspot and internet access.
Before moving a port, show its current bridge and link state. Moving the port used by the operator can cut off local access. The interface carrying WAN or the active management route must never be selected as a guest port.
Configure DHCP, Hotspot and RADIUS as one unit
The guest bridge needs one non-overlapping subnet, a matching address pool, DHCP network and server, DNS, NAT masquerade and a Hotspot server bound to that bridge. RADIUS must point to the reachable server address and the Hotspot profile must use RADIUS when external authorization is required.
The portal domain and required authentication endpoints must be reachable before login. Keep the walled garden minimal and verify that its entries match the production hostnames actually used by the portal.
Use a certification gate before launch
- Router is online and the management tunnel is current.
- API login and a read-only resource request succeed.
- Guest bridge, address, DHCP, DNS and NAT are active.
- Hotspot is running on the intended bridge and RADIUS is enabled.
- A real phone receives an address, opens the portal, authorizes and reaches the internet.
- The active session appears once in the dashboard and closes after the configured inactivity window.
Design failure messages for the person fixing the router
A generic failed status creates repeated imports and risky manual changes. Show the component, last successful stage, exact endpoint, safe next step and whether retrying is expected. Cache old errors only as history; the current health view must refresh after a successful check.
The goal is a repeatable setup that a venue can complete once. After certification, normal portal publishing and guest operations should not require staff to open Winbox or edit RouterOS by hand.