Formerly Shadow AI Guard.Enterprise Coming soonYour estate.
Your infrastructure.
Build a home for your AI visibility. Start with your estate, choose where it runs, then take the plan with you.
Measured to ~19,000 devices on one node.
Synthetic estate · 16 September 2026.
Adds 2 pods to your cluster: 1 GiB memory, ~1.2 vCPU while ingesting, plus a 1 GB receiver database volume.
If you already run a cluster with spare capacity and Loki, these two application pods and the receiver volume are what you add. There is no separate control plane to pay for. Optional CronJobs need their own allowance.
Memory is the sum of the portal and receiver limits. CPU: ~1 core receiver + 0.2 core portal planning allowance; portal CPU is not measured. External Loki is separate.Two pods. Your Loki.
22,400 findings in 7 days. The portal memory budget is 512Mi, rounded up with headroom.
Application footprint
Portal + receiver memory limits, rounded up with system allowance. Loki is external. Optional jobs are not included in this memory floor.
CPU planning allowance: ~1 core for the receiver + 0.2 core for the portal. Only the receiver (~0.9 core while ingesting) was measured; validate portal and optional job CPU.
The log store dominates disk.
At 3,200 findings per day, these are alternative retention horizons. Your selected retention is 30 days; its provisioned log budget is 20 GB.
150 bytes per finding for planning, above ~40 bytes measured on repetitive synthetic data. Budgets round up to 10 GB, minimum 20 GB. This is stored data; bandwidth and bytes on the wire were not measured.
Cost this yourself Your rates. Your existing capacity. ＋
The shape to price
For a dedicated node, start with 2 vCPU, 2 GiB RAM (application limits + 25%), and a 1 GB receiver volume. Node count: 1. Node OS disk, external Loki and optional jobs are additional; CPU is a planning allowance to validate.
With spare cluster capacity, use the pod footprint above instead of pricing a new node. No separate control plane is needed for an existing cluster.
| Cloud | 2 vCPU / 8 GiB | 4 vCPU / 16 GiB | Kubernetes |
|---|---|---|---|
| AWS | m7i.large | m7i.xlarge | EKS |
| Azure | D2as_v5 | D4as_v5 | AKS |
Google’s calculator is linked for your own estimates; no Google instance mappings or prices are supplied here.
Excludes your negotiated rates, egress, support plans, backups, tax, snapshots and the Nyxus subscription; also the external log store if you do not already run one. No bandwidth or network-cost estimate is provided.
Stress-test a busy morning Explore ingestion bursts ＋
What if the fleet wakes together?
Assume a full day’s findings arrive within a short burst.
This burst is below the approximate ingest ceiling. It is not a latency guarantee. Adding CPU does not remove the receiver’s single-worker limit.
Your configuration notes
Nyxus 0.1.0 · planning estimate 2,000 devices · typical activity (1.6/device/day) 7-day reporting window · 30-day log retention 22,400 findings in window Kubernetes: 2 pods; 2 optional CronJobs. External Loki required. Pod footprint: 1 GiB, ~1.2 vCPU while ingesting (1 receiver + 0.2 portal planning allowance, not measured). Portal memory limit: 512Mi; receiver: 512Mi, exactly 1 replica. Application memory plus 25% system allowance: 2 GiB (rounded up). CPU is a planning allowance: portal and CronJob CPU not measured. Validate under your workload. Receiver storage: 1 GB. External Loki budget: 512Mi, 20 GB. Concurrent portal sessions: 2 Prices and Nyxus subscription excluded.
What these numbers mean Measurements, assumptions & limits ＋
Measured in 0.1.0
One company, synthetic estate, single-node k3s. Container cgroup peaks: portal 47Mi idle, 434Mi at 100,000 findings; receiver 252Mi peak; Loki 88–196Mi. Receiver database ~26Mi at 19,428 devices.
Cold first-page measurements: 9.9s at 43,685 findings, 22.8s at 99,013, 26.2s at 100,000. Repeat loads were under 1s in this test. Five concurrent sessions: median 3.1s per load.
Planning assumptions
Portal = 47Mi + 4.5Mi per 1,000 findings, rounded up to 512Mi / 1Gi / 2Gi. Receiver = 512Mi to 20,000 devices. No session multiplier. Light and heavy activity are estimates.
Loki disk = daily findings × 150 bytes × retention, rounded to 10GB, minimum 20GB. Receiver disk = 1.4KB × enrolled devices, minimum 1GB; reporting count is used as the enrolment proxy here.
Compose tiers use the supplied host budgets. The 25% Kubernetes allowance covers system overhead only. The additional 0.2 core portal CPU allowance is an unmeasured assumption. Bytes on the wire were not measured; no bandwidth or network-cost calculation is made. Above 6,000 devices uses the largest tier, but beyond the measured estate needs validation even when a shorter window fits.
Formerly Shadow AI Guard.Enterprise Coming soonYour estate.
Your infrastructure.
Build a home for your AI visibility. Start with your estate, choose where it runs, then take the plan with you.
Measured to ~19,000 devices on one node.
Synthetic estate · 16 September 2026.
Adds 2 pods to your cluster: 1 GiB memory, ~1.2 vCPU while ingesting, plus a 1 GB receiver database volume.
If you already run a cluster with spare capacity and Loki, these two application pods and the receiver volume are what you add. There is no separate control plane to pay for. Optional CronJobs need their own allowance.
Memory is the sum of the portal and receiver limits. CPU: ~1 core receiver + 0.2 core portal planning allowance; portal CPU is not measured. External Loki is separate.Two pods. Your Loki.
22,400 findings in 7 days. The portal memory budget is 512Mi, rounded up with headroom.
Application footprint
Portal + receiver memory limits, rounded up with system allowance. Loki is external. Optional jobs are not included in this memory floor.
CPU planning allowance: ~1 core for the receiver + 0.2 core for the portal. Only the receiver (~0.9 core while ingesting) was measured; validate portal and optional job CPU.
The log store dominates disk.
At 3,200 findings per day, these are alternative retention horizons. Your selected retention is 30 days; its provisioned log budget is 20 GB.
150 bytes per finding for planning, above ~40 bytes measured on repetitive synthetic data. Budgets round up to 10 GB, minimum 20 GB. This is stored data; bandwidth and bytes on the wire were not measured.
Cost this yourself Your rates. Your existing capacity. ＋
The shape to price
For a dedicated node, start with 2 vCPU, 2 GiB RAM (application limits + 25%), and a 1 GB receiver volume. Node count: 1. Node OS disk, external Loki and optional jobs are additional; CPU is a planning allowance to validate.
With spare cluster capacity, use the pod footprint above instead of pricing a new node. No separate control plane is needed for an existing cluster.
| Cloud | 2 vCPU / 8 GiB | 4 vCPU / 16 GiB | Kubernetes |
|---|---|---|---|
| AWS | m7i.large | m7i.xlarge | EKS |
| Azure | D2as_v5 | D4as_v5 | AKS |
Google’s calculator is linked for your own estimates; no Google instance mappings or prices are supplied here.
Excludes your negotiated rates, egress, support plans, backups, tax, snapshots and the Nyxus subscription; also the external log store if you do not already run one. No bandwidth or network-cost estimate is provided.
Stress-test a busy morning Explore ingestion bursts ＋
What if the fleet wakes together?
Assume a full day’s findings arrive within a short burst.
This burst is below the approximate ingest ceiling. It is not a latency guarantee. Adding CPU does not remove the receiver’s single-worker limit.
Your configuration notes
Nyxus 0.1.0 · planning estimate 2,000 devices · typical activity (1.6/device/day) 7-day reporting window · 30-day log retention 22,400 findings in window Kubernetes: 2 pods; 2 optional CronJobs. External Loki required. Pod footprint: 1 GiB, ~1.2 vCPU while ingesting (1 receiver + 0.2 portal planning allowance, not measured). Portal memory limit: 512Mi; receiver: 512Mi, exactly 1 replica. Application memory plus 25% system allowance: 2 GiB (rounded up). CPU is a planning allowance: portal and CronJob CPU not measured. Validate under your workload. Receiver storage: 1 GB. External Loki budget: 512Mi, 20 GB. Concurrent portal sessions: 2 Prices and Nyxus subscription excluded.
What these numbers mean Measurements, assumptions & limits ＋
Measured in 0.1.0
One company, synthetic estate, single-node k3s. Container cgroup peaks: portal 47Mi idle, 434Mi at 100,000 findings; receiver 252Mi peak; Loki 88–196Mi. Receiver database ~26Mi at 19,428 devices.
Cold first-page measurements: 9.9s at 43,685 findings, 22.8s at 99,013, 26.2s at 100,000. Repeat loads were under 1s in this test. Five concurrent sessions: median 3.1s per load.
Planning assumptions
Portal = 47Mi + 4.5Mi per 1,000 findings, rounded up to 512Mi / 1Gi / 2Gi. Receiver = 512Mi to 20,000 devices. No session multiplier. Light and heavy activity are estimates.
Loki disk = daily findings × 150 bytes × retention, rounded to 10GB, minimum 20GB. Receiver disk = 1.4KB × enrolled devices, minimum 1GB; reporting count is used as the enrolment proxy here.
Compose tiers use the supplied host budgets. The 25% Kubernetes allowance covers system overhead only. The additional 0.2 core portal CPU allowance is an unmeasured assumption. Bytes on the wire were not measured; no bandwidth or network-cost calculation is made. Above 6,000 devices uses the largest tier, but beyond the measured estate needs validation even when a shorter window fits.
Formerly Shadow AI Guard.Enterprise Coming soonYour estate.
Your infrastructure.
Build a home for your AI visibility. Start with your estate, choose where it runs, then take the plan with you.
Measured to ~19,000 devices on one node.
Synthetic estate · 16 September 2026.
Adds 2 pods to your cluster: 1 GiB memory, ~1.2 vCPU while ingesting, plus a 1 GB receiver database volume.
If you already run a cluster with spare capacity and Loki, these two application pods and the receiver volume are what you add. There is no separate control plane to pay for. Optional CronJobs need their own allowance.
Memory is the sum of the portal and receiver limits. CPU: ~1 core receiver + 0.2 core portal planning allowance; portal CPU is not measured. External Loki is separate.Two pods. Your Loki.
22,400 findings in 7 days. The portal memory budget is 512Mi, rounded up with headroom.
Application footprint
Portal + receiver memory limits, rounded up with system allowance. Loki is external. Optional jobs are not included in this memory floor.
CPU planning allowance: ~1 core for the receiver + 0.2 core for the portal. Only the receiver (~0.9 core while ingesting) was measured; validate portal and optional job CPU.
The log store dominates disk.
At 3,200 findings per day, these are alternative retention horizons. Your selected retention is 30 days; its provisioned log budget is 20 GB.
150 bytes per finding for planning, above ~40 bytes measured on repetitive synthetic data. Budgets round up to 10 GB, minimum 20 GB. This is stored data; bandwidth and bytes on the wire were not measured.
Cost this yourself Your rates. Your existing capacity. ＋
The shape to price
For a dedicated node, start with 2 vCPU, 2 GiB RAM (application limits + 25%), and a 1 GB receiver volume. Node count: 1. Node OS disk, external Loki and optional jobs are additional; CPU is a planning allowance to validate.
With spare cluster capacity, use the pod footprint above instead of pricing a new node. No separate control plane is needed for an existing cluster.
| Cloud | 2 vCPU / 8 GiB | 4 vCPU / 16 GiB | Kubernetes |
|---|---|---|---|
| AWS | m7i.large | m7i.xlarge | EKS |
| Azure | D2as_v5 | D4as_v5 | AKS |
Google’s calculator is linked for your own estimates; no Google instance mappings or prices are supplied here.
Excludes your negotiated rates, egress, support plans, backups, tax, snapshots and the Nyxus subscription; also the external log store if you do not already run one. No bandwidth or network-cost estimate is provided.
Stress-test a busy morning Explore ingestion bursts ＋
What if the fleet wakes together?
Assume a full day’s findings arrive within a short burst.
This burst is below the approximate ingest ceiling. It is not a latency guarantee. Adding CPU does not remove the receiver’s single-worker limit.
Your configuration notes
Nyxus 0.1.0 · planning estimate 2,000 devices · typical activity (1.6/device/day) 7-day reporting window · 30-day log retention 22,400 findings in window Kubernetes: 2 pods; 2 optional CronJobs. External Loki required. Pod footprint: 1 GiB, ~1.2 vCPU while ingesting (1 receiver + 0.2 portal planning allowance, not measured). Portal memory limit: 512Mi; receiver: 512Mi, exactly 1 replica. Application memory plus 25% system allowance: 2 GiB (rounded up). CPU is a planning allowance: portal and CronJob CPU not measured. Validate under your workload. Receiver storage: 1 GB. External Loki budget: 512Mi, 20 GB. Concurrent portal sessions: 2 Prices and Nyxus subscription excluded.
What these numbers mean Measurements, assumptions & limits ＋
Measured in 0.1.0
One company, synthetic estate, single-node k3s. Container cgroup peaks: portal 47Mi idle, 434Mi at 100,000 findings; receiver 252Mi peak; Loki 88–196Mi. Receiver database ~26Mi at 19,428 devices.
Cold first-page measurements: 9.9s at 43,685 findings, 22.8s at 99,013, 26.2s at 100,000. Repeat loads were under 1s in this test. Five concurrent sessions: median 3.1s per load.
Planning assumptions
Portal = 47Mi + 4.5Mi per 1,000 findings, rounded up to 512Mi / 1Gi / 2Gi. Receiver = 512Mi to 20,000 devices. No session multiplier. Light and heavy activity are estimates.
Loki disk = daily findings × 150 bytes × retention, rounded to 10GB, minimum 20GB. Receiver disk = 1.4KB × enrolled devices, minimum 1GB; reporting count is used as the enrolment proxy here.
Compose tiers use the supplied host budgets. The 25% Kubernetes allowance covers system overhead only. The additional 0.2 core portal CPU allowance is an unmeasured assumption. Bytes on the wire were not measured; no bandwidth or network-cost calculation is made. Above 6,000 devices uses the largest tier, but beyond the measured estate needs validation even when a shorter window fits.