One calm command center for your operational world.

Deploy and version compose stacks, scale and redeploy services, manage nodes, tasks, networks, volumes, secrets, configs, and private registries with live SSE monitoring.

• Stacks & GitLab versioning
• Services, tasks & nodes
• Networks, volumes, secrets, configs

SNMP/ICMP discovery and polling of routers, switches, firewalls, servers, printers, UPSes and more — one unified device model with ports, health sensors, alert rules, traps, syslog, and data-collection auditing.

• Unified devices, ports & sensors
• Modular discovery & polling
• Alerting, traps, syslog & coverage

Organise work in Spaces → Folders → Lists with object-level sharing; run tasks with subtasks, multi-assignees, dependencies, checklists and custom fields across List, Board and Table views; write Docs, comment in threads, and track time.

• Spaces, folders & lists
• Tasks, views & custom fields
• Docs, comments & time tracking

A cryptographic credential vault (envelope encryption, online key rotation) with safes, privileged-account onboarding and discovery, automated change/verify/reconcile, access requests with approvals, brokered recorded sessions, just-in-time and break-glass access, and a tamper-evident audit chain.

• Encrypted vault & safes
• Requests, approvals & sessions
• JIT, break-glass & audit chain

Organise sections, subnets, VLANs and VRFs; inventory addresses with a visual grid; track racks, circuits, NAT and customers; and keep utilisation accurate with scheduled scans, requests, and import/export.

• Sections, subnets, VLANs & VRFs
• Address inventory & scans
• Racks, circuits, requests & vault

Query PostgreSQL, MySQL/MariaDB, MongoDB and Redis targets from the browser: governed connections with envelope-encrypted credentials, a policy-enforced SQL editor with metadata navigation, org-wide query oversight, target session management, and a verifiable audit chain.

• Connections, ACLs & policies
• SQL editor & navigator
• Query Manager, sessions & audit

Record what the platform operates as configuration items of administrator-defined types with typed attribute fields, relate them with ten relationship kinds, and keep a per-item change history with optimistic concurrency. Every item is published to the platform catalog, so global search, catalog links and the other modules see it.

• CI types & typed attributes
• Relationships & history
• Published to the platform catalog

Run the desk on tickets of four kinds with their own state machines, impact × urgency priority, SLA policies whose clocks pause on hold and flag breaches, comments and work logs, a per-ticket history, and links to anything the platform catalogs — with the people a ticket concerns notified through the portal bell.

• Four ticket kinds & state machines
• SLA policies, clocks & breaches
• Linked to the platform catalog

Chain calls to the platform’s module APIs into workflows and runbooks that run as a bound API token — with conditions, retries, compensating rollback, delays, manual steps, approvals and schedules — and keep every run’s step log. A workflow can do exactly what its token can, and never carries a secret.

• Module API steps with retries & rollback
• Manual steps, approvals & schedules
• Run history with a redacted step log

Back up the configuration of routers, switches and firewalls over SSH on a schedule or on request, with the device’s host key pinned and its credential taken from the module vault or Privileged Access. Every version is sealed, unchanged backups are recognized, any two versions can be compared, and secrets are masked in everything a person reads. An approved baseline per device shows drift on every backup, and compliance policies check every configuration.

• Scheduled SSH backups with pinned host keys
• Baselines, drift & compliance policies
• Changes & restores with four-eyes approval

Keep every certificate the organisation depends on in one inventory: read from the TLS endpoints that present them (directly or after SMTP, IMAP, POP3, LDAP or PostgreSQL STARTTLS), found by network discovery, held by the keystores you read (PKCS#12, JKS, JCEKS, PEM — opened in your browser, so neither the file nor its password leaves it), imported, or issued by an internal authority held here. See each certificate’s issuer chain, where it is deployed and was, which certificate replaced it, who owns it and what is weak about it — and hear about it before it expires. Internal authorities issue from CSRs a second person approves, and revoke with signed CRLs; no private key of anyone’s is ever taken, and the authorities’ own keys are sealed by the module vault.

• TLS scans, network discovery & keystores
• Deployments, renewals & expiry notices
• An internal CA: four-eyes issuance & CRLs

Set protection policies — the RPO, the RTO, how often an offsite and an immutable or offline copy must exist, how often a restore must be proven — and put the items in the CMDB under them. Backup jobs, people and Automation runbooks report each backup run and restore test; every item then reads as protected, at risk, breached or awaiting its first evidence, with the reason and a notice when it is breached or its restore test is overdue. What each item depends on in the CMDB graph shows the gaps — a dependency nobody protects, one slower to restore than what needs it — and the order to restore in. DR plans say how each service is brought back; a second person approves each version, and a plan is reviewed on a cadence and flagged when what the service depends on changes. Exercises rehearse the plans as Service Desk changes run by Automation runbooks, and leave their results as evidence. Evidence reports freeze a period and a scope as a PDF and CSV files, each kept with its SHA-256 for an auditor to check. KNetraHub does not connect to backup products: the evidence is reported, and labelled with who reported it.

• Policies with RPO, RTO, copies & restore tests
• Evidence from people, scripts & runbooks
• Dependency gaps & restore order from the CMDB
• DR plans approved by a second person
• Exercises as Service Desk changes & runbooks
• Evidence reports with checksums

Register the Kubernetes clusters you run — from a kubeconfig read in your browser, or with a service account token or a client certificate — and KNetraHub keeps an inventory of each: its nodes, namespaces, Deployments, StatefulSets, DaemonSets, CronJobs, Jobs, pods, services, ingresses and volume claims, with each one’s health and why (a crash-looping container, a rollout stalled past its deadline, a node not ready or under pressure, a service with no ready endpoint), and the warning events of the last days. The credential is sealed by the module vault and never shown again; what it may read — and what it could change, which KNetraHub does only by an operation someone else approved — is checked and shown. Workloads, nodes, namespaces, services and ingresses are published to the platform catalog, so the CMDB imports them and a Service Desk ticket or a Backup & DR policy can name them. Operators read a pod’s log or follow it as it is written — each read audited, nothing kept —; every page shows an object’s events of every type, read live, and usage now from metrics-server; Helm releases show with their chart, version and health, from their resources’ labels and, where an administrator switches it on, Helm’s storage. Where the deployment and an administrator allow it, an operator asks to scale, restart or roll back a workload, delete a pod, cordon a node or suspend a cron job: the cluster checks it as a dry run, someone else approves it with their security password, and it is made on that object only.

• Clusters from a kubeconfig, read in the browser
• Workloads, pods, nodes & network with their health
• Pod logs read & followed, every read audited
• Helm releases, live events & usage now
• Warnings, notices & catalog entries for the CMDB
• Read-only: never exec, never a Secret’s data

Send what an image, a host or an application is made of — an SBOM as syft, Trivy or cdxgen write it (CycloneDX or SPDX), or a host’s package list from dpkg, rpm or apk — from the page or from a pipeline with an API token, and KNetraHub matches every component against the security advisories of the ecosystems you keep: OSV’s feeds for Debian, Ubuntu, Alpine, Wolfi, Chainguard, Rocky Linux and AlmaLinux, and for npm, PyPI, Maven, Go, crates.io, NuGet, RubyGems, Hex and Pub, downloaded daily from OSV or a mirror of it, or uploaded where nothing is downloaded. Each ecosystem’s versions are ordered as its own tools order them (dpkg, apk, rpm, SemVer, PEP 440, Maven, NuGet, RubyGems), an operating-system package is matched as its source package and only for the release it came from, and each finding says the version that fixes it. Findings open when an inventory or a feed brings them and are fixed — with the reason — when an upgrade leaves the range, the package goes or the advisory is withdrawn; the owner hears of new critical and high findings. Nothing is scanned, pulled or patched: the module reads what it is sent.

• SBOMs & package lists, from people or pipelines
• OSV feeds for 16 ecosystems, downloaded or uploaded
• Each ecosystem’s own version order
• Findings with the version that fixes them
• Where a package is used, at which version
• Notices for new critical & high findings

Point your devices’ syslog at KNetraHub — UDP, TCP (newline or octet-counted framing) or TLS — or have a shipper post lines over HTTP with a key of its own: Fluent Bit, Vector, Logstash, rsyslog, anything that sends NDJSON, a JSON array or plain lines. Each source says whose lines it takes (address ranges, host names), how they are read (RFC 5424 and 3164 as devices really send them, JSON, CEF, key=value pairs, or a dissect pattern of your own), how long they are kept (a retention class) and who may read them. Card numbers and secrets are masked before anything is kept. Search by words, phrases and fields, count them over time and by value, open a line with the lines around it, follow a query live and export what it matches — every search recorded in a search log. Keep a search under a name, and put the counts you watch on dashboards — lines over time, top values, numbers, the newest lines —, yours or shared, each read over the sources its reader may read; counts over days come from counts kept beside the lines, the same numbers read faster. Open a device’s, a node’s or an item’s lines from its own page, and let correlation rules tell you when lines of different searches belong together — failed logins then a success from one address — within a window. Lines live in the module’s own PostgreSQL database, in daily partitions each class drops when its days are past.

• Syslog over UDP, TCP & TLS; HTTP with per-source keys
• RFC 5424/3164, JSON, CEF, logfmt & dissect patterns
• Cards & secrets masked before anything is kept
• Words, phrases & fields; histograms & top values
• Saved searches & dashboards, yours or shared
• A resource’s lines from its page; correlation rules
• Live tail, context & export — every search logged
• Retention classes, a source readable by the tier it names

Run nginx, Caddy, Traefik or HAProxy tenants on your Docker Swarm from one place — internal, external or in the DMZ, each with its own engine, routes, upstreams, TLS, networks, resources and placement. Describe a tenant once in the guided editor (listeners, TLS, routes with WebSockets, SSE, gRPC, rate limits, basic authentication, caching, headers and allow lists; upstreams with balancing, health checks and stickiness; compression, security headers, timeouts) and the engine adapter renders the engine’s own file; or take the Expert editor with the engine’s completion and lint. Every change is an immutable revision with its rendered files and diff; a deployment runs preflight against the swarm (eligible nodes, networks, port conflicts, the orchestrator’s dry run), applies only the tenant’s service as content-addressed secrets through the Docker module, waits for the tasks to run and answer their healthcheck, and rolls back on its own when they do not. External, DMZ and restricted tenants need a second person’s approval with the security password. Health and drift are checked on a schedule, traffic is counted from the access logs, certificates — yours, self-signed, or issued by a Certificates-module authority for a key that never leaves the module — ring the bell before they lapse, and the Docker module refuses to touch what the Proxy Manager owns.

• nginx, Caddy, Traefik & HAProxy behind one canonical configuration
• A wizard that checks nodes, networks & ports against the swarm
• Guided editor & Expert editor with completion and lint per engine
• Immutable revisions, file diffs, dry runs & selective service updates
• Approvals for external, DMZ & restricted tenants; step-up auth
• Health, drift & automatic rollback; traffic from the access logs
• Certificates: yours, self-signed, or from the Certificates module
• Shared or dedicated stacks; the Docker module keeps hands off