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: { modes: [api-key] }

Field notes:

• command is a single shell command line, run through /bin/sh -c. Quoting, $VAR expansion, && and redirections all work as they would in a shell script. Keep it to one line; anything more involved belongs in a wrapper script you point the command at.
• 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 --device my-first
edgible application get --app <app-id>

The process’s own output comes back with the rest of the application’s workload logs — no ssh needed:

edgible application logs --app <app-id>
edgible application logs --app <app-id> --follow

A managed process’s output is buffered in memory by the agent, so it starts fresh after an agent restart; anything you need to keep beyond that is what logFile is for, and that file stays on the device. See Diagnose a broken app.