Skip to content

Automation & integration

The work nobody should have to do a second time

Ansible, API integrations, billing and provisioning automation — so one change across forty devices is one command, and two systems tell the same truth.

The problem

One change, forty manual logins

The configuration is changed by hand on each device, and the fortieth one comes out different. Billing does not know which port is live; monitoring does not know a new customer exists; and once a week somebody fills in a spreadsheet by hand to make the two agree.

  • The same change is repeated by hand
  • The systems do not talk to each other
  • There is more than one source of truth
  • A mistake surfaces when the customer calls

What we deliver

The work nobody should have to do a second time

One source of truth

An inventory of devices, addresses and services for the automation to rest on.

Playbooks and templates

A repeated change in one run, with a dry-run mode and a check on the result.

Integration map

Which system sends what to which, in what format and how often.

API contracts

Documented, versioned interfaces — an integration does not fall apart when one side changes.

Configuration backup and diff

Automated export into version control, with an alert on every change.

Failure handling

What happens when an integration fails: retry, queue and an alert to a human.

Architecture

Architecture

  1. 01InventoryOne source of truth
    • phpIPAM
    • Git
    • Inventory
  2. 02TemplateDesired state as code
    • Ansible
    • Terraform
    • Idempotency
  3. 03Dry runThe diff before the change, not after it
    • Check mode
    • Diff alerts
  4. 04ApplyAcross the fleet, in one command
  5. 05IntegrateThe systems talk through a contract
    • REST API
    • Webhooks
    • RADIUS
  6. 06VerifyResult, retry and an alert
    • Auto-discovery
    • Telegram
One change, one run — from inventory through to verification

Operator consoles

Operator consoles

These exact systems run on the group's own infrastructure — the screenshots are processed before publication.

Blurred ros-backup dashboard showing device coverage, backup success rate and a fleet table broken down by company.

ros-backup — the configuration archive, collected on its own

A device's configuration is the one file whose loss is measured in hours of downtime. ros-backup collects it every day over SSH — MikroTik RouterOS, Juniper JunOS, Cisco IOS and Arista EOS — and keeps it in a git repository, versioned, with a line-by-line diff between any two. No engineer signs in to each device to copy a config by hand: any router's configuration from any day is two clicks away — including when the device itself will no longer power on. We wrote this one ourselves too.

in-houseRouterOS / JunOS / IOS / EOSgit-versioneddaily over SSH
The Semaphore Schedule page: four enabled jobs with their names, cron expressions and the playbook each one runs.

Ansible on a schedule — the Semaphore scheduler

Ansible playbooks here are not scripts someone ran once — they are jobs on a schedule: latency checks against cloud VPS instances, a DNS server check, a reporter run from TVG, a weekly VPS job. Each has its own cron expression and its own playbook, and each produces the same result every time, because a playbook describes the state it wants rather than the steps to get there.

AnsibleSemaphorecronplaybooks

Capabilities

Capabilities

Every item is marked: verified production experience, or engineering capability.

Provisioning at API level

Proven

In the group's hosting the customer creates the server themselves — plan, balance, creation — with no operator involved.

  • REST API
  • cloud-init
  • Templates

Billing wired into the network

Proven

Subscriber, plan and service management connected to network provisioning and AAA.

  • RADIUS
  • PostgreSQL
  • REST API

Automated configuration export

Proven

Device configuration in version control, with an alert when it changes.

  • Git
  • Automated export
  • Diff alerts

Notifications and ChatOps

Proven

Alerts and operational events in the channel the on-call engineer actually watches.

  • Telegram
  • Webhooks
  • Grafana Alerts

Ansible across the fleet

Capability
  • Ansible
  • Inventory
  • Idempotency

Infrastructure as code

Capability
  • Terraform
  • GitOps
  • CI

Automatic onboarding into monitoring

Capability

A new device or service appears in monitoring straight from the inventory, rather than by hand.

  • Auto-discovery
  • Zabbix API
  • Prometheus SD

IPAM integration

Capability

Address allocation and release become part of the process instead of a step someone has to remember.

  • phpIPAM
  • REST API
  • Webhooks

Process

Process

  1. 01

    Inventory

    What exists, and where it is written down today.

  2. 02

    Priorities

    Which manual work costs the most.

  3. 03

    First automation

    One scenario, with a dry run and a check.

  4. 04

    Integration

    The systems talk to each other through a contract.

  5. 05

    Observe

    Failures are visible and retries are logged.

  6. 06

    Handover

    Code, documentation and training for the team.

Technology stack

Technology stack

Automation
AnsibleTerraformcloud-initCron
Integration
REST APIWebhooksMessage queueCSV/JSON
Sources of truth
phpIPAMPostgreSQLGit
Network
MikroTik APINETCONFSSHRADIUS
Notification
TelegramGrafana AlertsSMTP

Engagement model

Engagement model

Project

A one-off scope: audit, migration or implementation with a fixed outcome.

Retainer

Monthly engineering hours — specialist access on demand.

Co-managed

NetWizard and your in-house team together, with split responsibility.

Use cases

Use cases

One change across the whole fleet

NTP, syslog or an access list has to change on forty devices. We write the playbook with a dry run and a result check — the change is one run, and it leaves a trail.

Billing and the network agree

A new subscriber is created in billing and network access is written at the same moment — the manual spreadsheet disappears.

Monitoring lags behind the infrastructure

New services appear and get added to monitoring by hand — or not at all. We connect it to the inventory so onboarding happens by itself.

FAQ

FAQ

Where do we start?

With the one task that repeats most often and goes wrong most often. The first result shows up in weeks rather than months.

Isn't automation risky?

The risky thing is manual work — it quietly differs on every repetition. Our playbooks are idempotent, have a dry-run mode and check the result; before running at scale they are proven in the lab.

Will you work with our existing systems?

Yes. Integration normally happens with the systems you already have — billing, monitoring, ticketing, IPAM. Where there is no API, we look at what interface does exist and write an adapter.

Tell us about your infrastructure