HELIX NMS+

Every ISP operation,
in one pane.

See all 131 capabilitiesTry the live demo

A read-only demonstration on synthetic data for a fictional ISP. Guest sign-in details

New in 1.9.0 · BetaAn AI digital NOC and SOC for every organisation

A traditional MikroTik Network Management System with the plus built in.

Built in

  • Cloud Management
  • Deep Monitoring
  • Device Maintenance
  • Billing & Finance
  • SPLYNX Integration
  • IPAM
  • Alerting & Incidents
  • Multi-Tenancy
  • Backups & Recovery
  • AI NOC & SOC

Arriving next

  • AGENTIC Orchestration
  • Kronos DNS Security
  • SD-WAN
  • New in 1.9.0
  • Daily briefing in beta

A digital NOC and SOC for every organisation.

Few ISPs can staff a network operations centre and a security operations centre around the clock. Helix’s AI engine takes the first watch. Every night at 03:00 it reviews the last 24 hours of your network, across the organisation and router by router, and writes a briefing of what happened, what matters and what to do about it. During the day it answers questions about your network in plain words, in the console or in Telegram.

Digital NOC

Is the network healthy?
  • Traffic against the week before, outages, BGP and OSPF peers that flapped, ports that kept losing link and links running at their limit.
  • Alerts, backups and firmware, checked every day.
  • Every finding carries its evidence, an action, and whether it is new, still open or resolved since yesterday.
  • Explain with AI on a traffic graph and on the VLAN map.

Digital SOC

Is anyone getting in?
  • Bursts of failed logins against a router, and an address that failed again and again and then got in.
  • A login from the internet over telnet, FTP or Winbox, where a password crossed the internet or a console is open to it.
  • Your own team’s console accounts: a sign-in from a new country, a suspicious sign-in, repeated failures.
  • Management services open to the internet, and configuration changes that were not made through Helix.
How the AI engine works as a digital NOC and SOCWhat Helix already measures (traffic, routing, backups and firmware for the NOC; router logins, console sign-ins and configuration changes for the SOC) flows into the Helix AI engine. Code rules raise findings first, for every organisation. The AI half runs on top of them only with the owner’s consent, with names replaced and within a budget. The results are a daily briefing and alerts and answers in the console and Telegram, and a person decides what to do. The engine never writes to a router.What Helix already measures, every dayTraffic & portsNOCRouting & outagesNOCBackups & firmwareNOCRouter loginsSOCConsole sign-insSOCConfig changesSOCHelix AI enginereads stored data only, opens no router sessionCode rules firstevery organisation, every dayevidence and an action on eachmarked verified by codeno AI and no consent neededowner consent · stand-ins · budgetAI on top of the rules03:00 briefing · assistantExplain with AI · TelegramDaily briefingfindings · evidence · actionAlerts and answersin the console and in TelegramA person decides and actsthe engine never writes to a router
  • Nothing reaches the AI model until your organisation’s owner agrees.
  • Router and customer names are replaced by stand-ins before anything leaves.
  • It reads what Helix already measures, and it never changes a router.
  • Every AI call is reserved against your organisation’s monthly cap first.
  • During the beta, Helix pays for the daily sweep.
How the AI NOC and SOC worksTalk to us

What has landed since September.

Up to release 1.9.0. Everything in this grid is built and reachable in the console today.

A wall for the operations room

A tile for every router with its health, the ten busiest interfaces, subscribers and routers, and the open incidents beside them, full screen if you want it. Rows move only when the change is real, a router that stops reporting says so, and the routing and spanning-tree cards say how many routers they read rather than giving an all-clear.

Graphs for every router

Processor, memory and traffic for each router over the last hour, day, two days and the full period your plan keeps, with the peak and the 95th percentile drawn in. Any interface can be graphed, quiet ones included, and a gap in the data is drawn as a gap.

Telegram, both ways

Link your own account once and ask the assistant from your phone about routers, the busiest ports, incidents or backups. Alerts your organisation sends can arrive in the same chat as they happen, from the severity you choose. It answers only in a private chat, checks your role on every message, and nothing runs from a chat.

A VLAN map across your network

Every VLAN in your organisation and where it runs: which routers carry it, how it appears on each one, and the links between routers with the evidence for each. A router Helix has not read yet is named as not read, never shown as having no VLANs.

Bring the subscribers you already have

Helix reads the PPPoE logins, business VLAN clients and static public-IP clients already on your routers and puts them into billing without writing anything to the router. Each profile or rate becomes a priced plan; anything it cannot adopt is listed with the reason.

Suspensions that say whether they bit

When you suspend a client you are told whether the cut actually reached them. A missing firewall rule, logins held on a RADIUS server, or a router that redirects to a payment page are each named, instead of a record that says “suspended” over a line that is still up.

Holds, reminders and statements

Freeze a customer’s billing with a reason and a review date. Overdue reminders now chase one-off charges too: installations, equipment, arrears. Print a statement of account with a running balance for any period.

Kenyan tax on the invoice

Record a corporate customer’s KRA PIN and every invoice prints it, along with the service it bills. A customer marked tax-exempt is charged no VAT, and excise still applies.

WebFig through the proxy

The router’s own WebFig in your browser, for routers with no direct route, on RouterOS v7 as well. You sign in to the router yourself: the proxy handles no router password at all, and it is open to organisation admins only.

Early access: the Traffic and Graphs views of the monitoring page, which rank every interface, client and router and open a full graph behind every row; routing monitoring for BGP, OSPF and LDP; and the bridge and spanning-tree checks. All are built; none has much production mileage yet.

What the plus actually stands for.

A network management system tells you a router is down. It cannot tell you that the customer behind it paid this morning, that the address it holds was never recorded anywhere, or that another system is about to bill them again. Those are the questions that cost an ISP money, and every one of them needs two halves of the business in the same place.

One dashboard over the whole operationA single console pane showing the router fleet, subscriber billing and address space together rather than in separate tools.cloud.helixnms.comFleetmonitoredSubscribersbilling liveAddress spaceIPAM
What the plus in NMS+ stands forA MikroTik network management core surrounded by billing, Splynx integration, IPAM and an AI digital NOC and SOC, which are available today, and by Kronos security and SD-WAN, which are upcoming and drawn with broken outlines.Billing & BSSSplynxIPAMAI NOC & SOCKronosSD-WANNMS coremonitor · configurebackup · upgrade

Below is the whole of it, with the honest state of each part beside it. Available now means built, reachable and in production use. Early access means built and reachable, with little or no production mileage yet. Upcoming means designed and not built — named here because an ISP plans in years and a roadmap you cannot see is one you cannot plan against.

We publish the difference rather than smoothing it over. You are being asked to hand a system your entire network; a vendor who blurs that line before you buy will blur it afterwards too.

MikroTik NMS core

Monitoring, telemetry, syslog, configuration baselines, backups with diffs, and firmware orchestration with downgrade blocking and a low-flash pre-flight.

Available now

Private-IP device management

Routers behind carrier NAT reached over a Helix-managed OpenVPN tunnel the device brings up itself — with Winbox, a web terminal and the router’s own WebFig proxied through it.

Available now

Billing and ISP BSS

Plans, subscriptions, recurring invoices, Customer 360, cash desk, bank reconciliation and credit notes — and the subscribers already on your routers brought into billing without writing anything to the router.

Available now

Dunning and auto-suspend

Overdue escalation and reminders, off unless you turn them on. When you suspend a client, Helix says whether the cut actually reached them — and if it did not, why: no firewall rule using the list, or logins held on a RADIUS server rather than on the router.

Early access

Splynx integration

Full API integration: tariff and subscriber import, automated cohort migration, payments read back, and dual-mode running while both systems are live.

Available now

IPAM

Address-space inventory, allocation under a per-block lock, discovery from the routers themselves, and an ICMP liveness view. Built and hardened; not yet carrying a production estate.

Early access

Routing monitoring

BGP peers, OSPF and LDP neighbours and route-table size, read from each router every five minutes without changing it. A peer that is configured but never came up is listed, not left out, and a peer going down raises an alert.

Early access

AI NOC and SOC

A daily AI briefing on the last 24 hours of your network and its security, with evidence and an action on every finding, and an assistant that answers in plain words and lists the data it read. It changes no router. Nothing is sent until your organisation’s owner agrees, and names are replaced by stand-ins first.

Early access

Agentic orchestration

An agent that PLANS and never touches a router: it emits an intent, the existing policy layer admits or refuses it, and the existing queue executes and audits it.

Upcoming

Helix Kronos security

DNS policy and filtering as a managed tier — a resolver plane with licence-gated threat feeds, and a read-only firewall snapshot taken before anything is written.

Upcoming

SD-WAN and WireGuard

Per-tenant tunnel namespaces, WireGuard alongside the existing OpenVPN planes, and policy routing across sites. Additive by design — no forced cutover of remote CPE.

Upcoming

Your routers do not have public IPs. That is fine.

Most MikroTik management tools assume they can dial the router. On a real subscriber estate that assumption fails immediately: CPE sits behind carrier NAT, addresses are dynamic, and the customer’s own router is the one you most need to reach when something breaks.

Helix inverts it. During enrolment the device runs a single generated script that brings up an outbound encrypted tunnel — carrying its own certificate — and from that moment Helix manages it exactly as if it were directly addressable: configuration, backups, firmware, telemetry, Winbox, port forwards. No static IP. No port forward on the customer’s side. No site visit.

Certificates are per-device and revocation is real: deleting a device revokes its certificate at the next nightly rebuild, and regenerating one revokes its predecessor.

Two OpenVPN planes run side by side, because RouterOS v6’s client speaks a narrower set of algorithms than v7 — so v6 hardware is admitted without weakening the plane that carries everyone else.

Upcoming: WireGuard alongside the existing planes, per-tenant tunnel namespaces, and SD-WAN policy routing across sites. Additive by design — a forced cutover of remote CPE over the very tunnel being replaced is a self-inflicted outage, so existing devices stay where they are.

Reaching a router that has no public addressThree subscriber routers behind carrier NAT each open an outbound encrypted tunnel to Helix, which manages them as if they were directly addressable.CPE 110.0.0.2 · privateCPE 210.0.0.3 · privateCPE 310.0.0.4 · privatecarrierNATHELIX NMS+manages all three directly

Integrated, migrated, or both at once.

Helix speaks to Splynx over its API as a first-class integration rather than a CSV bridge. Connect an instance with a signature-auth key and Helix reads tariffs, customers, services and payments directly.

Automated migration runs in stages you control: import the tariff catalogue as plans, dry-run the subscriber migration and read the result before anything is written, then apply in cohorts filtered by tariff — so a corporate cohort and a residential one move separately, on different days.

Dual-mode operation is the part that matters during a real cutover. Splynx keeps billing and enforcement; Helix runs in observe mode, reading and reporting and refusing to cut anyone off. Every automated path that could suspend a subscriber consults that gate — including the paths that cut service by removing an account rather than by suspending it.

Placement is observed, not inferred: which router a subscriber sits on is determined from the routers themselves — a live session, or a per-client queue — never from an administrative field. A subscriber no device claims is refused by name rather than guessed onto a router, because a wrong device means that client cannot be suspended and their usage is read from somebody else’s queue.

Any subscriber both systems would invoice is named, with their Splynx service id, on every billing run — so the duplicate is a line in a report rather than a phone call from the customer.

Running alongside Splynx during a migrationSplynx keeps billing and enforcement while Helix reads subscribers, tariffs and payments over the API. Helix reports any subscriber both systems would bill and withholds its own enforcement until the operator hands it over.Splynxstill billingstill enforcingHELIX NMS+reading · reportingenforcement withheldcustomers · tariffspayments read backDouble-billing detectornames every subscriber both systems would invoice

The money half is not an afterthought.

Recurring plans, ad-hoc invoices for installations and arrears, a cash desk, bank-statement reconciliation, credit notes, wallets, and dunning you configure rather than inherit.

How money reaches the ledgerRecurring plans, ad-hoc invoices and credit notes raise a charge. Payment arrives on three rails — card, a cash desk, and a pasted bank statement — and all three meet at reconciliation, where every row is parsed before anything is written. A row that cannot be read is reported with its line number rather than dropped. What survives is written to the ledger. An outage observed by the monitoring half returns along the only backward path on the figure, as a credit note. Three gates sit underneath the whole arrangement: currency must be stated, every row belongs to exactly one organisation, and dunning is configured rather than inherited.RAISEDARRIVESCHECKEDRECORDEDRecurring planmonthly, per subscriptionAd-hoc invoiceinstallations, arrearsCredit noteunder a policy you setCardcollected automaticallyCash desktaken in personBank statementpasted, then parsedReconciliationevery row parsedbefore a writea row that cannot be read isreported with its line numberLedgerwallets, credit notes,arrears, receiptsan outage the monitoring half observedBEFORE ANY OF IT RUNSCurrency is statedor it refuses to invoiceOne organisationchecked on every rowDunning you configureautomation ships off
Three ways money arrives, one place it is checked, one ledger it lands in. The dashed path is the only one that runs backwards: an outage the monitoring half observed, returning as a credit note under a policy you set.

Manual billing is first-class

Not every ISP collects by card. Raise an invoice by hand, take payment at the desk, paste a bank statement and see exactly what parsed before anything is written — a row that cannot be read is reported with its line number rather than silently dropped.

Five service models, provisioned properly

PPPoE, static public IP, DHCP reservation, dedicated VLAN and hotspot. Each writes the objects that service actually needs — a lease, an ARP pin, a shaping queue, a bridge VLAN entry — tags them as ours, and tears down only what it tagged.

Disconnection stays your decision

Automated suspension ships switched off. An organisation that has never chosen a policy is treated as not having chosen one, rather than as having agreed to a default — because a row nobody wrote is not a decision anybody made.

Outages can credit themselves

An outage the monitoring half observed can raise a credit note in the billing half, under a policy you set. With no policy configured it withholds rather than guessing: an issued credit is money off a ledger, and a withheld one is recoverable.

Currency is never assumed

An organisation states what it prices in before it can raise an invoice, and Helix refuses rather than defaulting. A default prints the wrong currency on a document that leaves the building.

Multi-tenant to the row

Every device, customer, plan and invoice belongs to exactly one organisation, checked on every request. Working across tenants needs an active agreement naming both parties — a pending one authorises nothing.

HELIX NMS+works withMikroTik RouterOS

We wrote our own RouterOS client, and it is the reason the rest works.

The RouterOS engine, in cross-sectionProvisioning, monitoring, suspension, backup and upgrade all enter one engine and pass through four layers: a resolver that emits the form both RouterOS dialects accept, a guard that reads an empty collection as an answer rather than as an unreachable device, a bounded session pool that never exhausts a router’s shared API budget, and a feasibility check that reads the hardware before acting on it. Underneath, a virtual CHR on a development lane and a physical RouterBoard on a production lane feed hardware evidence back up into the engine before any device-facing change ships.EVERY OPERATION, WITHOUT EXCEPTIONProvisionMonitorSuspendBack upUpgradeONE ENGINE · MAINTAINED HEREDialect resolverEmits the form both dialects acceptv6v7bothEmpty-collection guard“No rules” is an answer, not a failure[ ] → answeredkeptSession poolBounded — one per operation, released at onceceilingFeasibility checkReads the hardware before it touches itflash · model · dialectreadhardware evidence, before anything shipsDEV LANECHRvirtual, in our own labPROD LANERouterBoardphysical, on real firmware
Every operation enters the same engine and passes through the same four layers. The arrows underneath run the other way: a virtual CHR and a physical RouterBoard feeding hardware evidence back up into it before a device-facing change is allowed to ship.

Everything Helix does to a router goes through one Node RouterOS engine we maintain ourselves — not a wrapper around a library that happens to speak the protocol. That sounds like an implementation detail until the protocol misbehaves, and on a real fleet it does.

The clearest example: from RouterOS 7.18 a router answers an empty collection with a reply the common client library throws on — from an event emitter, where no caller can catch it. So “this device has no firewall rules” came back as “this device is unreachable”, on 58 of 65 online routers, and it grows with every firmware upgrade. Every “does this object already exist?” check a provisioning run makes — the lease, the ARP pin, the queue — is exactly that read, and each one is empty the first time a client is set up. We found it, fixed it in the connector, and verified the fix on live hardware across the version boundary.

The same engine enforces the thing every fleet tool gets wrong: session discipline. A MikroTik router allows a fixed number of concurrent API sessions and shares that budget with the operator’s own Winbox. Fan out carelessly across a fleet and you lock the engineer out of their own router during the incident they are trying to fix. Every fleet operation here runs through bounded concurrency, one session per operation, released immediately.

Dialects

v6 and v7, as two languages

They are not one product with a version number. Tokens that are correct on v7 are parser-fatal on v6 — and RouterOS aborts an entire import on a parse error, so a single wrong word silently configures nothing. Where the two disagree, Helix emits the form both accept; where v6 has no equivalent at all, it refuses rather than quietly measuring something else.

Hardware

CHR and RouterBoard

Virtual and physical behave differently in ways that matter: available flash decides whether a router can be upgraded remotely at all, and a 16 MB board cannot take a modern image however the upgrade is scheduled. Helix checks feasibility before it touches anything, and says so instead of failing halfway.

Validation

Proven on real routers

Device-facing changes are held to hardware evidence on both dialects before they ship — a CHR and a physical RouterBoard in our own lab, and a restoring test against real hardware where the lab cannot reproduce a case. Reasoning from the documentation is not accepted as evidence; three findings have been withdrawn here after the hardware disagreed with them.

MikroTik and RouterOS are trademarks of MikroTik (SIA Mikrotīkls). HELIX NMS+ is an independent product and is not affiliated with, endorsed by or certified by MikroTik. The mark is shown to identify the systems this product manages.

Written by people who had to run the fleet.

These are not design preferences. Each one is a defect that reached production somewhere and is now a rule.

RouterOS is two dialects wearing one name

Commands v7 accepts are refused outright by v6, and a v7-only integration silently does nothing on older hardware rather than failing loudly. Every device-facing change here is verified on both dialects, on real routers, before it ships.

Sessions are a scarce, shared resource

A router's API session limit defaults to 20 and is shared with the operator's own Winbox. Fleet operations run under bounded concurrency with one session per device, so a sweep can never lock you out of your own equipment.

Empty is not the same as unknown

A reading that could not be taken is shown as unknown, never as zero. Telemetry gaps render as gaps. A failed load says it failed rather than rendering an empty list that reads as "there is nothing here".

The device is the source of truth

A subscription is marked active only once the router confirmed it. If the device was unreachable, the intent is recorded and retried and the console says so — instead of showing a green status over a line that was never provisioned.

What is not settled yet.

HELIX NMS+ is pre-GA and in live production use. Some capabilities are proven on real hardware across a live fleet; some are proven only in test. We publish the difference.

  • The features list on this site is filtered. It shows only what is built and reachable by a user. Unfinished and unreachable work is tracked under separate statuses and none of it is published there — so a capability on that page is one you can use.
  • Early access means early. IPAM, routing monitoring, the monitoring Traffic and Graphs views and the AI assistant are built and have little production mileage. They are labelled that way here rather than counted as shipped.
  • The daily AI briefing is in beta. It runs every night for every active organisation with a live router, at Helix’s cost while the beta lasts. Where the owner has not agreed to AI, the briefing is built by the code rules alone and says so.
  • Upcoming means not built. Agentic orchestration, Kronos and SD-WAN are designed and scheduled, not delivered. No date is printed on this page, because a date we cannot keep is worse than none.
  • Automated disconnection ships switched off. Turning it on across a live fleet is a decision with a support queue attached, and it stays yours.
Read the documentationSee what changed

See it against your own estate.

The most useful first conversation is a read-only look at your routers: what they run, what they expose to the internet, which of them could not be upgraded remotely today, and which subscribers your systems disagree about. Nothing is written to any device to produce it.

Or look around first: the live demo is the same console, read-only, on synthetic data for a fictional ISP.

Open the consoleMore from Helix