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.

Concept & spec

An AosEdge Service is built as a lightweight container image with configurable restrictions on CPU, RAM, and storage usage.

The root filesystem layer is shared with the device OS, while other filesystem layers come from the Service package or AosCloud.

Service file package

All Service files (binaries, libraries, configs) must be provided within a defined directory structure:

.
├── meta  
│   ├── config.yaml
│   ├── state.dat
│   ├── aos-user-sp.p12
└── src
    ├── /usr/bin/services
    │            └── hello_world.py
    └──/etc/hello.cfg

The key configuration file is meta/config.yaml (Service config), which defines metadata, runtime parameters, and resource limits.

Service deployment workflow

The diagram below illustrates how a Service is prepared, packaged, and deployed through AosEdge.

loading...

Config file transformation workflow

AosCloud processes the provided config.yaml (Service config) to produce:

• OCI Image Manifest
• OCI Image Configuration
• AosEdge Service Configuration

These are sent to the device as below archive:

├── blobs
|   └── sha256
|       ├── <hash1>  -- config
|       ├── <hash2>  -- service_config.json
│       └── <hash3>  -- service rootfs layer 
└── manifest.json -- image manifest

Then, AosCore's Service Manager generates the OCI runtime spec.

info

For more detail, see Conversion to OCI Runtime Configuration.

OCI spec deviation

OCI spec	AosEdge deviation
OCI image manifest	Currently, AosEdge supports: platform — Linux architecture — amd64, arm
OCI image configuration	User — will be ignored Entrypoint — will be ignored Volumes — will be ignored StopSignal — currently not supported rootfs — not required and is ignored
OCI layer	Whiteouts — currently not supported
OCI runtime specification	Runtime specifications are mostly supported by runc process — consoleSize parameters are always false apparmorProfile — currently not supported selinuxLabel — currently not supported User — is ignored

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.