Deployment

VirtualMetric DataStream Directors support flexible deployment options to match your infrastructure requirements and operational preferences. Whether you're running on physical hardware, virtual machines, or containerized environments, Directors can be deployed to optimize performance while maintaining data sovereignty.

For Director concepts, capabilities, and installation types, see Directors - Overview.

Options

As Physical Server

Deploy Directors directly on dedicated physical hardware for maximum performance and complete infrastructure control. This option provides maximum performance and resource allocation with complete control over hardware specifications. Without virtualization overhead, physical deployments are ideal for high-throughput environments.

Considerations

Physical server deployments involve higher infrastructure costs and maintenance overhead. They offer limited flexibility for resource scaling and require longer deployment and provisioning times.

As Virtual Machine

Deploy Directors on virtual machines across various hypervisors and cloud platforms for balanced performance and flexibility. Virtual machine deployments offer flexible resource allocation and scaling with cost-effective resource utilization. They simplify backup and disaster recovery procedures and are platform agnostic, supporting VMware, Hyper-V, KVM, AWS, Azure, and GCP.

Considerations

Virtual machine deployments introduce slight performance overhead from virtualization and create dependency on hypervisor platform stability.

Recommended VM Specifications:

Workload Size	CPU Cores	Memory	Storage	Notes
Small	2-4 cores	8GB RAM	50GB	Development/testing, < 10K EPS
Medium	4-8 cores	16GB RAM	100GB	Standard production, 10K-50K EPS
Large	8+ cores	32GB RAM	200GB+	High-volume production, > 50K EPS

Disclaimer

Actual requirements may vary depending on the workload.

As Container

Deploy Directors in containerized environments for modern infrastructure management and orchestration capabilities.

Docker deployments run as single-host containers with simplified dependency management. They offer easy scaling and updates, making them ideal for development and small production environments.

Kubernetes deployments provide multi-node orchestration with automatic scaling, built-in service discovery and load balancing. They support rolling updates with zero downtime and deliver enterprise-grade high availability and resilience.

Containerized deployments provide consistent deployment across environments with rapid scaling and resource optimization. They include integrated monitoring and logging capabilities and support DevOps-friendly CI/CD integration.

Platform-Specific Considerations

On Linux

Linux deployments offer performance advantages: network-based collectors (syslog, TCP, SNMP) operate more efficiently with lower resource overhead for network processing. Linux provides superior performance for high-volume data ingestion and native support for Unix/Linux system integration.

Agent Connectivity:

• Windows Agent: Full support for Windows systems via VirtualMetric Agent with optional pre-processing
• Linux Agentless: Complete support via SSH-based connections
• Windows Agentless: Full support via WinRM protocols

note

Microsoft has announced plans to deprecate WinRM in future Windows releases. VirtualMetric continues to support WinRM-based agentless monitoring. Consider using VirtualMetric Agent for long-term Windows endpoint monitoring strategies.

Recommended For:

• High-volume network data collection environments
• Mixed Windows/Linux infrastructure monitoring
• Cost-sensitive deployments requiring maximum efficiency

On Windows

Agentless Connectivity:

• Windows Agentless: Full support via WinRM protocols
• Linux Agentless: Complete support via SSH connections
• Universal Agent: Support for both Windows and Linux systems with optional pre-processing

note

Microsoft has announced plans to deprecate WinRM in future Windows releases. VirtualMetric continues to support WinRM-based agentless monitoring. Consider using VirtualMetric Agent for long-term Windows endpoint monitoring strategies.

Windows deployments provide native Windows service integration with Active Directory authentication support. They offer PowerShell-based management capabilities and seamless Windows ecosystem integration.

Recommended For:

• Windows-centric environments
• Organizations requiring agentless Windows monitoring
• Environments with existing Windows management infrastructure

Installation Process

Standalone Director Installation

info

Directors are always created as standalone instances. To create a clustered deployment for high availability, first create Directors using this wizard, then group them using the Clusters tab. See Clusters for configuration details.

Navigate to Home > Fleet Management > Directors and click Create new director to begin the 6-step setup wizard.

Step 1: Director Setup

Director Name:

Enter a unique identifier for the Director (3-64 characters). This name is used for identification across the platform.

Mode Selection:

Select the management approach using radio tiles:

• Managed - VirtualMetric manages Director infrastructure with automated updates, proactive monitoring, and reduced operational overhead
• Self-managed - User controls Director deployment with manual updates, custom security configurations, and full infrastructure control
• Orchestrated - For auto-scaling cloud environments where instances are automatically managed, scaled, and replaced by the platform
• Serverless - Runs on demand as a container without dedicated infrastructure, scaling automatically with load

For what each mode means operationally, see Platform Management Options. The mode cannot be changed after creation for Serverless Directors, and no other Director can be converted to serverless mode.

Self-managed Directors

A self-managed Director is indicated under the Mode column as Self-managed, with a warning icon when configuration has changed. Hovering over the icon displays a tooltip reading "Director configuration changed after last update. Please deploy the current configuration."

The actions menu contains a Download config option that downloads the vmetric.vmf file. Place this file under the <vm_root>\Director\config directory. Self-managed Directors skip access verification — monitor errors through the CLI or the files under <vm_root>\Director\storage\logs.

Container Type:

Selecting the Serverless mode reveals an additional required selection. It does not appear for the other three modes, and a container type cannot be submitted with them:

• Docker - Lightweight containerized deployment. Runs anywhere Docker is available, ideal for single-host or self-managed setups
• Kubernetes - Orchestrated container deployment. Scales across clusters with self-healing and rolling updates
• Azure Container Instances - Serverless containers on Azure. Fast startup with no cluster to manage, suited for bursty or short-lived workloads
• Azure Container Apps - Managed container platform on Azure. Built-in autoscaling and microservice support with managed identity integration

The container type determines the form of the deployment manifest generated in the Install and Connect Director step, and it cannot be changed afterwards.

Step 2: Access Management

Configure optional access controls for the Director.

Access Tokens:

• Enable Access Tokens - Toggle to require token authentication
• Token Name - Identifier for the token
• Token Value - Auto-generated when token is created (use copy button to copy)
• Expiration - Token validity period (default: 3 months):
  • 1 month
  • 3 months
  • 1 year
  • Unlimited

Access Restriction:

Restrict which IP addresses can connect to the Director:

• Enable Access Restriction - Toggle to enable IP filtering
• Restriction Type:
  • Single Block - Single IP address
  • Range - IP address range (start-end)
  • CIDR - CIDR notation (e.g., 10.0.0.0/8)
• Sources - List of allowed IP addresses/ranges

Step 3: TLS Configuration

Select how TLS is managed for agent-to-director communication using radio tiles:

• Auto-generated - The Director manages its own certificate authority (CA) and certificates
• Custom certificate - The Director uses your certificate and private key, for organizations with an existing PKI
• TLS offloading - TLS termination is handled by your load balancer

Each mode exposes its own fields, along with the agent communication port and, where applicable, the discovery endpoint used for agent enrollment. For the full field reference, the mode-to-proxy_tls mapping, and the certificate resolution order, see Transport Layer Security.

Serverless Directors are subject to stricter port rules, because these values are written into the deployment manifest as the container's exposed ports:

Rule	Applies to
The agent communication port is mandatory and must be in the range 1-65535	All container types
The discovery port is mandatory, and must differ from the agent communication port, when discovery is enabled	All container types
Ports 80 and 443 are rejected	Azure Container Apps only — the platform reserves them for its own ingress

The Director is created when this step is submitted, so a port that violates these rules is reported here rather than at deployment time.

Step 4: Install and Connect Director

Installation Scripts:

• PowerShell Script - For Windows deployments
• Bash Script - For Linux/macOS deployments
• Copy Button - One-click copy to clipboard
• API Key - Auto-generated secure authentication key included in scripts

Run the provided script with administrative privileges on the target system. The installation downloads and configures the Director service with automatic service registration and startup configuration.

Serverless Deployment Manifest:

Serverless Directors do not use an installation script. This step instead presents a complete deployment manifest for the container type selected in Director Setup, and the PowerShell/Bash selector is not shown — the manifest is the same regardless of the platform you apply it from:

Container Type	Manifest	Applied with
Docker	A Compose service definition	docker compose up
Kubernetes	A vmetric namespace, a Secret, a Deployment, and a LoadBalancer Service	kubectl apply
Azure Container Instances	An Azure Resource Manager template for a container group, with a public IP and DNS label	Azure CLI or portal deployment
Azure Container Apps	An Azure Resource Manager template for a container app with external ingress and HTTP-based autoscaling	Azure CLI or portal deployment

The manifest carries the API key as the VMETRIC_CONFIG_HASH environment variable, supplied through the platform's own secret mechanism rather than as plain text. The container name is derived from the Director name, reduced to lowercase letters, digits and hyphens and truncated to 32 characters so that it is valid on every supported platform.

warning

Reinstalling a Director issues a new API key and a new manifest. The previously issued manifest stops authenticating, so redeploy from the new one rather than reusing the old copy.

Connection Verification:

After running the installation script, verify Director connectivity:

• Connecting - Director attempting initial connection
• Success - Director successfully connected to platform
• Failed - Connection attempt unsuccessful

Real-time connection status updates with visual indicators for each state.

If the Director is not yet connected, click Connect later to proceed without connection verification and return later to verify the connection.

Step 5: Update Management

Configure the Director's update policy. By default the organization-level update settings apply; enable the Custom update policy toggle to override them for this Director. See Updates for the policy options.

Step 6: Review and Complete Setup

A read-only summary of the values entered in the preceding steps. Click Complete setup to finalize the Director and navigate to its detail view.

Navigation

The wizard displays a 6-step progress indicator (Director Setup > Access Management > TLS Configuration > Install and Connect Director > Update Management > Review and Complete Setup). Click completed steps to navigate back. Invalid steps are marked with an error indicator.

Navigation Buttons:

• Cancel - Exit wizard (first step)
• Next Step - Advance to next step with validation
• Create director - Submit Director configuration and proceed to connection (from the Access Management step; shown as Update director when returning to that step after creation)
• Connect later - Skip connection verification (Install and Connect Director step)
• Back - Return to the previous step
• Complete setup - Finalize Director creation (final step)

Network Requirements

Critical: Pre-Installation Network Access

Before running installation commands, ensure the target system has outbound HTTPS access to dl.vget.me. The installation scripts are served from this URL and will fail silently or with connection errors if blocked by firewall rules.

Outbound Connectivity:

• Port 443 (HTTPS) to dl.vget.me for installation script and binary downloads
• Port 443 (HTTPS) for DataStream cloud platform communication
• DNS resolution for dl.vget.me and api-service.*.cloud.virtualmetric.com domains

Serverless Directors

Serverless Directors do not download an installation script, so dl.vget.me access is not required for them. The container platform pulls the Director image from Docker Hub instead, and that registry must be reachable from wherever the manifest is deployed. Platform communication over port 443 applies as it does to every other mode.

warning

TLS certificate validation requires accurate system time. Ensure NTP is configured and the system clock is synchronized before installation.

Installation Script Delivery

The installation commands use dl.vget.me as the script delivery endpoint. This URL serves platform-appropriate installation scripts based on the requesting client:

Client	Script Served	Command Example
PowerShell	install.ps1	$h="<apiKey>"; iwr dl.vget.me | iex
curl/wget	install.sh	curl -sL dl.vget.me | h="<apiKey>" bash
Browser	Redirects to virtualmetric.com	N/A

The scripts automatically:

1. Detect the operating system (Windows, Linux, macOS, FreeBSD, etc.)
2. Detect the CPU architecture (amd64, arm64)
3. Download the appropriate Agent binary from dl.vget.me/agent/{os}/{arch}
4. Configure the Agent with the provided API key
5. Install and start the service

Supported Platforms:

Operating System	Architectures
Windows	amd64, arm64
Linux	amd64, arm64, 386, ppc64, ppc64le
macOS (Darwin)	amd64, arm64
FreeBSD	amd64, arm64
Other Unix	amd64, arm64

Customizable Download URL

For environments where dl.vget.me is not accessible, the download URL can be configured via the VITE_INSTALLATION_DOWNLOAD_URL environment variable in self-hosted deployments.

Inbound Connectivity:

• Configure based on data source requirements
• Ports as defined in device configurations

Firewall Configuration

Outbound Rules (Required):

• Allow HTTPS (443) to dl.vget.me (installation scripts and binaries)
• Allow HTTPS/WebSocket Secure (443) to api-service.eu-west.cloud.virtualmetric.com (platform communication - Europe)
• Allow HTTPS/WebSocket Secure (443) to api-service.aus-east.cloud.virtualmetric.com (platform communication - Australia)
• Allow HTTPS/WebSocket Secure (443) to api-service.us-east.cloud.virtualmetric.com (platform communication - US)
• Allow DNS queries for name resolution
• Allow NTP for time synchronization

Firewall Rule Order

If your firewall processes rules in order, ensure the dl.vget.me rule is evaluated before any blanket deny rules. Installation will fail if the target system cannot reach this endpoint.

Inbound Rules (As Needed):

• Open ports for configured data collection protocols
• Allow management access (SSH for Linux, RDP for Windows)
• Configure source restrictions based on security policies

Security and Performance

Security Considerations

Deploy Directors in appropriate network segments and implement network access controls and monitoring. Use dedicated service accounts with minimal privileges and enable logging and audit trails for security monitoring. Implement encryption for data at rest and in transit, and maintain regular security updates and patch management.

Performance Optimization

Monitor CPU and memory utilization patterns and allocate sufficient disk space for logging and buffering. Configure appropriate network interface capacity and plan for peak load scenarios and growth.

For data processing efficiency, optimize YAML pipeline configurations for performance and implement efficient parsing and transformation rules. Use appropriate batch sizes for different data sources and monitor processing latency and throughput metrics. Consider Agent pre-processing for high-volume deployments to distribute processing load.

High Availability Planning

Maintain regular configuration backups and version control. Document recovery procedures and test them regularly. Implement monitoring and alerting for service health and plan for disaster recovery scenarios.

For redundancy, group Directors into clusters for automatic failover and load balancing. See Clusters for configuration details and quorum requirements. Consider geographic distribution for disaster recovery and plan for seamless failover procedures.

Advanced Deployment Scenarios

Multi-Site Deployments

For organizations with multiple locations or data centers, deploy Directors at each site for local data processing. Implement centralized configuration management and coordinate routing and aggregation strategies. Plan for inter-site connectivity and failover.

Compliance and Regulatory Requirements

For regulated industries requiring specific compliance, implement appropriate data retention and disposal policies. Configure audit logging and compliance reporting, ensure data sovereignty and jurisdictional requirements are met, and plan for regulatory audit and inspection procedures.

Scalability Planning

As your environment grows, monitor resource utilization and performance trends. Plan for vertical scaling (more resources per Director) or horizontal scaling (clustering multiple Directors). Implement capacity planning and forecasting procedures to determine when to transition from standalone to clustered deployments.