Service
A service is a process you tell the platform to keep running on a device. Unlike a job, which runs to completion and produces a result, a service is meant to stay up, and the platform restarts it when it does not.
This is the free-form version: you supply the command. When what you want to run is one of your own models behind an endpoint, the platform builds that service for you, and it has its own page (Model deployment).
Why it exists
Some work on a device is not a run with an end. A collector that samples a sensor, a helper daemon a benchmark needs, a container that has to be up while a test runs: all of it needs to be started, watched, restarted and eventually stopped, on a machine you may not be able to reach directly. A service is that, expressed once and then maintained by the platform.
Desired state, not commands
The platform stores a desired state per device: which services should be running, with what command, environment, artifacts and health check. A reconciler compares that against what the device reports in its heartbeat and issues the difference.
Three useful behaviors fall out of that.
- A start survives an offline device. Desired state persists while a device is unreachable, so starting a service on a device that is not connected is not refused: it is recorded, the service reads
pending, and it starts when the device comes back. - Crashes self-heal. A service that dies falls out of the reported state, so the reconciler starts it again, with a backoff that gives up after repeated failures rather than restarting forever.
- The fleet is declarative. You state what a device should run, and the platform converges toward it. Starting or stopping through the API or the web application updates desired state too, so the imperative path gets the same tracking.
The service definition
A definition is a reusable template. Its fields:
| Field | What it declares |
|---|---|
command | The process to run, as an argument array. |
type | process (a command) or compose (a Docker Compose project on a device that has Docker). |
env | Environment variables for it. |
artifacts | Files staged on the device before it starts, by artifact and tag. |
health_check | How the platform decides it is up: a URL to poll, an interval and a timeout. |
auto_restart | Whether to restart it when it exits. |
port | The port it listens on. |
required_resources | Minimum hardware the device must report. |
resource_limits | Bounds on the running process: CPU cores and memory. |
Write a service definition covers the YAML in full, including how to start a service from a definition and override its defaults per device.
States
A service moves through pending (recorded, not started yet), starting, running, and then failed or stopped. A stop whose cleanup could not finish reads cleanup_failed.
Stopping a service stops its whole process group, so a wrapper script that forked workers takes them with it. On Unix the stop is graded, a polite signal first and a kill once the grace period is spent; on Windows the process group is terminated outright, because a service there has no console to receive the polite signal.
Where you see it
- Web UI
- CLI
- Claude
Services in the sidebar holds the definitions and the running services; a device's own Services tab shows what that device is running, with its state, uptime, restart count and a live log.
clika-rt apply -f service-definition.yaml # kind: ServiceDefinition
clika-rt apply -f start-service.yaml # kind: Service, naming its devices
Ask Claude:
What services are running on my devices, and has anything restarted more than once?
That reaches get_services and the per-device service state on get_devices_id. Starting and stopping services stays outside the served toolsets, so those remain deliberate actions.
Related pages
- Model deployment: the service the platform builds for you, for serving a model.
- Device: what a service runs on.
- Job: the other thing the platform runs on devices.