26. Network and servers

Provision and manage your bare-metal servers and network switches from one place — and let the AI propose changes you approve before anything ships.

At a glance

Daalu can manage the configuration of your network switches and the lifecycle of your bare-metal servers — and let its AI agents propose, and you approve, changes to both. This chapter explains what the feature does, how to turn it on, and how a change flows from “the AI noticed something” to “it’s applied on the device.”

Behind the scenes Daalu runs a managed configuration engine for your network fabric and a managed provisioning service for your servers. You never touch either directly — Daalu provisions them for you, gives you per-area web addresses, and drives them on your behalf. You work entirely in the Daalu UI.

26.1 What it manages

Each piece is optional — you choose what Daalu manages.

26.2 Where it runs (and why your data stays put)

The management stack runs in your environment — either a Daalu-operated cluster or your own — never inside Daalu’s shared service. Daalu’s hub connects to it over a secure, outbound-only tunnel. For regulated or data-sensitive operations, you can require it to run entirely in your own cluster. Either way, you get a set of private, per-organization web addresses for each component.

26.3 Turning it on (the provisioning wizard)

From Managed infra → Onboarding → Network & server management:

1. Choose where it lives — Daalu’s cluster (default) or “my own cluster.” If you pick your own, you’ll first connect it with the cluster-tunnel step (a one-time secure handshake — see Chapter 15).
2. Pick the components you need. Three ready-made profiles:
   • Lean — config and change management for existing devices.
   • Standard — Lean plus zero-touch provisioning of new network devices.
   • Full — everything, including built-in network boot services and a read-only config browser.
3. Pick a size — small, medium, or large, based on how many devices you manage.
4. Provision. Daalu builds the stack for you (this takes a few minutes on first run — you’ll see a progress indicator) and then shows you your private URLs.

When it finishes you’ll have addresses like https://your-org.cm.daalu.io (the config browser) and matching addresses for each service. These are simply per-organization web addresses for each component, secured with automatic TLS. You don’t need to log into them for day-to-day work — Daalu drives them for you — but they’re there if you want to look.

Note — Server provisioning needs the right hardware. It works with standard bare-metal servers that have a BMC (iDRAC / iLO / Redfish). If a step in the wizard is greyed out, it’s telling you your fleet doesn’t meet a prerequisite — Daalu will say which one.

26.4 Onboarding your devices and servers

Once the stack is up, add your inventory — switches and servers alike — through the Inventory screen (or by importing a list). Everything lives in one shared source of truth, so a server and a switch sit side by side and Daalu knows how to manage each.

For a brand-new server, Daalu can take it from powered-off bare metal all the way to a booted, configured host: it network-boots the machine, installs the OS image you chose, applies your first-boot settings (hostname, login keys), and then keeps the OS in line going forward.

26.5 How a change happens — find → suggest → approve → apply

This is the part that makes it Daalu and not just a config tool. The loop is the same for a switch config change, a server reconfigure, or a power action:

1. Find — an agent notices something (an alert, drift from intent, a capacity signal, or you asking for a change).
2. Suggest — the AI explains the issue and proposes a specific fix, with its reasoning and a confidence score.
3. Approve — you see the proposal (and, for config changes, the exact diff) in the Daalu UI and click Approve or Reject. Nothing touches a device until you approve.
4. Apply — Daalu carries out the approved change on the device and reports back: success, or failure with the reason. Network config changes are applied with commit-confirm and automatic rollback, so a bad change backs itself out rather than stranding a device.

You stay in control at the approval step every time. The AI can find and propose all day; only an approval turns a proposal into a real change.

26.6 What you’ll see in the UI

• Recommendations — AI suggestions waiting for your decision.
• Change proposals — the formal record of a proposed device change, its diff, who approved it, and the outcome. This is your audit trail.
• Inventory — your switches and servers, their state, and their intended config.
• Events feed — live updates as deploys complete, drift is detected, or a server finishes provisioning.

26.7 Setting it up fresh — what you provide

A first-time setup is mostly Daalu’s job: when you finish the wizard (§26.3), Daalu builds the entire management stack for you and hands you the URLs. What you provide depends on where it runs.

If it runs on Daalu’s cluster (the default)

Almost nothing. Click through the wizard, pick your components and size, and Daalu provisions everything — the configuration engine, the workflow engine, the shared source-of-truth database, and their storage. You then add your inventory (§26.4). This is the recommended path for most customers.

If it runs on your own cluster (“bring your own”)

You’re giving Daalu a Kubernetes cluster to install into, so a few one-time prerequisites must be true. The wizard checks these and tells you, by name, anything that’s missing before it will provision:

1. Connect the cluster. Complete the one-time cluster-tunnel handshake (a secure, outbound-only link from Daalu’s hub to your cluster — Chapter 15). The wizard walks you through it; your platform team applies one manifest and approves the peer. Nothing in your cluster is exposed to the public internet.
2. Platform basics (installed once). Your cluster needs a small set of standard platform capabilities present before the first tenant stack — a way to publish the per-service web addresses, automated TLS for them, managed Postgres for the stack’s databases, and persistent storage. If you don’t already run these, Daalu’s onboarding team sets them up with you; they’re cluster-wide and shared by every stack, configured once.
3. Capacity. A management stack is a modest workload — a few dozen pods plus a handful of small databases. Make sure the nodes you’re dedicating have room for it alongside your other workloads. Daalu will tell you if scheduling is blocked.
4. Your own domain (optional). Daalu manages the *.cm.daalu.io addresses by default. If you’d rather host the stack under your own domain, you can point a wildcard (*.cm.<your-domain>) at your cluster — Daalu’s team will give you the exact target.

For server provisioning (either location)

Server lifecycle management needs bare-metal hosts with a BMC (iDRAC / iLO / Redfish) reachable on your management network, and a site with the provisioning service. This is set up per site (it can’t be shared across locations) — Daalu’s team stands it up with you. If a server step in the wizard is greyed out, it’s telling you a hardware or site prerequisite isn’t met yet.

After provisioning

Once the wizard finishes and shows your URLs, the stack is live. You add switches and servers in Inventory (§26.4) and start the find → approve → apply loop (§26.5). You don’t log into the underlying tools for day-to-day work — Daalu drives them for you.

26.8 Frequently asked

Do I have to use the per-service web UIs? No. Daalu is the primary surface; those UIs are optional and read-mostly.

Can I manage only servers, or only network? Yes — the two are independent feature toggles. Turn on whichever you need.

What if I already run my own source of truth (Nautobot)? Daalu can use the one it provisions as the shared source of truth, or you can connect your own — see Integrations (Chapter 24) and the catalog (Chapter 38).

Is anything applied automatically without me? No device change is applied without an approval. Read-only discovery and health monitoring run on their own; they don’t change anything.

Next: Chapter 27 — Usage and pricing