NetIDE

A desktop workspace for network engineers. It connects to your devices over SSH and works on them directly — one window holding the tree, the terminals, the configurations and the files, instead of six vendor web consoles and a folder of terminal tabs.

Written in Go. Licensed builds for macOS, Windows and Linux, on both arm64 and amd64.

Nothing in NetIDE is simulated. It ships with no devices, and every fact, configuration, directory listing and command reply comes from the device it connected to. If a device cannot be reached, NetIDE says so rather than showing something plausible.

The devices

A device is described with what is needed to reach it and nothing more: name, address, port, type, group, username, and how to log in — SSH agent, private key or password. Everything else is read from the device on connect.

Six types today: Juniper, Cisco, Palo Alto, Fortinet, Linux and Windows.

What you get depends on what it is:

Configuration is fetched read only. Pushing configuration back to a network device is not implemented, and the page says so rather than implying otherwise — the CLI on the right is how a change is made today.

Getting there: jump hosts and proxies

Not every device is reachable from the machine you are sitting at, and a tool that assumes otherwise is a tool for one flat lab network.

A device that is not directly reachable carries a route: the intermediate hosts NetIDE goes through, in order.

• SSH jump hosts — a machine you have an account on that can reach what you cannot. NetIDE logs in and opens the connection onward, which is what ssh -J does; the far end sees it as the client.
• SOCKS5 and HTTP CONNECT proxies — handed the connection to carry onward, with no login of their own. A proxy given a username is one that asks to be logged in to, and is asked for its password at connect time.

Each host is described once and named from the routes that go through it, so a bastion serving a whole rack is one edit when its address changes rather than thirty. The order lives on the device, because which machines you go through is a property of where you are going — one bastion can be the first hop for one rack and the second for another without contradicting itself. The device form spells the route out: this machine > bastion > core > edge01.

Some consequences worth having:

• A jump host's host key is checked like any other, before anything is sent to it. An unknown or changed key stops the connection at the jump host rather than at the device behind it.
• A refusal names the machine that refused. A bastion rejecting a password is a different account from the device's, so NetIDE asks for that machine's password rather than offering the device's.
• A route that cannot be followed stops the connection. It does not quietly fall back to connecting straight at the device — being sent directly at something you asked to reach through a bastion is a different thing to have done, from an address the device may not expect.

What happens on connect

1. The route is resolved and the intermediate hosts are opened in order.
2. The host key is checked against your own ~/.ssh/known_hosts. An unknown key is shown with its SHA256 fingerprint and pinned only if you accept it. A changed key is refused unless you replace it deliberately — and re-pinning is written into the console history with both fingerprints, because that is the moment a device's identity is redefined.
3. Exactly the authentication method you chose is offered. There is no silent fallback, so a failure names the thing that actually failed. Passwords are held in memory for the session and never written to disk.
4. NetIDE asks the device about itself and shows only what it answered.
5. An interactive shell is opened with a PTY.

A device is shown as connected only once all of that is done, so a prompt is never offered with nothing behind it. If the device ends the session — an idle timeout, an exit, a link that dropped — NetIDE says so and goes back to disconnected rather than writing your next command into a pipe with nothing at the other end.

Help → Host keys... lists what known_hosts holds and offers to forget any entry, which beats the alternative of opening the file and deleting line 23 by hand.

The console

A real terminal on a real pseudo-terminal, not a text box that posts commands.

• Enter sends; a box holding several lines sends all of them. Shift-Enter adds another line.
• Up/Down walks the command history — per device, and reaching back past the last restart.
• Tab completes the word under the cursor; press it again to list what it was choosing between.
• Ctrl-C interrupts what the device is printing — or copies, with something selected, as a terminal does.
• Find searches the scrollback and steps through the matches.
• Full-screen programs work: they take a real screen, which is a grid.

Pagers are disabled in the session's environment, because a pager waits for keys with the rest of your answer behind it.

Console history

console.jsonl keeps the last 10,000 lines written to or read from any device's CLI, each a record of when it happened, which device, whether it was a command or an answer, and the text. It is what the command history is built from, so Up reaches back past a restart rather than starting empty, and Help → Console history... opens all of it, filtered by device or by text — because the question is nearly always what did I do to this device or where did that error come from.

It is a record, never replayed into the console: nothing is ever shown as though a live device were talking.

It also records what you type at devices, an enable secret included. The file is private, and NetIDE says so plainly rather than leaving you to find out.

Files

A Linux or Windows host's filesystem is browsed over SFTP in the sidebar, directories listed lazily as you open them. A file is fetched when you open it and written back only when you press Save to device. Files over 2 MiB are refused rather than pulled into a text box.

• The files follow the shell. A cd sent to a device walks the tree to the same directory — a bare cd, cd - and all. Browsing the tree does not move the shell, because one of them has to lead and it is the one you typed in. A cd it cannot resolve leaves the tree where it is rather than moving it somewhere wrong.
• Search knows its own scope. The box above the tree searches the directory on screen and everything under it — not the whole device — and says so, then offers to re-root at / and search the whole thing. That is slower and reads a great many directories, so it is offered rather than assumed.
• Windows hosts are browsed the same way. Remote paths are POSIX even on Windows, so C:\Users\netops is folded on the way out, and going up far enough reaches the list of drives.

Shells on this machine

Above the device folders is This machine — your own login shell, in a pane beside the devices you are working on. Same scrollback, same search, same history, same Ctrl-C. It is your $SHELL, started as a login shell so it reads your profile, on a real pseudo-terminal.

macOS and Linux today. Windows needs ConPTY, which is not wired up yet; devices are reached over SSH on every platform regardless.

The workspace

A day is rarely one piece of work.

Workspaces are chips under the title bar, each with its own editor tabs and its own selected device. Switching puts one set of work down whole and picks the other up whole. Each chip carries the number of tabs put away in it, so a full workspace is told from an empty one without switching to it.

Panes are the row you work in — one editor, and a shell for each thing you are watching. Drag a pane by its header to move it along the row. Drag a device out of the tree and drop it in the work area to open a shell for it, in the place you dropped it. Moving a pane takes its size with it, so a wide editor moved to the right is still wide.

Tabs drag along their strip. The tab in front stays in front, and the order belongs to the workspace.

The first shell always follows the selected device, so clicking a device always changes something you can see. A shell opened beside it is pinned to whatever was selected at the time, and closes itself when that device disconnects — otherwise a day of work collects an empty pane for every device it touched.

All of it is remembered between runs: the panes, the dividers, the tab order, which sidebar view each workspace was left on. A tab is only put back if what is behind it still exists — a device since removed is dropped rather than restored as a tab reporting that it is gone.

Connections are not part of a workspace. They belong to devices, so a session opened in one is still up while you work in another.

Licensing

NetIDE asks for its licence before it does anything else. On a first run the shell is not built until one is installed, so there is never a moment where the workspace exists unlicensed.

The .lic file is about a kilobyte — small enough to email. It is saved beside the inventory and read on every subsequent start, so you are asked exactly once. The licensee is shown in the top right of the title bar with a dot: green while the licence is in force, amber inside the last two weeks, red once it is not. Clicking it gives the full terms and offers to replace the file, which is how a renewal is installed before the old term runs out rather than after.

Where things are stored

The inventory holds addresses, usernames, the authentication method, key paths, and the jump hosts each device is reached through. It never holds passwords, a gateway's included. Writes are atomic and the files are private.

Known limitations

We would rather you read these here than discover them on a Thursday.

• Configuration is read only. Pushing config back to a network device is not implemented; use the CLI.
• Local shells are macOS and Linux. Windows needs ConPTY, which is not wired up yet.
• Passphrase-protected keys are not unlocked by NetIDE. Load them into your SSH agent and choose SSH agent.
• Windows hosts need OpenSSH for Windows installed and running.
• On Windows on ARM, run the amd64 build. Windows 11 on ARM runs it under emulation, and it is currently the only one that opens a window.
• The scrollback is a list of lines, not a grid. It resolves escape sequences, overstrike and blanking, but a shell redrawing a wrapped line can leave a mark at the wrap. Full-screen programs are unaffected — they take a real screen.

Early access

NetIDE is licensed software and is in early access with a small number of teams. If you run a network estate across more than one vendor and have opinions about how it should feel to work on, we would like to hear them.

contact@daydev.org

The DR platform · What else we build