Security

Open VTS is a self-hosted vehicle tracking platform. That architecture changes the security model: customers typically choose the cloud account, data center, operating system, reverse proxy, backup strategy, and data retention settings for production workloads.

Our responsibility is to build and deliver software with practical security controls, maintain the integrity of the Open VTS website and software distribution workflows we operate, and provide guidance that helps customers deploy responsibly.

In most engagements, production vehicle, driver, route, and telemetry data is stored in systems controlled by the customer rather than in Open VTS-operated multi-tenant infrastructure. That gives customers more control over data residency, vendor exposure, and network boundaries.

• Customers can host Open VTS on infrastructure they control, including private cloud, dedicated servers, or region-specific environments.
• Production-safe deployment guidance supports release isolation, persistent upload storage, health checks, and rollback workflows for managed server operations.
• Where Open VTS provides temporary implementation access, troubleshooting, or managed hosting, access is limited to the agreed support scope and should be governed by contract and operational approval.

We follow least-required-access principles for the systems and workflows we directly operate. Administrative access should be limited, reviewed, and provided only to personnel or contractors who need it for support, maintenance, or delivery work.

For customer-hosted environments, the customer is responsible for identity providers, password policies, privileged access controls, VPN or network restrictions, and account lifecycle management for their administrators and end users.

Open VTS recommends that customers protect production traffic with HTTPS or other appropriate transport-layer controls, secure database and file storage according to their environment, and maintain backups that are tested and monitored for restore readiness.

Because the platform is commonly self-hosted, encryption at rest, key management, data retention, logging destinations, and regional storage decisions are usually controlled by the customer and their chosen infrastructure providers.

When Open VTS receives business contact information, support materials, or diagnostic artifacts, we protect them with reasonable administrative, technical, and organizational safeguards suited to the nature of the information and the support workflow involved.

Security is considered throughout the product and website lifecycle, including code review, dependency management, environment separation, and release validation. We aim to fix security issues at the root cause rather than only masking symptoms.

• Software updates and website changes are reviewed and validated before release.
• Deployment workflows include health-check patterns and rollback guidance to reduce the impact of failed releases.
• Secrets, environment variables, and runtime storage paths are handled with explicit configuration rather than assumed defaults.
• Support for self-hosted operation reduces dependency on shared multi-tenant data planes and allows customers to apply their own hardening standards.

Open VTS uses logging, diagnostics, and operational review processes appropriate to the systems we directly run, including the website and service workflows we manage. If we identify a material security issue affecting those systems or software we distribute, we will assess scope, prioritize remediation, and communicate with affected customers as appropriate to the situation.

In customer-hosted environments, customers are generally best positioned to detect host-level, network-level, and data-plane incidents because they control the underlying infrastructure, observability stack, and access logs.

A self-hosted model gives customers control, but it also means customers own important parts of the security posture for their environment.

• Harden servers, databases, storage, and reverse proxies used to run Open VTS.
• Use strong credential practices, access reviews, and network restrictions for administrative accounts.
• Apply lawful privacy notices and workforce controls for vehicle tracking, telematics, and camera features used in the field.
• Maintain backups, patch infrastructure dependencies, and test recovery procedures for business continuity.
• Review integrations, device firmware, and third-party vendors connected to the deployment.

If you believe you have found a security issue in the Open VTS website, downloads, or other assets we operate, please report it privately so we can investigate and remediate it responsibly.

Please include a clear description of the issue, affected URL or component, reproduction steps, expected and actual behavior, and any supporting screenshots or logs that help confirm the report. Do not publicly disclose the issue until we have had a reasonable opportunity to investigate.

For security questions, procurement reviews, deployment-hardening discussions, or private vulnerability reports, email info@openvts.io. You can also reach us through our contact page.