One terminal, every Navixy service: the new Command Line Interface

Managing a telematics deployment usually means moving between several separate tabs: one screen for devices and geofences, another for automation rules, another for data queries, another for users and permissions. Each switch costs a few clicks and a bit of context. For a single account that's a minor friction. For a channel partner running dozens of clients, or an integrator scripting a rollout across hundreds of vehicles, it adds up fast.

Navixy Console is the new home for that entire setup: one place where organizations, workspaces, connected products, users, and billing come together, instead of being spread across separate tools. It's the control layer that sits above individual products like GPS Tracking, IoT Logic, or IoT Query — where you provision them, connect them, and manage who has access to what.

We are building a command line directly into that Console: a way to manage any connected service — device monitoring, automation flows, events and alerts, data queries, users — by typing a command instead of navigating a menu.

What is the Navixy Console command line?

The Console command line will come in two forms:

• An embedded shell — a collapsible terminal panel built into the Console itself, available on every page.
• A standalone CLI — a native tool for your own terminal, authenticating through the same login as the Console, similar to how the AWS, Google Cloud, or Vercel command-line tools work.

Both will share the same commands, so a script written against one works with the other. The design intent is straightforward: every action available anywhere in Console should also be reachable as a command, following a consistent pattern of nts <service> <command> [options] — for example, listing trackers in a region, creating an automation flow, or toggling an alert rule on and off.

This will sit alongside two other ways to configure the platform: a JSON-based configuration mode for bulk changes and environment replication, and MCP integration for developers and AI agents. All three will operate on the same underlying services, so the way you choose to work — clicking, scripting, or connecting an agent — is a matter of preference, not a different set of capabilities.

One thing the command line is deliberately not: an AI assistant that guesses what you mean. Every command will map to one specific, predictable action. What you type is what happens — no interpretation in between.

How the Navixy Console CLI will help different teams

Fleet and operations teams will be able to handle routine checks and adjustments — pulling a list of offline devices, updating a geofence, enabling a rule — in a single line instead of a sequence of screens, especially useful when doing the same small task many times a day.

Dealers and telematics solution builders managing many customer organizations will be able to script repetitive setup work — creating a new organization, applying a standard configuration, adjusting settings across several accounts at once — instead of repeating it by hand in each one.

Systems integrators rolling out configuration across a customer's fleet will be able to script the setup (flows, rules, geofences) as a repeatable procedure, making a large deployment consistent and easy to redo if something needs adjusting.

Developers building on top of Navixy will get a command set that mirrors what's exposed to automation and AI agents through MCP, so a workflow that starts as a manual command can later be wired into a script or an agent without learning a second interface.

Real-world use cases for the Console command line

Case 1. A dealer standardizing a new customer account. Instead of manually recreating the same device groups, alert rules, and user roles for every new customer, a dealer will be able to export a known-good configuration as JSON from one organization and apply it to a new one with a single import command — cutting a setup that used to take an hour of clicking down to a few lines.

Case 2. An integrator rolling out automation across a fleet. A systems integrator configuring idle-time and geofence alerts for a construction fleet could already automate this through the API. The CLI removes an extra integration step by exposing these capabilities as simple, human-readable commands, so the integrator doesn't need to build and maintain a separate API integration. They can create rules in bulk, reuse the same script across sites, and rerun it whenever the fleet configuration changes.

Case 3. A fleet manager doing a quick daily check. Instead of opening the monitoring dashboard and filtering by status, a fleet manager will be able to ask directly from the command line which trackers are currently offline or which geofences were breached overnight — a habit that fits naturally into a terminal-based morning routine.

Case 4. A developer keeping configuration in sync across environments. A developer maintaining separate staging and production organizations will be able to export the configuration of one and diff it against the other before applying changes, catching drift before it causes an incident.

What's next for the Navixy Console command line

The command line is an early piece of the new Console, currently built as a working prototype with the interface, command structure, and namespaces already in place. The next phase is connecting it to the real Navixy services behind it, service by service, starting with the most commonly used ones.

As this takes shape, we'll share more on which commands are available and how to get started with them. The Console command line is already on our public roadmap — see what else is coming to Navixy and track its progress.