Answers before you ask

A Configuration Management Database (CMDB) is a centralised repository that stores information about your IT assets and the relationships between them. It gives IT teams a single source of truth for every server, workstation, network device, software licence, contract, and service in their environment, along with the dependencies that connect them.

Kovira is built for IT professionals of every shape: internal IT teams, sysadmins, IT consultants, and managed service providers. Plans scale from a single technician on the free tier all the way up to organisations with unlimited seats and multi-tenant workspaces. The same CMDB and ITSM platform underpins every plan.

ServiceNow is an enterprise platform that takes months to deploy and assumes a dedicated platform team. IT Glue is documentation-first with limited CMDB depth. Kovira sits in the middle: a proper ITILv4-aligned CMDB with dependency mapping, incident and change management, workflow automation, and endpoint agents, sized for IT teams from solo admins through to organisations with unlimited seats.

IT asset management tracks what you own: serial numbers, warranty dates, purchase costs, and lifecycle status. A CMDB goes further by mapping the relationships and dependencies between those assets. In Kovira, every configuration item can be linked to other CIs through typed relationships, so you can see that a particular server runs a particular service, which depends on a particular database, which is covered by a particular support contract. This dependency awareness is what makes a CMDB essential for change management and incident response.

Yes. Kovira is ITILv4-aligned for incident, change, and configuration management. The platform is built around the practices auditors and frameworks expect: a configuration item model with dependency mapping, a change workflow with independent approvals and impact analysis, an incident workflow with priorities and SLAs, and a tamper-proof audit trail across the lot.

Minutes for the basics: create a workspace, invite a colleague, and start adding records. Days for a full rollout including a network discovery pass with VECTOR, ATLAS agents on managed endpoints, and a Microsoft 365 sync if you use it. That contrasts with enterprise platforms that typically take months and a dedicated implementation team before the first ticket is logged.

Kovira is built and operated from Australia. The platform is hosted on infrastructure in Australia by default, and customer data (including configuration items, documents, audit logs, and document storage) stays in region. Data residency for other regions is on the roadmap as customer demand reaches the threshold to justify a dedicated regional deployment.

No. Kovira is a hosted SaaS platform and self-hosting is not on the roadmap. The hosted model is a deliberate choice: it lets us keep the platform secure, current, and identical for every customer, and it means security patches reach every workspace at the same time without anyone having to schedule a maintenance window. Source-available licensing is something we may revisit later, but the platform is closed source today and we do not provide installation packages for customer-managed environments.

Not in a public document. We share what we are working on through release notes when features ship, and we are open about the major directions in conversation: deeper integrations with the platforms IT teams already use, broader regional data residency, more native triggers and actions in the workflow engine, and continued depth in the ITILv4 surface. If a specific capability is on your shortlist, ask and we will tell you whether it is in flight.

English at launch. Localisation into other languages is on the roadmap and will be driven by where customers are deploying Kovira. The data model itself is unicode-clean, so configuration items, documents, and audit records support any language regardless of the interface language.

Yes. The free tier includes one technician seat, 50 configuration items, up to 50 ATLAS agents, 50 MiB of document storage, the full CMDB and ITSM platform, mandatory MFA, and the complete audit trail. VECTOR network scanning and ATLAS endpoint agents are included. Upgrade when you need more seats, CIs, storage, or higher API throughput. Kovira is launching soon, register your interest to be notified.

Four plans: Free, Teams ($25 AUD per technician per month), Business ($55 AUD), and MSP ($65 AUD). Every plan includes the full platform. The differences are seat count, configuration item limits, document storage, monitored mailbox count, API throughput, and (on MSP) multi-tenant workspaces. Billing is per technician seat, not per managed device or per client.

Yes. You can move between plans whenever your needs change. Your data carries over without migration steps, and you only pay for the plan you are currently on. The free tier is open ended: there is no time limit and no requirement to convert to a paid plan.

Yes. There are no annual lock-ins. Cancel any time and your account stays accessible to the end of the current billing period. Before the account closes, you can export your data so nothing is lost.

Yes. The MSP plan adds multi-tenant workspaces with full client data isolation, so each client has its own configuration items, incidents, documents, and audit trail. Technicians can switch between client workspaces without logging out. Billing is per technician, with no per-client surcharge.

Australian dollars (AUD) by default. Support for additional currencies is on the roadmap.

Downgrades are pro-rated, so you only pay for the plan you are on. Cancellations do not generate refunds for partial months, but your workspace stays accessible to the end of the current billing period and you can export your data before it closes.

Yes. Annual billing comes with a discount when paid up front. A non-profit and education tier is available on request: get in touch with details about your organisation and we will sort it out.

Anything you track as an asset in Kovira: devices, networks, services, racks, domains, software, people, groups, vendors, locations, contracts, documents, passwords, APIs, and licences. Operational records (incidents and changes) are also CI types in the model so they get the same dependency mapping and audit trail, but they do not count against your plan's CI limit.

Soft-cap warnings, no surprise charges. As you approach your limits the workspace flags it; if you go over, the workspace continues to function so nothing breaks while you decide whether to upgrade or trim. Existing records remain readable either way.

Because the work the platform actually supports is the technicians using it. Per-CI pricing punishes thorough inventory: every device, contract, and licence you bother to track raises the bill, so teams under-document to keep costs down. Per-technician pricing inverts that incentive. Add as many configuration items as your environment actually has, and only pay for the people doing the work. The free tier and starter plan have CI caps so we can size infrastructure honestly, but mid-tier and up are unlimited on CIs.

Reseller arrangements for MSPs and IT consultants who want to bundle Kovira with their service offering are available; reach out and we will work it out case by case. We are not running a formal partner certification program at launch, but the per-technician pricing and multi-tenant MSP plan are designed to make reselling clean from day one.

Once Kovira launches, set-up is a matter of minutes: create an account, name your workspace, and start adding configuration items. There are 19 built-in CI types with purpose-built fields for each, so you do not need to design a data model from scratch. Run VECTOR against your network to seed the CMDB with what is already out there, and roll out ATLAS agents on the machines you manage. When the same device appears in more than one source, Kovira recognises it and keeps a single record.

Yes. Most teams seed their CMDB by running VECTOR against their network and rolling out ATLAS agents, which together populate device, network, and endpoint records automatically. For data living in spreadsheets or other tools, you can import via the public API or by syncing from Microsoft 365. Documents, contracts, and other governance records are added directly in the app.

Yes. Kovira replaces spreadsheet-based asset tracking with a proper CMDB: typed fields, dependency mapping, audit trails, version history, role-based access control, and impact analysis before you make changes. Spreadsheets go stale the moment someone forgets to update them. With VECTOR and ATLAS, Kovira keeps your inventory current automatically.

Minutes for a single subnet. Larger estates take longer in proportion to size, and very large networks can run for a while on a first pass. VECTOR is safe to leave running: it is read-only, throttled, and designed to coexist with whatever else is on the wire.

No. Kovira is a hosted SaaS platform. Self-hosting is not on the roadmap. The hosted model is what lets us keep the platform secure, current, and the same across every customer.

Kovira is designed for IT professionals, but no programming is required for day-to-day use. The workflow builder is visual, configuration items use typed forms rather than freeform schemas, and reports come out of the box. If you can run an IT environment, you can run Kovira.

Hands-on onboarding for paid plans is available. The platform is built to set up without a consulting engagement, so most teams walk through it themselves in a couple of hours. For larger rollouts (a fleet of ATLAS agents, a Microsoft 365 sync across multiple tenants, a migration from another ITSM tool) we will jump on a call and walk through the planning. Implementation is not a separate paid product; it is part of getting customers successful on the platform.

Days, not months, in most cases. Documentation tools (IT Glue, Hudu, Confluence pages) export cleanly into Kovira's CI types and document structures. Discovery is what makes the migration end rather than turn into a permanent CSV pipeline: once VECTOR scans your network and ATLAS rolls out to the endpoints you manage, the inventory rebuilds itself going forward. From an ITSM tool, open tickets and recent changes are usually worth migrating; closed history is more useful as a flat archive than as live records, so most teams export it once and keep it as evidence rather than re-importing it.

Tell us. The product roadmap is shaped heavily by customer requests, particularly when several teams ask for the same thing or when the gap blocks a real workflow. We do not make commitments without knowing the work involved, but we are transparent about whether something is in flight, on the list, or not on the cards. The workflow engine, the public API, and webhooks also cover a lot of feature gaps for teams who want to extend the platform without waiting for native support.

It means your CMDB reflects the IT environment you actually run, not the one someone documented six months ago. New devices show up automatically. Records refresh as machines change. Things that disappear get flagged. The CMDB stays current without anyone chasing it, which is the part most CMDBs get wrong.

Three things feed it. VECTOR scans your network and brings back whatever is on it. ATLAS agents on Windows and Linux machines report what is on each one. Microsoft 365 sync pulls users, groups, roles, and managed devices from Entra ID and Intune. All three run on schedules you control, and all three populate the same CMDB rather than separate inventories you have to reconcile.

Only the things automation cannot see for itself: contracts, vendors, ownership, documentation, and the relationships you care about between assets. Hardware, software, network presence, and security posture refresh themselves on every check-in or scan. The hand-edits you do still make are tracked in version history.

Traditional CMDBs are populated by hand and decay the moment someone forgets to update them. Kovira inverts that: discovery and agents do the boring work, the CMDB is current by default, and the human effort goes into the things that actually need a human (relationships, ownership, documentation, decisions). The data does not need a quarterly cleanup project to stay trustworthy.

On the default schedule, changes land at the next scan or check-in. For teams that need updates the moment something happens, VECTOR LIVE and ATLAS LIVE add-ons push changes into the CMDB instantly. Either way, when an update lands it goes through deduplication so the same device does not show up multiple times.

It is not silently deleted. ATLAS-managed machines that stop checking in get flagged on the dashboard so you can see who has gone quiet. VECTOR-discovered devices that stop responding to scans are kept on the record with their last-seen timestamp. You decide whether to retire the record, keep it, or investigate.

Yes. Topology relationships discovered by VECTOR (how devices connect to each other) refresh on every scan, so the dependency map matches what is actually plugged in. Manual relationships you add (a service depending on a database, a contract covering a vendor) stay where you put them with full version history.

No. The CMDB is live by default: scheduled scans and agent check-ins keep it current without manual work. The LIVE add-ons exist for teams that need updates the moment something changes rather than at the next scheduled run, and they are optional on top of any paid plan.

VECTOR is Kovira's agentless network scanner. Point it at your network and it discovers what is connected, identifies what each device is, and maps how everything links together. Nothing is installed on the scanned hosts and the scan is read-only. Results land in your CMDB ready to use, with duplicates merged against any existing records. Run it on demand or on a schedule. Included in every plan, including the free tier.

Yes. On switches that speak LLDP, VECTOR captures neighbour observations per port so you can see which device is plugged into which switch port without crawling cabinets. MAC address tables are pulled per switch, and a host MAC index lets you ask the reverse question: given this device's MAC, where on the network has it been seen? Each device's CI surfaces every neighbour, every MAC entry, and every observation Kovira has collected.

Yes. Both VECTOR collectors and ATLAS endpoints can be paused, resumed, or scheduled for uninstall centrally from the workspace. The agent picks up the command on its next check-in, acts on it, and (for uninstall) confirms back to the platform when it has removed itself. You do not need RDP or SSH to take an agent out of service cleanly.

ATLAS is Kovira's endpoint agent for Windows and Linux. It keeps each machine's record in your CMDB current with what is actually on it: hardware, software, and security posture. Short heartbeats in between let you know what is online and how it is running, and the dashboard flags any agent that goes quiet. Included in every plan, including the free tier.

Yes. Kovira syncs users, security groups, directory roles, and managed devices from Microsoft Entra ID and Intune, and surfaces them as configuration items alongside everything else. Sync runs in the background and you can also kick it off on demand. Paid plans add monitored mailboxes for incident triage (one mailbox on Teams, three on Business, five on MSP).

Kovira recognises it as the same thing. A single laptop that shows up in a VECTOR scan, reports to ATLAS, and sits in your Microsoft 365 device list becomes one record in your CMDB instead of three you have to merge by hand. You can still see which source contributed which piece of information when you need to.

Yes. Every paid plan includes API access for reading and writing configuration items, incidents, changes, documents, and other records. API throughput limits scale with the plan. Webhooks can fire from inside the workflow builder, so you can push events to other systems whenever something changes. The free tier is read-only at the API.

No. VECTOR discovers and identifies devices without credentials. Supplying read-only credentials gets you richer detail on the devices that accept them, but it is optional: discovery and identification work either way.

Yes. You can run as many VECTOR collectors as you need in a single workspace, each scoped to its own subnets. Results from every collector flow back to the same CMDB and are deduplicated against existing records.

ATLAS runs as a background service. There is no UI on the endpoint and users do not see it in normal operation. Administrators see everything ATLAS reports back through the Kovira dashboard.

Yes. ATLAS reads posture for inventory and reporting; it does not replace your endpoint security tooling. It coexists with the antivirus and EDR products you already have deployed.

REST over HTTPS, JSON request and response bodies, with read and write access to configuration items, incidents, changes, documents, audit log, and the workflow run history. Authentication is via tenant-scoped API keys (rotatable per workspace), and rate limits scale with the plan: 60 calls per hour on the free tier (read-only), 100 on Teams, 1500 on Business and MSP. The API surface is documented in the platform; if you need a particular endpoint that does not exist yet, the workflow engine usually covers the gap until the native endpoint lands.

Yes, in two directions. Outbound: the workflow engine ships a webhook action so any workflow run can POST to an external endpoint with a templated payload, and the runtime stores the response on the run for inspection. Outbound webhooks go through an SSRF guard that blocks private and metadata-service IP ranges to prevent workflow authors accidentally probing internal infrastructure. Inbound: Kovira's mailbox-to-ticket pipeline subscribes to Microsoft Graph change notifications under the hood, and additional inbound webhook endpoints (for non-Microsoft mail providers and other event sources) are on the integration roadmap.

Generic webhooks are available today inside the workflow builder, so you can connect Kovira to any system with an HTTP endpoint. Named integrations on the post-launch roadmap include: Slack and Microsoft Teams notifications as native workflow actions, Jira and HaloPSA two-way bridges for teams running Kovira alongside an existing PSA, and Google Workspace as a directory sync option alongside Microsoft 365. Priority is driven by customer demand. If you need something specific, ask and we will tell you where it sits.

Kovira ships with 19 configuration item types, grouped across your infrastructure, your organisation, your governance stack, and day-to-day operations. Every type supports dependency mapping, version history, audit logging, and workflow triggers.

Yes. Kovira includes a visual workflow builder where you can create multi-step automations without writing code: approval chains, conditional branches, delayed actions, retries, webhooks, and email. Triggers cover CI changes, incident lifecycle events, SLA events (at risk, breached, paused, resumed), scheduled intervals, manual dispatch, and incoming email when a monitored mailbox is connected. Every run is recorded in an execution log with input, output, and error captured per step so you can audit exactly what happened.

Yes. The send-email action is built in, sending through a managed sender so you do not need to wire up your own SMTP credentials inside the workflow. Built-in system workflows already cover the common notifications (ticket created, ticket assigned, SLA at risk, SLA breach) so you do not have to build them from scratch, and you can add your own on top for anything specific to your team.

Yes, when you have connected a monitored Microsoft 365 mailbox. The incoming-mail trigger fires on new messages so you can route by sender domain, set priority by subject pattern, send an acknowledgement, populate fields from the email body, or chain into your existing approval flow. Replies are threaded back onto the original incident as comments, and the trigger filters let you scope to a specific mailbox or subject pattern.

Workflows include data actions for shaping values mid-run: regex extract for pulling structured data out of an email body or webhook payload, string operations (case, trim, replace, slice), and JSON shape for plucking and renaming keys. Transformed values land back in the run scope so later steps act on cleaned-up data rather than the raw payload.

Yes. Connect a Microsoft 365 user or shared mailbox and every new message raises an incident in Kovira. Replies from the requester or technicians thread back onto the original incident as comments, with attachments and inline images preserved. Threading uses the Microsoft conversation identifier, RFC 5322 References and In-Reply-To headers, and a normalised subject fallback. Bounces, autoresponders, and Kovira's own outbound mail are detected and skipped to avoid feedback loops. Mailbox count by plan: 1 on Teams, 3 on Business, 5 on MSP.

Incidents carry the fields ITIL practices actually call for: priority matrix, response and resolution SLA timers (driven by per-customer policies and coverage windows), resolution category, closure code, who resolved it, watchers who get notified on updates, parent and child links for major events that group dozens of related tickets, and a postmortem document reference for major incidents. Reopens are tracked with a counter so you can spot recurring patterns.

Every edit to a configuration item creates a new version, capturing who made the change, when, and what changed. You can see the full history on any record and roll back to a previous version if a change needs to be undone. Restoring a previous version is non-destructive: it creates a fresh version on top, so you never lose the audit trail.

Yes. Kovira's incident and change management is ITILv4-aligned, with priority matrix, SLA tracking, and ownership assignment. Every incident links back to the configuration items it affects, and every proposed change can run an upstream and downstream impact analysis before approval. Change approvals require an independent reviewer: the person who created the change cannot approve their own work.

Yes. Custom CI types are supported alongside the 19 built-ins, so you can model anything specific to your environment that the standard set does not cover.

Yes. Any pair of configuration items can be connected through typed relationships (runs on, depends on, owned by, located at, and so on). The relationships surface as a dependency map so you can see upstream and downstream impact at a glance.

Yes. Deleted configuration items move into a recycle bin instead of being removed outright. From there you can restore a record back to its prior state or purge it permanently when you are sure.

Yes. Documents in Kovira are structured around content cards (headings, text, checklists, images, tables, code, callouts, and links) and can be linked back to any configuration item. Your runbooks, procedures, and reference material live next to the systems they describe.

Yes. Kovira detects concurrent edits and auto-merges non-conflicting field changes. If two people edit the same field at the same time, you get a clear conflict prompt with both versions side by side instead of one quietly overwriting the other.

Multi-factor authentication is mandatory on every account, on every plan. SAML 2.0 single sign-on is available from the Teams plan and up. Role-based access control with per-member overrides is included on every plan, and every action is recorded in a tamper-proof audit trail that cannot be disabled. Tenant data isolation is enforced at the database layer.

Data is encrypted in transit (TLS) and at rest. Sensitive fields like passwords and API keys are stored in a dedicated vault and never appear in plaintext, in API responses, in logs, or in audit records. Tenant isolation is enforced at the database layer, so one workspace can never read another workspace's records.

Every action in Kovira is recorded in a tamper-proof audit trail: configuration item changes, status transitions, logins, permission checks, workflow executions, and access to sensitive records. The log captures who did it, what they did, when, and from where. It is always on and cannot be disabled. For teams working towards ISO 27001, SOC 2, or internal governance requirements, the audit trail is designed to provide the evidence auditors ask for without a separate reporting system.

Kovira is hosted in Australia by default, on infrastructure that meets enterprise compliance baselines. All customer data, including audit logs and document storage, stays in region. Data residency for other regions is on the roadmap.

Yes. Your data is yours. You can export configuration items, incidents, changes, documents, and audit history at any time via the public API or via in-app export, in standard formats. After cancellation your data remains available for export through the end of the billing period before the workspace is closed.

Yes. Multi-factor authentication is mandatory on every account, on every plan, including the free tier. There is no way to disable it.

SAML 2.0, available from the Teams plan and up. That covers the major identity providers used by IT teams (Entra ID, Okta, Google Workspace, and others that speak SAML).

Retention varies by plan. Logs are not purged automatically, and you can export the full audit history at any time through the API or in-app export.

Yes. Kovira has four roles (Owner, Admin, Editor, Viewer) plus per-member permission overrides for cases that do not fit cleanly into a role. Some actions are Owner-only by design: billing changes and tenant deletion cannot be delegated.

Yes. We publish a responsible disclosure address and operate under a standard 90-day window. If you believe you have found a security issue, get in touch and we will work with you to resolve it.

Kovira is built around the principles GDPR codifies: data minimisation, purpose limitation, the right to access and erasure, audit logging, encryption, and tenant-level isolation. Data residency is in Australia at launch, with European residency on the roadmap as customer demand grows. For customers operating under GDPR, we treat the platform's audit trail and per-tenant data isolation as the foundation of compliance evidence, and we will sign a data processing agreement on request. If your legal team needs specific clauses or commitments to evaluate Kovira for GDPR-regulated data, get in touch and we will work it out.

Yes. Workspace owners can delete a tenant from inside the platform. Deletion is soft for a short retention window (so an accidental click is recoverable by support), then hard-deletes after the window expires. Configuration items, incidents, changes, documents, audit logs, document storage, and workflow history all flow through that deletion. For customers operating under GDPR, SOC 2, or similar frameworks where verifiable deletion is a requirement, we will provide written confirmation that the hard-delete has completed.

An honest answer: the platform is run as a sustainable business and we are planning to be around. The contingency, in case it ever became relevant, is that customers are given advance notice (longer than the standard cancellation window) to export their data via the API, in-app export, or CSV download, and we coordinate the wind-down. Data is yours, and the export tooling is built into the platform from launch rather than added as a parting gift.

Uptime targets and platform SLAs are documented per plan. The free tier is best-effort. Paid plans include a target uptime commitment with credits for breaches, and the MSP plan adds priority response on platform incidents. If you have specific availability or response-time requirements that need negotiation, contact us before signing on so we can structure something appropriate to the workload.