Google Cloud, Valtech launch open-source Nexus SDV platform for connected vehicles

Software is no longer something you buy once; it's a service that evolves.
Carmakers are shifting from selling finished vehicles to treating cars as platforms that receive updates and new features throughout their lifetime.

The automobile, long a symbol of mechanical completion, is becoming something more restless — a platform that learns, updates, and evolves long after it leaves the factory floor. Google Cloud and Valtech have released Nexus SDV, an open-source software-defined vehicle platform designed to connect up to 100 million cars to cloud intelligence while keeping their data and identities secure. The release arrives at a moment when carmakers must reckon with a new kind of responsibility: not just building vehicles, but sustaining them as living services. In offering a shared architectural foundation, the two companies are inviting an industry to stop reinventing the wheel and start building on common ground.

  • Carmakers face a mounting pressure to transform vehicles into continuously updated software platforms, but building that infrastructure from scratch is expensive and technically treacherous.
  • Nexus SDV enters this gap as an open-source platform capable of managing 100 million connected vehicles, processing real-time telemetry, and delivering AI-driven insights and over-the-air updates through Google Cloud.
  • Security is treated not as a feature but as a structural principle — mutual TLS, short-lived identity tokens, workload identity federation, and a custom Data API collectively ensure that neither vehicles nor backend services carry exploitable permanent credentials.
  • A layered gateway architecture restricts how applications query vehicle data, enforcing structured access patterns that scale gracefully as fleet telemetry volumes grow.
  • By releasing the platform as open-source software built on Arm processors and Bigtable, Google Cloud and Valtech are positioning Nexus SDV as an adaptable foundation that reduces the cost and complexity of entering the software-defined vehicle era.

The car industry is undergoing a quiet but profound transformation. Vehicles that once rolled off assembly lines as finished objects are becoming platforms — machines that receive new features, security patches, and capability upgrades over the air, much like a smartphone. That shift has created a new burden for manufacturers: they must now handle vast volumes of vehicle data securely, process it in real time, and do so without overwhelming their cloud budgets.

Google Cloud and Valtech have released an open-source response to that challenge. Nexus SDV is a software-defined vehicle platform built to manage connected cars at scale — up to 100 million devices. It sits between the vehicle and the cloud, ingesting telemetry, running it through AI models built on Google's Gemini, and returning insights and software updates back to the car. The platform integrates with Android Automotive OS and is designed around a modular architecture that treats software not as a one-time purchase but as a service that evolves over the vehicle's lifetime.

Security is woven into the platform's structure rather than added as an afterthought. Vehicles authenticate using mutual TLS and factory-issued certificates, which are exchanged for short-lived operational tokens that must be regularly refreshed — eliminating the risk of stolen static credentials. Backend services communicate using temporary credentials through Workload Identity Federation, and sensitive configuration data is stored in Google Cloud Secret Manager rather than embedded in code. Worker nodes run on private Kubernetes clusters with no public IP addresses, keeping them invisible to the broader internet.

Data access is controlled through a custom API that acts as a structured gateway between applications and the underlying data store. Rather than allowing open queries, it restricts requests to predefined vehicle identifiers, sensor types, and time windows — a design that enforces discipline as telemetry volumes grow.

By releasing Nexus SDV as open-source software, Google Cloud and Valtech are offering the industry a reference architecture and a starting point — one built on Arm-based processors and Bigtable for cost efficiency — that manufacturers can adapt to their own hardware and brand requirements without building these systems entirely from the ground up.

The car industry is in the middle of a fundamental shift. Where vehicles once came off the assembly line as finished products, they are increasingly becoming platforms—machines that receive new features, security patches, and capability upgrades over the air, the way your phone does. That transition has created a new problem for carmakers: they now need to handle enormous volumes of vehicle data securely, process it in real time, and do it without breaking their budgets on cloud infrastructure and development costs.

Google Cloud and Valtech have just released an open-source answer to that problem. It's called Nexus SDV, a software-defined vehicle platform built to manage connected cars at scale—up to 100 million devices. The platform sits between the vehicle itself and the cloud, ingesting telemetry data in real time, processing it through AI models, and sending software updates and services back to the car. It runs on Google Cloud infrastructure and integrates with Android Automotive OS, the in-vehicle operating system already used by some manufacturers.

The architecture is modular by design. At its core is Nexus AI, which uses Google's Gemini models to analyze vehicle data as it arrives. The system turns raw telemetry into actionable information—patterns that can trigger automated decisions or feed into more personalized driver assistance features. The goal is to create a continuous loop: data flows from the vehicle to the cloud, gets analyzed, and then insights and updates flow back to the vehicle. This reflects a broader shift in how carmakers think about their products. Software is no longer something you buy once; it's a service that evolves over the lifetime of the car.

But scale and convenience mean nothing without security. A significant portion of Nexus SDV's design is devoted to protecting vehicle identity, controlling who accesses what data, and preventing unauthorized changes to vehicle software. The platform uses what security architects call a defense-in-depth approach—multiple overlapping layers of protection rather than relying on any single lock.

Vehicles authenticate to the system using mutual TLS and public key infrastructure. When a car first connects, it presents a certificate issued at the factory. The system validates that certificate and issues a new operational certificate for ongoing use. Identity management runs through Keycloak, an open-source identity provider. Vehicles use their operational certificates to obtain short-lived tokens—credentials that expire quickly and must be refreshed—rather than relying on static passwords that could be stolen and used indefinitely. Backend services communicate with each other using temporary credentials obtained through Workload Identity Federation, which means no service needs to store permanent secrets in code or container images.

Secrets themselves—database passwords, configuration data, signing keys—are generated during infrastructure setup and stored in Google Cloud Secret Manager. Services retrieve them at runtime rather than embedding them. The platform runs on private Kubernetes clusters where worker nodes have no public IP addresses, making them invisible to the internet. The database that stores identity information uses IAM authentication, meaning access is controlled through identity and permissions rather than fixed passwords.

Data access is gated through a custom API that sits between applications and the underlying data store. Instead of letting applications query the database directly, the API restricts queries to predefined parameters: specific vehicle identifiers, particular sensor data types, set time windows. As vehicle fleets generate larger and larger volumes of telemetry, this gateway layer enforces structured access patterns and prevents applications from requesting more data than they actually need.

By releasing Nexus SDV as open-source software, Google Cloud and Valtech are positioning it as a building block that manufacturers can adapt to their own hardware, software roadmaps, and brand requirements. The platform uses Arm-based processors and Google's Bigtable database for data processing and storage—infrastructure choices designed to keep total cost of ownership low while providing an environment where AI-driven vehicle services can run natively. For carmakers navigating the transition to software-defined vehicles, the release offers a reference architecture and a starting point, reducing the pressure to build these systems entirely from scratch.

The shift from traditional connected vehicle models to software-defined vehicles has increased the volume of vehicle data that must be handled securely and added pressure on manufacturers to control cloud and development costs.
— Google Cloud and Valtech, via platform documentation
La Conversación del Hearth Otra perspectiva de la historia
Inventor

Why does a carmaker need a platform like this at all? Can't they just build their own cloud infrastructure?

Model

They could, but it would be expensive and slow. A carmaker's expertise is in vehicles, not cloud infrastructure or AI systems. Building secure, scalable telemetry pipelines from scratch takes years and specialized talent. Nexus SDV gives them a head start—proven patterns for handling millions of vehicles simultaneously.

Inventor

The security architecture sounds complex. Why so many layers?

Model

Because the stakes are high. A compromised vehicle isn't just a data breach—it's a safety issue. Someone could potentially modify software, disable safety systems, or cause physical harm. Defense-in-depth means that even if one layer fails, others are still protecting the system. It's not paranoia; it's proportional to the risk.

Inventor

What does it mean that vehicles get short-lived tokens instead of permanent passwords?

Model

A permanent password, if stolen, works forever. A short-lived token expires in minutes or hours. An attacker who steals it has a narrow window to use it before it becomes worthless. The vehicle has to keep refreshing its credentials, which means the system can detect and stop suspicious activity more easily.

Inventor

The Data API that restricts queries—isn't that limiting? What if an application needs data the API doesn't allow?

Model

It's a tradeoff. Yes, it's restrictive by design. But that restriction is the point. It prevents applications from accidentally or maliciously accessing more vehicle data than they should. If a legitimate need arises, the API can be updated. It's easier to add access than to secure a system where everything is open.

Inventor

Why open-source? Why not keep this proprietary?

Model

Open-source lets manufacturers adapt it to their own needs without being locked into Google's vision. A Toyota and a Volkswagen have different requirements, different hardware, different software stacks. Open-source means they can fork it, modify it, contribute improvements back. It becomes an industry standard rather than a vendor lock-in.

Inventor

What happens next? Is this actually going to be adopted?

Model

That's the real question. The platform exists and it's available, but adoption depends on whether carmakers trust it and whether it actually reduces their costs and complexity. The next phase is seeing whether real manufacturers build on top of it.

Contáctanos FAQ