Skip to main content
Version: Next

Deploy generic Service

In this section, we will walk through the basic flow of running a generic Service on AosEdge.

A generic Service is a service that runs as a Linux container, typically used for non-safety-critical workloads such as data collection, connectivity, or predictive functions.

This guide covers the process from development to registration, packaging, deployment, and update.

It’s also important to note that both OEM and SP (Service Provider) users participate in this flow — each playing different roles in developing, registering, and operating the Service.

Develop

Because generic Services run within a Linux container environment, you can develop them in almost any programming language — Python, C++, Go, or Rust — as long as the necessary runtime libraries and dependencies are available in the target container base image.

This allows utilizing existing application code and also bring non-automotive background developers on-board much easier.

Hello World (Python)

For a simple Hello World application in Python, check Get Started > 4. Create a Service.

Other examples

See Tutorials > Service > Sample code & tutorials. You will find examples such as:

  • Hello World (C++)

  • Client/Server Services (C++)

  • SQLLite (Python)

Register as a Service

To integrate your developed software into AosEdge, it must first be registered as a Service. Registration creates the necessary metadata for lifecycle management, including the generation of a Service ID required for packaging and deployment.

Key registration entities include:

  • Service – Defines your application’s identity and interface.

  • Unit Set (Verification Set) – Groups Units used for testing or verification.

  • Subject – Represents the logical binding between Services and Units.

  • Package – Contains the actual container image and deployment metadata.

Once your Service is registered, AosEdge issues a unique Service ID that you’ll use to package and deploy it.

Package, Upload, and Deploy

After registration, the next steps are:

  • Package – Bundle your Service container image along with configuration and metadata (e.g., service.yaml) including the issued Service ID.

  • Sign & Upload – Push the package to AosEdge using Aos CLI Tool aos_signer.

  • Deploy – Assign the Service to target Units using the registered Subject which will allow the Service to be deployed to the target Units.

After deployment, AosEdge orchestrates the container startup and monitors its status under the assigned Unit.

Confirm and Monitor

Once deployed, you can confirm that your Service is running properly by checking:

  • Service status via the AosEdge dashboard

  • Logs and metrics collected from the container runtime

  • API response from the Service endpoint (if applicable)

See Advanced service operation > Monitor your service for more.

Update

When you need to update your Service, simply rebuild your container image, increment the version, and redeploy.

AosEdge handles version control and rolling updates safely without disrupting other Services running on the same Unit.

See Updates & Campaigns > Update service for more.

Summary

Running a generic Service on AosEdge follows the same principles as cloud-native container deployment — but with added layers of safety, security, and policy management suited for the automotive environment.

This sets the foundation for scalable, updatable software functions across vehicles, fleets, and edge environments.