Meet lantronix.oob, a Red Hat–certified Ansible collection that puts the SLC 9000 console server and the Percepxion cloud platform inside the playbooks you already run.

As a network admin, you already live in Ansible. You configure switches, push router baselines, manage firewall rules, and keep dozens of sites consistent and it’s all from version-controlled playbooks. So why is your out-of-band platform the one box you still log into by hand?

That gap has a cost. Every in-band change goes out through automation; your OOB platform never hears about it. Every time you need to verify the state of a console-server fleet, someone checks it by hand. And the moment a playbook needs to reach a device through the out-of-band path, you hit a wall.

The Lantronix SLC 9000 with Percepxion closes that gap — and lantronix.oob is how. It’s a certified Ansible collection that gives your existing playbooks direct, API-native access to both the SLC 9000 console server and the Percepxion cloud management platform. No web UI detour. No manual steps. Just YAML.

What the collection is

lantronix.oob is an Ansible collection published on Red Hat Automation Hub and certified for production use (current version 1.0.21). Every module talks straight to the REST API — no CLI scripting, no screen scraping, no SSH piped through expect.

Every module is idempotent. Run the same playbook ten times and the result is identical each time — nothing changes on a device that’s already in the desired state.

Why this matters at scale

Enterprise networks aren’t getting simpler. Most admins are all-too-familiar with more sites, more devices, more compliance requirements, flatter headcount… Work that was tolerable to do by hand at 20 sites is unacceptable at 80. Yet traditional OOB platforms have historically been the exception to whatever automation discipline governs the rest of your stack. That model breaks. Three failure modes show up most often:

The lantronix.oob collection answers all three. The SLC 9000 and Percepxion are API-first by design. It works with what you already have, slotting the OOB platform into the automation you already run instead of asking you to rip and replace.

How it works

Both the SLC 9000 and Percepxion REST APIs run on OpenAPI (3.1 and 3.01 respectively). The modules handle authentication, request construction, and response parsing. You write YAML; the collection makes the calls.

Install from Red Hat Automation Hub


Your inventory defines the devices and connection parameters. Credentials live in Ansible Vault, never in plaintext.


Each module follows the same pattern to pass connection parameters and the desired state. The module checks current state, changes only what’s needed, and reports back.

Already at that hostname? The module reports ok and moves on. Not configured? It makes the change and reports changed. Standard Ansible behavior. The Percepxion modules work identically by pointing at the Percepxion API instead of the device so the same playbooks that touch your SLC 9000s can query fleet state, trigger firmware jobs, and manage smart groups.

Four playbooks that show the value

The value | A two-day manual task becomes a five-minute automated run AND you can prove it was done.

Your change process requires every OOB device at the affected sites to be on a specific firmware before tonight’s window opens. You need to know which ones aren’t, and preferably without logging into each one.


The value | A day-long check now takes minutes, and the output is machine-readable for your ticketing system.

Security needs a record of who touched what, and when, across the fleet before a periodic review without doing 150 separate login sessions to piece it together by hand.

Certified, signed, and ready

This isn’t a community side project. The Lantronix collection is published and signed on Red Hat Automation Hub, with full module documentation, dependencies, and version history. It’s the same place your team already pulls other certified content.


The lantronix.oob collection on Red Hat Automation Hub is published, signed, and certified.

This belongs in your pipeline

Because the collection uses Ansible Vault for credentials, it drops cleanly into GitHub Actions, Jenkins, or GitLab CI. Store the vault password as a pipeline secret and run the playbook as a stage. Baseline enforcement can run on a schedule or as part of a larger infrastructure pipeline so your OOB fleet stays in sync with your documented state without anyone remembering to kick off a check.

Prefer asking over scripting?

The Percepxion MCP server puts the same API behind a conversational interface. Point an AI agent at a device and ask what’s wrong, instead of writing a playbook. Different entry point, same API-first foundation. Both MCP servers are live on GitHub: slc-mcp-server and percepxion-mcp-server.

Getting started

The collection is available now on Red Hat Automation Hub (certified) and Ansible Galaxy. The repo includes a getting-started guide with complete, runnable playbook examples.

$ansible-galaxy collection install lantronix.oob

• View the repo & docs
• Getting Started Guide

Evaluating the SLC 9000 and Percepxion or planning an SLC 8000 migration before the December 2026 end-of-sale? Test the Ansible collection early. It’s where the out-of-band platform meets the automation stack you already run.

Requirements | The lantronix.oob collection requires Ansible Core 2.17 or later, Python 3.10 or higher, and network access to your SLC 9000 or Percepxion instance. Autonomous Out-of-Band (AOOB) — a dedicated, always-available management plane reaching every device independent of the production network is the foundation the SLC 9000 is built on.