What is network as code?

What it is

Network as code means you describe your network in text files and let automation apply those files. The text covers devices, links, IP addresses, routes, firewall rules, DNS records, load balancer settings and policies. You store it in a version control system such as Git. The repository becomes the source of truth, not a device console or a spreadsheet.

The code states what you want, not the keystrokes to get there. A declarative file might say a subnet exists with a given range and a firewall rule allows traffic from a named group to a port. The tool compares that intent with what is running and makes the smallest change it can. That is different from a script that logs into a box and types commands in order. It is not the same as network as code.

People sometimes call any automation network as code. The useful definition is stricter. The change is reviewed like software, tested before it runs, applied by a pipeline, and recorded in history. If the console is still where real changes happen, you have automation around the edges, not a code-driven network.

How it works

The usual loop starts with a branch and a pull request. An engineer edits the code, then a reviewer checks the diff. A pipeline runs format checks, syntax checks, policy tests and a plan. The plan shows what will be created, changed or destroyed. Someone with authority approves the apply step. The pipeline calls cloud APIs, controller APIs or device APIs to make the change.

Idempotency matters. Running the same code twice should leave the network in the same state, not add a duplicate rule. Most declarative tools track state so they know what they created. That state file is sensitive and needs locking when more than one person works at once. If two pipelines apply at the same time, you can get a partial change or a conflict.

Drift is the gap between the code and the running network. Someone opens a console and adds a rule. A device fails and comes back with an old config. A cloud provider changes a default. Good setups run a scheduled check that compares intent with reality and reports drift. Decide whether to alert or reconcile automatically for low-risk resources.

Secrets need their own path. Do not put passwords or API keys in the repository. Use a secret manager and let the pipeline fetch short-lived credentials. The pipeline identity should have only the permissions it needs. That limits the blast radius of a bad change.

Why it matters for a business

Changes become reviewable. A reviewer can see the exact rule, route or subnet change before it reaches production. The pull request records who asked, who approved and what the pipeline planned. When someone asks why a route changed six months ago, the commit and approval record answer the question. That is a practical audit trail, not a promise.

Repeatability improves. You can rebuild a lab, a branch office or a disaster recovery environment from the same templates. Names, tags and policy checks stay consistent. New engineers read the code instead of guessing from a console.

Testing happens before the change. You can run policy checks that reject public storage buckets, open management ports or routes that bypass a firewall. You can spin up a small test environment and apply the same code there. This catches mistakes that a console click would hide until an outage.

The trade-off is upfront work. Someone has to own the repository, the pipeline and the review rules. A small team may not need full network as code for every switch. Start where change is frequent and mistakes are costly: cloud networking, firewall policy, DNS or load balancers.

Common mistakes

The first mistake is keeping the console as the real source of truth. If people still make emergency changes by hand and never backfill the code, the repository drifts and trust drops. Decide how emergency changes get recorded. A common rule is to allow the fix, then open a pull request within a set window and reconcile.

The second is treating a pile of scripts as code. A script that runs commands in order can work, but it often fails halfway and leaves a mess. It may not check the current state or be safe to run twice. Use a declarative tool for resources that support it, and keep imperative scripts for narrow tasks with clear checks.

Skipping tests and policy checks is another common problem. A plan is not a test. It shows what will change, not whether the result is allowed. Add checks for naming, tags, open ports, route conflicts and required approvals. Test in a nonproduction environment when the change touches shared routing or security.

Secrets in Git, shared admin credentials and no state locking cause avoidable incidents. So does a giant first release that changes everything at once. Break the work into small changes with a rollback path. For network changes, rollback is often a revert commit and a reapply, but it can take time and may not restore live sessions.

How to get started

Pick one narrow scope with frequent changes. DNS records, a cloud VPC, a set of firewall rules for one application or load balancer settings are good candidates. Write down the current state, import what you can, and set up a repository with a protected main branch. Require a pull request and one reviewer.

Build a pipeline that runs a plan on every pull request and applies only after approval. Keep credentials short-lived and scoped. Add a scheduled drift check. Run it in report mode first so you learn what real drift looks like. Then decide which resources can reconcile automatically.

Move write access in steps. Give the pipeline the only write credential for the chosen scope. Reduce human console access to read-only where you can. That step is where network as code starts to hold. Keep an emergency path with logging and a follow-up review.

Start with templates for common patterns, such as a standard app network or a site subnet plan. Document the review rules and the rollback steps. Train the on-call team on the pipeline, not only the tool. If you need a second opinion on scope or architecture, an option is the Expert architecture session at $450/month, alongside vendor support, internal training or a consultant. Pick the smallest first slice that proves the loop works.

Frequently asked questions