Skip to content

Neops Worker SDK

Neops lets you write small Python scripts — called function blocks — that automate tasks on your network devices: collecting show commands, pushing configs, checking compliance, discovering inventory. The platform handles scheduling, connections, and retries so you can focus on automation logic rather than plumbing.

The Worker SDK is the Python framework that makes this possible. It gives you pre-built classes for defining inputs and outputs, managing device connections across vendors, and testing your automation locally before deploying it.

Architecture

graph LR
    CMS["CMS"] -- entity data --> WE["Workflow Engine"]
    WE -- creates jobs --> BB["Blackboard"]
    BB -- polls jobs --> SDK["Worker SDK"]
    SDK -- executes on --> ND["Network Devices"]
    SDK -- writes results --> BB

The Workflow Engine breaks high-level intent into discrete jobs and places them on the Blackboard (a shared job queue). Workers running the SDK poll the blackboard, execute function blocks against network devices, and post results back. The CMS provides entity data (devices, interfaces, groups) that function blocks use during execution.

Platform Components

The Workflow Engine orchestrates workflows, manages the blackboard, and handles job distribution. See its documentation for workflow authoring, execution lifecycle, and deployment. The CMS provides entity data (devices, interfaces, groups) -- its documentation is forthcoming. See the Glossary for definitions of all key terms.

Explore the Documentation

  • Getting Started

    Set up your environment and write your first function block in minutes.

    Quick start

  • Function Blocks

    Learn the core abstraction — typed, reusable execution units for network automation.

    Function blocks

  • Device Connections

    Connect to any vendor through the proxy/plugin architecture.

    Connections

  • Testing

    Test function blocks locally or against real devices in the remote lab.

    Testing

  • Deployment

    Run workers in production with Docker, systemd, or Kubernetes.

    Deploy

  • Resources

    Examples, glossary, and configuration reference.

    Resources

Why Neops?

If you already use nornir, Ansible, or custom Python scripts for network automation, here is what neops adds:

  • Workflow orchestration -- Compose function blocks into multi-step workflows with conditions, retries, and parallel execution. The engine handles sequencing; you handle the logic.
  • Safe retries and rollbacks -- Mark your blocks as pure (read-only) or idempotent (safe to re-run). The engine uses this to decide whether a failed workflow can be retried automatically or needs manual intervention.
  • Vendor-agnostic connections -- The proxy/plugin architecture lets you write a function block once and run it against Cisco, Juniper, Arista, or any vendor with a registered plugin. No if platform == "ios" branching.
  • Built-in testing -- Test function blocks locally with mock contexts, or against real devices in a remote lab with a single decorator.
  • Automatic state tracking -- Modify devices, interfaces, or groups in your function block. The SDK diffs the changes and persists them to the CMS automatically.

New to the terminology? See the Glossary for definitions of Blackboard, CMS, Entity, and other key terms.

How It Works

Developers write function blocks — small, typed Python units that encapsulate a single automation task such as collecting interface counters or pushing a config template. Function blocks are registered with the workflow engine, which maps them to specific workflow steps. At runtime, workers poll the blackboard for pending jobs, execute the matched function block with the provided entity context, and write structured results back. This decoupled architecture lets you scale workers independently, test blocks in isolation, and deploy updates without restarting the entire platform.