AUTOLINX · FEATURES · PROVISIONING Intent in. Vendor-correct config out. Across 10+ vendors. See pricing →
AutoLinx / Features / Provisioning
AUTOLINX FEATURE · 02 PROVISIONING

Describe a change once.
Ship vendor-correct config everywhere.

AutoLinx Provisioning translates your intent into vendor-correct configuration — Cisco, Juniper, Arista, Huawei, Nokia, MikroTik, and more — then stages it for engineer approval before push. Every change carries a tested rollback. Production-proven across 3 phases at a tier-1 Thai telco since 2019.

See pricing → How it works
INTENT → VENDOR SYNTAX · PARALLEL FAN-OUT
$ intent set BGP keepalive to 3/9 on edge routers α TRANSLATING 5 vendor families Cisco timers bgp 3 9 ✓ Juniper set protocols hold-time 9 ✓ Arista router bgp timers 3 9 ✓ Huawei bgp 65001 keepalive 3 ✓ Nokia configure keepalive 3 ✓ + 5 MORE VENDORS ✓ 247 routers · 5 vendors · 1 intent · audit signed
parallel execution · approval-gated · rollback ready ~ 6 seconds end to end
WHAT IT DOES

Three capabilities that production NetOps needs.

Provisioning isn't just "push config". It's intent translation + blast radius + rollback — the things that make production change safe.

Intent → vendor syntax

10+ vendors · one grammar · zero porting

Engineers describe a change once in declarative intent. AutoLinx emits Cisco IOS-XE, Juniper Junos, Arista EOS, Huawei VRP, Nokia SR — vendor-correct config for every device in scope. No more porting playbooks across vendors.

Pre-flight blast radius

simulate before push · know what breaks

Before any push, AutoLinx simulates the change against the live topology graph — what BGP sessions reset, what traffic re-routes, which downstream devices flap. Engineers see the consequences before approving. No surprise outages.

Tested rollback · always

100% of changes carry a rollback path

Every approved change is paired with a tested rollback before push. If post-push monitoring detects drift from expected state, AutoLinx surfaces the rollback for one-click revert. No "what was the previous config?" archaeology.

HOW IT WORKS

Five stages from intent to approved push.

Engineer-approved by default. Reversible by design. Every step traceable in the audit ledger.
01 · INTENT Express change declarative YAML scope + change no syntax 02 · TRANSLATE Emit per vendor 10+ vendors native syntax role-aware 03 · SIMULATE Blast radius BGP impact traffic shift downstream effect 04 · APPROVE Engineer gate diff + evidence rollback ready ↵ approve · ✕ reject 05 · APPLY Push + verify parallel push post-state check auto-rollback if drift 5 STAGES · ENGINEER GATE AT STAGE 04 · FULL AUDIT TRAIL EVERY ACTION SIGNED IN AUDIT LEDGER · REPLAYABLE
WHERE IT SHIPS

Production proof.

Provisioning has the longest production history of any AutoLinx capability. Three phases at a tier-1 Thai telco, plus government rollouts and Laos national telco automation.
ANCHOR 01 · TIER-1 THAI TELCO
AutoProvision Phase #1 → #3
2019 → 2020 → 2026 · 7 years of phases

The provisioning engine deployed at the tier-1 Thai telco — three phases of continuous evolution. Phase #1 (2019) automated routine config tasks. Phase #2 (2020) added orchestration. Phase #3 (2026) brings our AI reasoning layer into the loop for intent translation.

ANCHOR 01 · TIER-1 THAI TELCO
VLL Migration · 5G Cutover
2020 · single carrier-scale rollout

Provisioning handled the 5G VLL migration — a multi-thousand-device cutover where rollback had to be tested per region. Engineer-approved per region, parallel execution within region, full audit trail across the program.

ANCHOR 03 · LAOS GOVERNMENT MINISTRY
216 branch router rollout
2023 · government-grade deployment

216 branch routers provisioned with multi-ISP load balancing — same intent template, vendor-correct config generated per branch. Government audit-ready from day one. No site-by-site config drift.

ANCHOR 02 · LAOS NATIONAL TELCO
BPI · Broadband Provisioning Intelligent
2024 · subscriber-edge automation

Subscriber-edge provisioning across the broadband network — from order ticket to running service. Bridges automation between OSS systems and the network itself. The first "intelligent" provisioning product before the AI reasoning layer landed.

VENDOR COVERAGE

10+ vendor families · one intent grammar.

Same intent, different syntax. Provisioning emits native config per vendor — we don't normalize through a lowest-common-denominator API.
Cisco IOS-XE
✓ GA
Cisco NX-OS
✓ GA
Juniper Junos
✓ GA
Arista EOS
✓ GA
Nokia SR Linux
✓ GA
Huawei VRP
✓ GA
MikroTik
✓ GA
SONiC
✓ GA
Aruba CX
✓ GA
FRR / VyOS
✓ GA
HUMAN-IN-THE-LOOP

Provisioning is engineer-approved by default.

Pre-flight checks run auto. Translation runs auto. The push itself never happens without explicit approval — except in opt-in classes you explicitly enable.
L1 · TRANSLATE Convert intent to vendor syntax · validate against role definitions auto
L2 · SIMULATE Pre-flight blast radius · BGP impact · downstream effect · build rollback auto
L3 · LOW-RISK PUSH VLAN naming · interface description · banner text · cosmetic config opt-in auto
L4 · APPLY All production-affecting changes · routing · firewall · QoS · ACL approval
L5 · STRATEGIC Topology changes · vendor migrations · multi-region cutovers multi-approval
QUESTIONS

What people ask first.

How is this different from Ansible / Nornir / NAPALM?
Ansible / Nornir execute playbooks you wrote. AutoLinx reasons about what to do from a declarative intent, generates the playbook, simulates blast radius, builds a rollback, and stages it for approval. We integrate with both — AutoLinx can call existing Ansible playbooks as actions, and writes Git diffs into your repo so the audit trail is consistent.
What if the AI generates wrong config?
Two safeguards. First, every push requires engineer approval by default — wrong config doesn't reach the network unless a human approves it. Second, every change has a tested rollback path. We're not optimistic about AI getting it right 100% of the time; we're systematic about catching the 1% that don't.
Can we add support for a vendor not on your list?
Yes — our Adapter SDK lets you build a vendor driver in ~200 lines of code. For Enterprise and Carrier-grade plans, our solutions team writes the driver for you at no additional cost. Anchor 02 (Laos national telco) shipped with three custom adapters this way.
Does it work with our existing Git workflow?
Yes. AutoLinx writes every approved change as a Git commit in your config-as-code repo — GitHub, GitLab, Gitea. The commit message includes intent, diff, blast radius, approver, and rollback ID. Your existing PR workflow can be the approval gate for AutoLinx.
How fast can it provision at scale?
Parallel by design. The 216-branch government rollout (Anchor 03) provisioned 50 sites concurrently with per-region staging. At carrier scale, AutoLinx has provisioned 1,000+ devices in a single approved window. For changes that need to fan out faster than network APIs allow, pair with FabricLinx.
What credentials does Provisioning need?
Read-write credentials, scoped to AutoLinx as a dedicated service account. We recommend separating discovery credentials (read-only) from provisioning credentials (read-write). Vault integration (HashiCorp, CyberArk) for rotation. Customer-managed keys on Carrier-grade plans.
SISTER FEATURES

Provisioning is one capability. Here's how it fits the platform.

Discovery feeds provisioning the topology. Resource Management feeds it inventory. Compliance verifies the result.
FEATURE 01

Discovery

Live graph of every device, neighbor, role. Discovery tells provisioning what's there.
Read →
FEATURE 03

Resource Management

Live IP / VLAN / interface / ASN inventory. Provisioning consumes free resources from here.
Read →
FEATURE 04

Compliance Audit

Every provisioning change auto-checked against compliance policy before approval.
Read →

Ship your first AutoLinx-provisioned change in week three.

A 4-week pilot lets you describe a change, see vendor-correct config emitted, review blast radius, approve, and push — on a 100-device slice of your real network.

See pricing → Read product overview