Deploy a managed process

Sometimes you don’t want a container. Maybe it’s a Go binary that’s already statically linked. Maybe it’s a Python script with a virtualenv on the device. Maybe the workload has hardware access (GPU, USB) that’s awkward to plumb through Docker.

The managed-process workload type lets the agent supervise a long-running command directly. The agent starts it, restarts it if it dies, captures its logs, and stops it on teardown.

When to use it

• A single binary that can run as a long-lived process.
• Something you’d otherwise wrap in a systemd unit just to keep it alive.
• Workloads that need direct access to device hardware.

What it looks like

app.yml

apiVersion: v3
kind: Application
metadata:
  name: telemetry-collector
  organization: <your-org-id>
spec:
  placement:
    strategy: serving-device
    deviceSelector:
      deviceName: my-first
  workloads:
    - name: collector
      type: managed-process
      command: ["/opt/collector/bin/collector", "--config", "/etc/collector.toml"]
      workingDir: /opt/collector
      logFile: /var/log/edgible/collector.log
      env:
        COLLECTOR_LOG_LEVEL: info
        COLLECTOR_REGION: ap-southeast-2
      ports:
        - { name: metrics, containerPort: 9090, protocol: tcp }
  access:
    - name: metrics
      type: https
      target: { workload: collector, port: metrics }
      hostname: { custom: telemetry.example.com }
      tls: { managedBy: edgible }
      policies:
        auth: { mode: api-key }

Field notes:

• command is an argv array, not a shell string. No interpolation, no piping — if you need that, point at a wrapper script.
• workingDir is the directory the process runs in. The binary, scripts, and any relative paths in command resolve from here.
• logFile is where stdout and stderr are written. The agent rotates the file when it grows past a few hundred MB.
• env is a flat string-to-string map. No expansion of other env vars — values are passed through literally.
• ports declares what the process listens on. Edgible doesn’t enforce this; it’s how the access entry knows which port to target.

The binary needs to exist on the device

The agent does not download or build your binary — it expects something to run at the path you give. Get the binary on the device by whatever means you already use: scp, a deploy script, a CI pipeline that pushes artifacts. The application YAML is the runtime declaration; the artifact’s lifecycle is yours.

Lifecycle

When you deploy:

1. The agent receives the new application.
2. It writes a small unit description for the process (process group, restart policy, log file).
3. It launches the command with the configured env, working dir, and stdio routing.
4. The agent re-launches the process on exit, with a brief backoff. After repeated rapid failures the agent stops trying and reports the workload as failed.

When you tear down:

1. The agent sends SIGTERM to the process.
2. After a grace period, it sends SIGKILL if the process hasn’t exited.
3. The log file is left in place.

Watching it

edgible device application-health --name my-first
edgible application get -i <app-id>

For the process’s own logs, read logFile directly on the device (ssh in, tail -f) — the agent doesn’t currently surface those over the API. Improving this is on the roadmap.