How SPEKTRA Edge works

SPEKTRA Edge runs containerized applications on fleets of edge devices — hardware sitting in shops, factories, vehicles, or offices, far from a data centre and often on unreliable networks.

You do not administer those devices one at a time. You describe what a device should look like and what should run on it, and the platform makes it so, whether you have one device or ten thousand.

This page gives you the mental model behind that. If you have been through Get started, it explains what was actually happening while you clicked; if you have not, nothing here depends on it.

The shape of the system

There are three sides to it: the tools you work with, the platform itself, and your devices out in the field.

flowchart LR
    %% --- What you use ---
    subgraph YOU["You"]
        DASH["Dashboard"]
        CLI["cuttle CLI"]
        API["Your own code<br/>(gRPC / REST)"]
    end

    %% --- The platform ---
    subgraph PLATFORM["SPEKTRA Edge platform"]
        SVC["Core services<br/>identity, devices, applications,<br/>monitoring, logging, limits"]
    end

    %% --- The edge ---
    subgraph EDGE["Your devices"]
        D1["Device<br/>droplet + pods"]
        D2["Device<br/>droplet + pods"]
    end

    DASH --> SVC
    CLI --> SVC
    API --> SVC
    SVC <-->|"desired state down,<br/>status, metrics, logs up"| D1
    SVC <-->|"desired state down,<br/>status, metrics, logs up"| D2

Everything the dashboard shows you, it reads through the platform API. The cuttle CLI uses that same API, and so can your own code — see Integrate. That means most of what you do in the dashboard can be scripted and automated.

The objects you work with

Four things account for most of what you will do.

flowchart TD
    P["Project<br/><i>your fleet, pinned to a region</i>"]
    D["Device<br/><i>one piece of hardware</i>"]
    A["Distribution<br/><i>an application and where it should run</i>"]
    PO["Pod<br/><i>a running container on a device</i>"]

    P --> D
    P --> A
    A -->|"scheduled onto<br/>matching devices"| PO
    D -->|"hosts"| PO

• A project is your fleet. It groups devices, applications, and the people who can touch them, and you pick the region it lives in when you create it.
• A device is one piece of hardware running SPEKTRA Edge OS, or your own Linux machine with the agent installed.
• A distribution is an application plus a rule for where it should run. You target devices by label rather than by name, so growing the fleet does not mean editing deployment lists.
• A pod is the actual running container on a device. The droplet runtime on each device starts pods, keeps them running, and reports back.

Devices pull their configuration, they are not pushed to

This is the part that most often surprises people coming from conventional server management.

You never “run a command on a device” in the normal course of operating a fleet. Instead you record the state you want on the platform, and each device continuously pulls that state and makes itself match. A device that was offline when you made a change picks it up when it reconnects; no retry queue, no partial rollout to reconcile by hand.

Two practical consequences:

• Changes are durable. A device that reboots, or gets replaced, comes back to the state you described.
• Editing a device by hand does not stick. Changes to the read-only system image are lost on reboot. See how persistence works.

What the platform gives you

You get these as part of the platform, rather than assembling them yourself.

Each one has a full API reference under Service APIs. You will also see these names in audit entries, in IAM role definitions, and in cuttle commands.

Regions

The platform runs in multiple regions, and a project belongs to one of them. Pick the region closest to your devices when you create a project: it is the region your devices talk to, so proximity matters for latency and for how quickly a device picks up a change.

Next steps

• Applications — build an image, deploy it, configure it, and watch it run.
• Devices — set up hardware and operate it.
• Build a service — if you want to publish your own service on the platform rather than consume it.