Hosting Service Description (Infrastructure)
Service Level: L3 — Full-Managed Cloud Service
This Service Description defines the Full-Managed Hosting & Infrastructure package, enabling clients to host physical hardware test rigs (Assemblies) directly inside Vector's secure datacenter.
L3 extends L2
This document covers the additional Hosting services only. The full capabilities of the WebService (Platform) L2 are a prerequisite and are included in every L3 engagement. Refer to the WebService Service Description for the platform-level terms, SLAs, and support scope.
Pilot Phase — No Binding SLA
This service is currently in Pilot Phase (Closed Beta). No legally binding availability levels are guaranteed during this period. Vector makes all commercially reasonable efforts to meet the target values stated below.
1. Subject and Scope
1.1 Scope of Agreement
In addition to the WebService (Platform) capabilities, the contractor offers turn-key physical hosting of development Workspaces and Assemblies. This represents the Full-Managed (Hosting) deployment tier (L3).
1.2 Service Boundary
The contractor takes full responsibility for provisioning, operating, and maintaining the physical hardware environment.
- Contractor Responsibility: Datacenter facilities, racks, network switches, Execution Environments (NUCs), remote power relay cards, and Hardware Automation Interfaces (HAI).
- Client Responsibility: Proprietary target hardware (e.g., ECUs, customized wiring harnesses, target debugger units) provided for installation inside the datacenter.
1.3 Usage Rights and Physical Restrictions
- Authorized Personnel Only: Physical access to racks and systems is restricted to certified datacenter staff.
- Client Access: Client engineers access their hosted hardware exclusively via secure web interfaces, remote terminals, or API channels. Direct physical client access is not permitted unless specifically agreed upon for audit purposes.
- Internal Use Only / Reselling Prohibition / Geographic Restrictions: As defined in the WebService Service Description §1.3.
2. Definitions
| Term | Definition |
|---|---|
| Workspace Slot | A standardized rack unit (1 U / 1 HE) designated to house client assemblies. Used as the base unit for Assembly sizing and pricing. |
| Execution Environment (EE) | A fully managed compute environment for flashing, debugging, and automation tasks. By default, EEs are operated on Proxmox VE-managed physical hosts and can run Windows Server 2025 or Linux workloads. |
| Physical Assembly | The client's actual electronic test setup, comprising ECUs, power units, cabling, and communication interfaces. |
All further terms (Application Service, vHaaS Agent, HAI, Assembly Profile, Request Profile, Workspace) are defined in the WebService Service Description §2.
3. Scope of Hosting Services
3.1 Datacenter & Rack Operations
The infrastructure is operated within professional, enterprise-grade carrier hotels in Stuttgart, Germany.
- Environmental Controls: Redundant climate control, dust filtration, and uninterrupted power supply (UPS).
- Physical Security: Multiple physical perimeters, strict badge access controls, and continuous video monitoring.
- Network Isolation: Strictly isolated Layer-2 VLANs assigned per client tenant.
3.2 Workspace Architecture
Each hosted Workspace includes the following standard infrastructure components:
- A fully managed Execution Environment (EE)
- The physical Assembly operated by Vector
- Hardware Automation Interface (HAI) integration for device control
- A local, isolated high-speed network (10 GbE) for internal component communication
┌────────────────────────────────────────────────────────┐
│ Secure Workspace │
│ │
│ ┌──────────────────┐ Outbound only ┌────────────┐ │
│ │ vHaaS Agent │◄──────────────────►│ vHaaS AS │ │
│ │ (EE Host) │ │ (Cloud) │ │
│ └────────┬─────────┘ └────────────┘ │
│ │ │
│ │ Isolated 10 GbE LAN │
│ │ (no direct internet / intranet access) │
│ ▼ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Client Hardware Assembly │ │
│ │ ┌──────────┐ ┌──────────┐ ┌────────────────┐ │ │
│ │ │Target ECU│ │ Debugger │ │Relays & Meters │ │ │
│ │ └──────────┘ └──────────┘ └────────────────┘ │ │
│ └────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘
3.3 Setup, Cabling & Assembly Integration
3.3.1 Physical Setup
The contractor's technical team performs physical rack placement, professional cabling, and power hookups according to documentation supplied by the client. The setup is performed strictly following the client's specifications.
3.3.2 Network Isolation & Security
Critical Security Concept
By default, the network segment of a Physical Assembly has no direct routing to the public internet or corporate networks. This prevents external interference, protects intellectual property, and guarantees a noise-free test environment.
Any required outbound connectivity (e.g., external license servers, package repositories, source code) is securely proxied exclusively via the vHaaS Agent or dedicated outbound gateways.
3.3.3 Digital Twin Modeling
Following physical deployment, the contractor digitally models the cabling topology in the platform. Client teams can then control power, trigger resets, and monitor electrical state directly from the Web UI via the HAI.
3.3.4 Execution Environment Deployment & Network Architecture
Both the physical host and the Execution Environment running on it are deployed and configured entirely from code. The Proxmox VE host and the EE virtual machine are described declaratively in OpenTofu / Terraform and rolled out through GitLab CI/CD pipelines hosted on code.vector.cloud. No manual host configuration is performed — every change is version-controlled, reviewed, and reproducible.
┌────────────────────────────────────────────────────────┐
│ Infrastructure as Code — GitLab CI/CD │
│ (code.vector.cloud) │
│ OpenTofu / Terraform definitions │
└───────────────────────┬────────────────────────────────┘
│ deploys & configures host + VM
▼
┌────────────────────────────────────────────────────────┐
│ Execution Environment Host │
│ Proxmox VE — configured from code │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ Execution Environment (VM, deployed from code) │ │
│ │ Windows Server 2025 / Linux + vHaaS Agent │ │
│ └───────────────┬───────────────────┬────────────────┘ │
└─────────────────┼───────────────────┼──────────────────┘
│ Ethernet (NIC 2) │ USB
│ 192.168.10.2 │ (automatic
│ up to 2.5 Gbit/s │ passthrough)
▼ ▼
┌────────────────────────────────────────────────────────┐
│ Client Hardware Assembly │
│ ┌──────────┐ ┌──────────┐ ┌────────────────┐ │
│ │Target ECU│ │ Debugger │ │Relays & Meters │ │
│ └──────────┘ └──────────┘ └────────────────┘ │
└────────────────────────────────────────────────────────┘
Network Interfaces
Each Execution Environment is equipped with two separate network interfaces with strictly different purposes:
| Interface | Addressing | Scope | Bandwidth |
|---|---|---|---|
| NIC 1 — Uplink | DHCP or fixed private IP | Platform connectivity via the vHaaS Agent and controlled outbound access (license servers, package repositories, source code) | 1 Gbit/s inside the datacenter; 100 Mbit/s guaranteed outbound |
| NIC 2 — Assembly | Fixed IP 192.168.10.2 |
Intra-Assembly communication only; not routed beyond the Assembly segment | up to 2.5 Gbit/s |
Host Isolation
No lateral network access
An Execution Environment has no network access to any other host — this explicitly includes other hosts booked by the same client and all further hosts assigned to the same organization. Each EE is confined to its own Assembly segment and its controlled uplink path. Cross-workspace communication is not possible, even within a single tenant.
Typical Virtual Machine Profile (NUCs)
| Property | Typical Value |
|---|---|
| vCPU | 16 cores |
| Memory | 30 GB RAM |
| Disk | approx. 600 GB |
| Operating System | Windows Server 2025 or Linux |
| USB Devices | Physical USB devices of the Assembly (debuggers, interface boxes, measurement hardware) are attached to the VM automatically |
Deviating sizings are possible on request and are recorded in the client Workspace record. Refer to Section 7.1 for the commercially available EE tiers.
3.4 Hardware Intake & Handover Process
All client hardware delivered to the Vector datacenter undergoes a documented intake process:
- Delivery Coordination: The client schedules hardware delivery in advance via the ticket system. Unannounced deliveries cannot be accepted.
- Incoming Inspection: Upon arrival, Vector staff perform a visual inspection and document the condition of all received components (type, quantity, visible damage). The client receives a signed Incoming Goods Protocol (Wareneingangsprotokoll) confirming receipt.
- Responsibility Transfer: Vector assumes operational responsibility for the hardware from the point of confirmed receipt. The client is responsible for ensuring that hardware is delivered in functional condition with all necessary documentation (wiring diagrams, pin assignments, configuration requirements).
- Inventory Management: All client-owned hardware is tracked in an internal inventory register and is clearly labelled to prevent mix-ups between tenants.
Note
The client is responsible for ensuring adequate export compliance and shipping documentation for any hardware subject to customs or export control regulations.
4. Service Level Agreement (SLA)
4.1 Provisioning Lead Times
Initial Assembly setup begins once the client has delivered all required hardware components and sufficient schematic documentation.
| Setup Size | Complexity | Lead Time (Target) |
|---|---|---|
| Small | Up to 5 devices (e.g., 1 ECU + Debugger) | ≤ 10 working days |
| Medium | Up to 10 devices (e.g., ECU + VT-System + VN-Box) | ≤ 20 working days |
| Complex | Custom multi-component systems | Project-based agreement |
Capacity Planning
Ad-hoc availability of additional resources (rack space, NUCs, HAIs, support capacity) is not guaranteed by default. Scaling the environment requires prior coordination and adequate lead time.
4.2 Operational Availability
| Component | Target Annual Availability | Recovery Time Objective (RTO) |
|---|---|---|
| Execution Environment (EE) | 95.0% | Subject to contract / Best Effort |
| Physical Assembly | 95.0% | Subject to contract / Best Effort |
| Local Rack Network | 95.0% | Subject to contract / Best Effort |
All hosted environments are monitored 24/7 via Prometheus and Grafana. Announced maintenance windows are excluded from availability calculations.
Hardware Replacement Times
No guaranteed replacement times for defective hardware components (e.g., NUC, relay card, cabling) are defined at this service level. Vector will address hardware failures on a best-effort basis and communicate expected resolution timelines to the client as soon as they are known. Clients with specific recovery time requirements should raise this during the onboarding scoping discussion.
5. Maintenance & Patching
5.1 Execution Environment (EE) Updates
| Update Type | Cycle | Notice Period | Description |
|---|---|---|---|
| Patch Update | 1st Wednesday of the month | 1 week | OS security updates, package updates, driver maintenance. |
| Unplanned Maintenance | As needed | 3 days | Urgent datacenter work, power switchover, network routing changes. |
| Security Update | As needed | Prior to rollout | Critical CVE remediation; applied within 3 days of disclosure. |
5.2 Assembly & HAI Updates
Scheduled immediately after the EE patch window on the same day.
| Update Type | Cycle | Notice Period | Description |
|---|---|---|---|
| Patch Update | 1st Wednesday of the month | 1 week | Calibration, hardware tests, configuration updates for managed components. |
| Unplanned Maintenance | As needed | 3 days | Hardware swap, urgent repairs, or infrastructure changes. |
| Security Update | As needed | Prior to rollout | Critical CVE remediation; applied within 3 days of disclosure. |
6. Support & Change Management
6.1 Incident Severity Classification
The L3 service uses the same platform-level severity classification as L2, extended with hosting-specific criteria:
| Priority | Definition | Initial Response (Target) | Resolution (Target) |
|---|---|---|---|
| P1 — Critical | Complete loss of access to a hosted workspace; no workaround available. Includes total EE or network failure. | 1 hour | Best Effort (hardware-dependent) |
| P2 — High | Significant degradation of EE performance or partial Assembly failure impacting active work. | 2 hours | Best Effort (hardware-dependent) |
| P3 — Medium | Non-critical component failure with available workaround; limited operational impact. | 4 hours | 3 business days |
| P4 — Low | General queries, configuration questions, minor adjustments. | 1 business day | Best Effort |
Support window: Mon – Fri, 08:00 – 17:00 CET. Contact via ticket system; phone escalation for P1/P2.
Note
Physical hardware incidents (P1/P2) may have resolution times beyond the platform targets due to the time required for on-site diagnosis and component sourcing. Vector will provide regular status updates until resolution.
6.2 Problem Management
For P1 and P2 incidents affecting hosted infrastructure, Vector conducts a root cause analysis and provides the client with a written Post-Incident Report (PIR) within 5 business days of resolution. The PIR covers the incident timeline, identified root cause, impact assessment, and corrective or preventive actions taken.
6.3 Support Matrix
| Support Type | Scope | Contact | Response Time (Target) |
|---|---|---|---|
| Standard Support | Application Service and Execution Environment incidents. On-site excluded. | Ticket system; phone for critical issues. | 4 hours within support window |
| Hosting Support | Incidents related to network, EE, Assemblies, and their hardware components. | Ticket system; phone for critical issues. | 8 hours (on-site dispatch) within support window |
| Support Window | Mon – Fri, 08:00 – 17:00 CET | — | — |
On-site hands-on support is available on request for hardware swaps, manual jumper configuration, or temporary measurement instrument integration.
6.4 Change Requests
Hardware changes after initial setup must be requested by the client in writing (e.g., via ticket system). Minor adjustments can be billed against a pre-agreed support budget. Larger modifications are quoted separately.
6.4.1 Support for Defective Hardware
If a hosted hardware component (e.g., ECU, Execution Environment, cabling) is found to be defective, the client reports it via the ticket system, using the help icon (?) within the vHaaS platform. The report should include the affected Assembly ID and a precise description of the issue.
The ticket is triaged and assigned a severity level as described in §6.1. Depending on severity, the case may be escalated internally to ensure a timely response.
Once triaged, the repair or replacement is carried out as described in §6.4.4.
For P1/P2 incidents, a written report is provided in addition, as part of the Problem Management process (§6.2).
6.4.2 New Assembly Request
To request a new Assembly, click the help icon (?) in vHaaS → Support → Embedded Device and select the action Create. To help Vector estimate the effort involved, please provide as much detail as possible, including:
- The board to be used, and required connectors/switches
- Whether a debugger is needed, and which type
- Whether a VN-Box or other test/measurement equipment is required
- The wiring plan connecting the board to any test/measurement equipment
- Confirmation that all required hardware and licenses are provided by the client
A ticket is created and the client receives confirmation that the request was received. Setting up the new Assembly typically starts with a kickoff meeting to finalize requirements, followed by a stock/procurement check, build-up and testing, and handover to the client once the system is fully operational in vHaaS.
Lead times depend on the size and complexity of the setup and are stated in §4.1. They begin once all required hardware and schematic documentation have been delivered; deliveries must be scheduled in advance, see §3.4.
Commercial handling
A new Assembly is a larger modification and is quoted separately, as described in the introduction to §6.4. An initial quote is discussed upfront, based on the details provided with the request, and is finalized after the kickoff meeting once the requirements are confirmed.
6.4.3 Hardware Feature Request
Use this process to request a temporary or permanent change to an existing Assembly (e.g., replacing a component or adding an interface).
To submit a request, click the help icon (?) in vHaaS → Support → Embedded Device, which automatically fills in the setup details in the ticket system. Select the applicable action and include:
- The affected Assembly ID (e.g., "ASSEMBLY-123")
- A precise description of the requested change, and whether it is temporary or permanent
A ticket is created and the client receives confirmation that the request was received. Depending on scope, the change is either billed against a pre-agreed support budget or quoted separately; see the introduction to §6.4. Vector confirms the applicable handling before starting work.
6.4.4 Repair, Replacement & Hardware Changes
This section describes how the work itself is carried out, once a ticket from §6.4.1 or §6.4.3 has been triaged.
Vector determines the appropriate course of action — on-site repair, component replacement, or reconfiguration — based on the availability of spare parts and hardware. Physical work on hosted hardware is performed exclusively by authorized Vector datacenter staff.
The outcome is documented in the ticket. Vector then verifies correct operation (e.g., via status indicators and the platform dashboard) and asks the client to confirm resolution before the ticket is closed.
Note
Components that are Vector's property (e.g., NUC, HAI relay cards) are replaced by Vector and remain Vector's property; see also §11 Offboarding & Hardware Return.
6.5 Execution Environment Support Model (Roles & Owners)
The core responsibility of this Hosting Service is to provide and operate a managed Execution Environment (EE) within vHaaS. The EE is a dedicated host system connected to the vHaaS WebService through the vHaaS Agent and to the assigned physical Assembly inside the rack.
Default implementation model:
- Virtualization Standard: EE workloads run on Proxmox VE-managed physical hosts by default. Any non-Proxmox exception requires explicit documentation in the client Workspace record.
- Physical EE Hardware: Intel NUC systems (Windows standard today, Linux rollout planned) and Raspberry Pi systems (Linux).
- Operating Systems: Windows Server 2025 or Linux, depending on the agreed use case and device profile.
- Deployment Model: Host and EE virtual machine are deployed and configured from code (OpenTofu / Terraform via GitLab CI/CD on code.vector.cloud). The deployment topology, network interfaces, isolation guarantees, and typical VM sizing are described in Section 3.3.4.
| Role | Primary Owner | Responsibilities |
|---|---|---|
| Hosting Service Owner (L3) | Vector Service Management | Accountable for service scope, delivery quality, escalation governance, and cross-team coordination. |
| EE Platform Operations | Vector Infrastructure Team | Provisioning and lifecycle management of EE hosts (Proxmox baseline), host capacity planning, base image governance, and backup/restore procedures where contracted. |
| Endpoint Management | Vector Endpoint/Workplace Team | OS deployment (Windows Server 2025 / Linux), patching, endpoint configuration baselines, managed software packaging, and policy-based configuration enforcement. |
| vHaaS Agent Operations | Vector Platform Operations | Installation, registration, and health monitoring of the vHaaS Agent; ensuring reliable EE-to-WebService connectivity and controlled outbound access paths. |
| Network Infrastructure Operations | Vector Network Team | Rack switching, VLAN isolation, IP management, routing/firewall policies for EE uplinks, and incident handling for network connectivity faults. |
| Datacenter Field Operations | Vector Datacenter Technicians | Physical installation, cabling, device replacement, and hands-on diagnostics for NUCs, Raspberry Pis, and related rack components. |
| Client Technical Owner | Client | Provides workload requirements, approves selected managed tools, validates target hardware integration requirements, and signs off on change requests impacting test behavior. |
6.6 Support Processes for Execution Environments
| Process | Owner | Trigger | Output |
|---|---|---|---|
| EE Provisioning | EE Platform Operations | New Workspace onboarding or capacity expansion | Provisioned EE host (NUC or Raspberry Pi profile), OS baseline installed, Agent-ready state documented. |
| OS Deployment & Hardening | Endpoint Management | Initial delivery, rebuild, major refresh | Windows Server 2025 or Linux image with baseline security settings, endpoint policies, and required access controls. |
| Automated Tool Installation | Endpoint Management (with Client Technical Owner approval) | New tool request or template update | Approved toolset installed via automation (selected tools only), version state documented. |
| Agent Onboarding & Connectivity Validation | vHaaS Agent Operations | New EE provisioning or incident recovery | EE registered in platform, WebService connectivity verified, health checks passing. |
| Patch & Maintenance Cycle | Endpoint Management + EE Platform Operations | Monthly cycle or critical advisory | Patched OS and managed components; maintenance evidence and exceptions tracked in ticket/change records. |
| OS License Provisioning (Microsoft SPLA) | Vector Service Management + Endpoint Management | New Windows EE onboarding, license true-up, or contract change | Windows Server licensing provided and tracked under Microsoft's Service Provider License Agreement (SPLA), including tenant assignment and compliance records. |
| Basic Security Operations | Endpoint Management + Network Infrastructure Operations | Continuous operations, vulnerability advisories, audit findings | Endpoint baseline compliance, limited network exposure, and mitigation actions for identified risks. |
| Network Incident Handling | Network Infrastructure Operations | Connectivity degradation/outage | Restored EE network path (switch/VLAN/uplink), root-cause notes provided for P1/P2 events. |
| Hardware Break/Fix | Datacenter Field Operations | Device fault (NUC/Raspberry Pi, power, cabling) | Repaired or replaced component, post-fix validation with EE and Assembly connectivity checks. |
Implementation Constraints
Proxmox is the default operational model for physical EE platforms. Where technical constraints require a direct host configuration, the exception scope, ownership, and support boundaries must be explicitly recorded in the onboarding documentation.
Microsoft SPLA Program
Program details for Microsoft Service Provider License Agreement (SPLA): Microsoft SPLA Licensing Program.
6.7 Consolidated Roles and Owners
This table provides a single reference view of all support roles and their primary owners.
| Role | Primary Owner | Ownership Scope |
|---|---|---|
| Hosting Service Owner (L3) | Vector Service Management | Service accountability, escalations, governance |
| EE Platform Operations | Vector Infrastructure Team | EE host lifecycle and platform operations |
| Endpoint Management | Vector Endpoint/Workplace Team | OS lifecycle, patching, endpoint baseline |
| vHaaS Agent Operations | Vector Platform Operations | Agent lifecycle and platform connectivity |
| Network Infrastructure Operations | Vector Network Team | VLAN/switching/routing operations for EE uplinks |
| Datacenter Field Operations | Vector Datacenter Technicians | Physical install, break/fix, and cabling |
| Client Technical Owner | Client | Workload requirements and change approvals |
Process-level ownership (including shared ownership and SPLA licensing) is defined in Section 6.6.
7. Pricing & Workspace Configurator
Each vHaaS Workspace consists of two components: a mandatory Execution Environment and an optional Physical Assembly. Pricing is modular and based on the chosen configuration. All costs are in addition to the L2 user license.
7.1 Component 1: Execution Environment
Minimum commitment: 1 year.
| Tier | Specifications | Annual Cost (Ubuntu) | Annual Cost (Windows Server) |
|---|---|---|---|
| Medium | Intel® Core™ Ultra 5 (14 cores), 32 GB RAM, 500 GB SSD | On request | On request |
| Large | Intel® Core™ Ultra 7 (20 cores), 64 GB RAM, 1 TB SSD | On request | On request |
7.2 Component 2: Assembly Hosting (Rack & Power)
Base hosting costs include rack space, power, cooling, cabling, and full operational service.
| Workspace Size | Recommended Use Case | Annual Fee |
|---|---|---|
| Small (1 U) | Single ECU + debugger. Ideal for modular unit testing. | On request |
| Medium (2 U) | ECU + VT-System card or VN interface box. | On request |
| High (4 U) | Multiple ECUs, high-voltage relays, complex test boards. | On request |
| Individual | Custom multi-cabinet HIL racks. | On request |
7.3 Optional Hardware Extensions
| Component | Manufacturer | Description | Cost |
|---|---|---|---|
| Board Status Pin | Vector | Visual "alive" LED readable from the platform Web UI for fast diagnosis. | On request |
| vHaaS Multiplexer | Vector | Software-controlled signal/bus-line routing between Assembly components. Significantly increases automation potential. | On request |
| VIO / VT-System Cards | Vector | Real-time I/O simulation of sensor and actuator signals for deep HIL testing. | On request |
| Logic Analyzer | Third-party | Precise trace and timing analysis of digital communication lines (I²C, SPI). | On request |
| Oscilloscope | Third-party | Voltage curve tracing and analog signal validation. | On request |
8. Reference Use Cases
Use Case 1: Standard ECU Development (HIL)
Goal: Development, routine debugging, and firmware flashing on a single physical ECU.
Recommended configuration: EE Medium + Small Assembly (1 U)
Use Case 2: Multi-ECU System Integration
Goal: Fully automated system validation of networked ECUs within a CI/CD pipeline.
Recommended configuration: EE Large + High Assembly (4 U), optionally extended with VT-System I/O cards.
9. Third-Party Providers & Licenses
| Provider / Technology | Role | Data Protection Relevance |
|---|---|---|
| Cisco Systems | Network infrastructure (switches, rack networking) | Infrastructure sub-processor |
| Microsoft Corporation | Windows Server OS for EEs | Operating system provider |
| Canonical | Ubuntu OS for EEs | Operating system provider |
| 1&1 Versatel GmbH | Internet connectivity (primary) | Internet provider |
| Telekom Deutschland GmbH | Internet connectivity (redundant) | Internet provider |
| Fleet Inc. | Device Management | Application Service |
For cloud-layer third-party providers (AWS, Cloudflare, identity providers), refer to the WebService Service Description §8.
Security & Data Protection
For the full security architecture, GDPR/DSGVO compliance details, Technical and Organizational Measures (TOMs), and certification status, refer to the Security & Compliance section.
10. Service Reporting
In addition to the platform-level reporting defined in the WebService Service Description §11, clients with an active L3 Hosting engagement receive a monthly hosting report covering:
- Infrastructure Availability: Measured uptime per hosted component (EE, Assembly, network) against the 95% target, excluding planned maintenance.
- Incident Summary: All P1 and P2 hosting incidents, including duration, root cause status, and resolution.
- Maintenance Overview: Completed EE and Assembly patch windows, plus any unplanned maintenance activities.
- Hardware Inventory Status: Current inventory of client-owned hardware components held at the Vector datacenter, including condition flags from the most recent inspection.
Pilot Phase
During the pilot phase, hosting reports are provided on a best-effort basis. Format and delivery cadence may evolve as the service matures.
11. Offboarding & Hardware Return
Upon contract termination or explicit client request, the following offboarding process applies:
- Termination Notice: The client submits a written offboarding request via the ticket system, specifying the desired return date and shipping destination.
- Workspace Decommissioning: Vector decommissions the workspace in the platform, disconnects all cabling, and removes the client's physical hardware from the rack. A decommissioning date is agreed upon with a minimum lead time of 10 business days.
- Condition Inspection: Before shipping, Vector staff perform a visual inspection of all client hardware and document the condition. The client receives a signed Outgoing Goods Protocol (Warenausgangsprotokoll).
- Return Shipment: Client hardware is packaged and shipped to the address designated by the client. Shipping costs and any insurance for the return transport are borne by the client unless otherwise agreed.
- Data Deletion: All configuration data and platform records associated with the decommissioned workspace are deleted within 30 days of the final decommission date. A deletion confirmation is provided upon request.
Warning
Vector-owned infrastructure components (NUCs, HAI relay cards, network switches, racks) remain the property of Vector and are not included in the return shipment.