Deployment Specs

Deployment Specs

Deployment specs are .sidl files that define how services are organized into processes, which transport backend to use, how processes start up, and how the OS-level supervisor should manage them. Multiple deployment specs can coexist in a project — for example, monolith.sidl for development and multiprocess_dbus.sidl for production.

Full Example

deployment:
  name: multiprocess_dbus
  version:
    major: 1
    minor: 0
  mode: multiprocess   # monolith | multiprocess
  ipc: dbus            # inprocess | dbus | grpc | posix — fallback when SUML arrows have no label

domains:
  service:
    launcher: systemd
    install:
      prefix: /opt/myapp
      user: myapp
      group: myapp
    restart_policy: on-failure
    logging:
      strategies: [file]
      file_dir: /var/log/myapp
      file_rotation_size_mb: 10
      file_rotation_count: 5
  
  hmi_session:
    launcher: script
    logging:
      strategies: [console, file]

processes:
  climate_hal_app:
    domain: service
    services:
      - ClimateHal
    runtime: dev-grpc    # optional: enables runtime debug adapter

  car_service_app:
    domain: service
    services:
      - ClimateManager
      - AudioManager
    start_after:
      - climate_hal_app
    grpc_port: 50052     # for gRPC transport

  hmi_app:
    domain: hmi_session
    services:
      - HmiGateway
    start_after:
      - car_service_app

Top-Level Fields

deployment

Field	Description
deployment.name	Deployment name. Used as the directory name under gen/deployments/.
deployment.version	Version of this deployment spec.
deployment.mode	monolith — all services in one process; multiprocess — services split across separate processes.
deployment.ipc	IPC backend fallback: inprocess, dbus, grpc, or posix. Per-connection transport can be set via SUML arrow labels (takes priority).

Mode and Transport

Mode	IPC	Description
monolith	inprocess	All services share a single process and communicate via direct shared_ptr calls. No IPC overhead.
multiprocess	dbus	Each process group runs independently; DBus carries inter-process calls. Linux only.
multiprocess	grpc	Each process binds to a port; gRPC carries inter-process calls. macOS and Linux.
multiprocess	posix	Each process binds a POSIX Unix Domain Socket. No external deps. macOS and Linux.
multiprocess	mixed	Different connections use different transports — set per-arrow in the SUML diagram. The ipc: field is the fallback.

Per-Connection Transport (Mixed IPC)

Add a transport label to arrows in the SUML deployment diagram to override the global ipc: for that connection:

ClientApp --> PlatformService : posix
ClientApp --> CloudService    : grpc

IPC priority: SUML arrow label > ipc: fallback > SERP053 error

Domains

Domains group processes that share the same launcher, installation config, restart policy, and logging settings. Every process must belong to a domain.

domains:
  service:
    launcher: systemd          # systemd | initd | android_init | script
    install:
      prefix: /opt/myapp       # installation prefix
      user: myapp              # OS user for the process
      group: myapp             # OS group for the process
    restart_policy: on-failure
    logging:
      strategies: [file]
      file_dir: /var/log/myapp
      file_rotation_size_mb: 10
      file_rotation_count: 5

launcher

Value	Description
systemd	Generates .service unit files. Linux with systemd.
initd	Generates traditional init scripts. Older embedded Linux.
android_init	Generates .rc files for Android init. AAOS targets.
script	Generates simple shell scripts. No OS-level supervisor. Development and macOS.

Logging per Domain

Field	Description
strategies	List of log output strategies: console, file, or both.
file_dir	Directory for log files (used when file strategy is active).
file_rotation_size_mb	Rotate log file when it exceeds this size in megabytes.
file_rotation_count	Number of rotated log files to keep.

Processes

Each entry under processes defines one executable.

processes:
  car_service_app:
    domain: service
    services:
      - ClimateManager
      - AudioManager
    start_after:
      - climate_hal_app
    grpc_port: 50052
    runtime: dev-grpc

Process Fields

Field	Required	Description
domain	Yes	Which domain this process belongs to (inherits launcher, logging, install config).
services	Yes	List of service names (from service specs) that run in this process.
start_after	No	List of process names this process waits for before starting. Controls startup ordering.
grpc_port	No	Port this process listens on. Required per process when transport: grpc.
runtime	No	Enables the runtime debug adapter. dev-grpc or dev-dbus. Engineering builds only.

runtime

Attaching a runtime adapter to a process enables the SERP runtime console to connect to it for live introspection — inspecting property values, triggering method calls, watching broadcasts. Do not enable in production builds.

What serpgen Generates per Process

For each process defined in a multiprocess deployment, serpgen generates:

gen/deployments/multiprocess_dbus/
  car_service_app/
    main.cpp            # Service instantiation, transport init, app.run()
    CMakeLists.txt      # Build target for this process executable
  lifecycle/
    car_service_app.service   # systemd unit (if launcher: systemd)

For a monolith deployment, there is a single main.cpp and CMakeLists.txt at the deployment root.

Related Pages

• Deployment Configurations — choosing between monolith, DBus, and gRPC modes
• Lifecycle Backends — systemd, init.d, Android Init detail
• Service Specs — service declarations that processes reference
• Generator Overview — serpgen generate-deployments command