What is Infrastructure as Code?

New to managing servers with code? This page explains the whole idea from scratch: what Infrastructure as Code (IaC) is, why it beats clicking around in a portal, how Terraform and Pulumi work, and how to pick between them. No prior experience needed.

The problem IaC solves

Without IaC, you provision cloud resources by hand: open a portal, click through forms to order a VPS, wait, repeat for every server, every disk, every keypair. It works, but:

No record. Nothing captures what you clicked last time, so recreating an environment means doing it all again from memory.
No review. Typos and wrong settings are easy to miss, and nothing is checked before it goes live.
No repeatability. Two environments drift apart because they were built by hand at different times.
No automation. Every change needs a human sitting at a browser.

Infrastructure as Code fixes all four by describing your infrastructure in files that tools read and apply, the same way application code describes software.

Think of it like a recipe instead of cooking from memory. The recipe file is checked into git, anyone can read it, and everyone who follows it gets the same dish.

The core ideas

Every IaC tool shares a small set of concepts:

Concept	What it means	Biznet GIO example
Resource	One thing you want to exist	A NEO Lite VM, a keypair, an object storage bucket
Provider	The plugin that talks to a specific cloud	`biznetgio`, which wraps the Biznet GIO Portal API
State	The tool’s memory of what it already created	Which VM belongs to which keypair, and their real ids
Declarative	You describe the destination, not the journey	”A VM with Ubuntu 22.04”, not “POST here, then poll there”

The workflow is always the same three steps:

Write configuration files that describe what you want.
Plan (Terraform) or preview (Pulumi): the tool compares your files against reality and shows what it would change.
Apply: the tool calls the cloud API to make reality match your files, and records the result in state.

How the tools actually work

The three step workflow above is the surface. Underneath, Terraform and Pulumi both work the same way, built from three moving parts. The provider is a separate program. biznetgio is not baked into Terraform or Pulumi. It is its own compiled binary (terraform-provider-biznetgio / pulumi-resource-biznetgio) that the CLI downloads once and then launches as a subprocess every time you run a command. Your .tf files or your TypeScript program never call the Biznet GIO API directly - they describe a resource, and the CLI sends that description to the provider process over a local RPC connection. The provider is the only thing that speaks HTTP to api.portal.biznetgio.com. This is why the same provider works from Terraform’s HCL and, in Pulumi’s case, from five different programming languages: the language only has to produce the same RPC calls, not implement the API client itself. Everything you declare becomes a graph, not a list. When your configuration says a VM’s keypair_id comes from a keypair resource, the tool records that as an edge: keypair before VM. Spread across a whole file, this turns into a dependency graph, and the CLI walks it to decide order - creating a keypair before the VM that needs its id, and reversing the order on destroy/down so the VM is removed before the keypair it depended on. Resources with no relationship to each other create in parallel, which is why a plan with ten unrelated VMs finishes far faster than ten sequential API calls would.

biznetgio_neolite_keypair.main ──┐
                                 ├──▶ biznetgio_neolite_vm.main
data.biznetgio_neolite_products ─┘

destroy order: reverse the arrows

State is what turns “run twice” into “converge”, not “duplicate”. After every apply/up, the tool writes down the ids and attribute values it now knows about into a state file (Terraform) or a stack’s state (Pulumi). The next time you run a plan or preview, three things get compared side by side: your configuration (what you want), the last known state (what the tool remembers creating), and a fresh read from the real API (what is actually there right now, called a refresh). The diff between those three is exactly what becomes your plan. This is also why changing one field rarely means destroy and recreate - if only label changed on a bare metal server, the provider’s diff logic calls the one API endpoint that renames it, and every other field is left alone. Full replacement only happens for attributes explicitly marked create-only in a resource’s reference page, because the upstream API has no in-place way to change them.

This is the mechanical reason two rules from the FAQ exist: secrets returned only once at creation (keypair private keys, object storage secret keys) survive in state precisely because state is the tool’s only persistent memory of them, and a Pulumi update that times out is safe to retry because the partial state it already wrote lets the next run continue instead of starting over.

What is Terraform?

Terraform is an IaC tool from HashiCorp that uses its own configuration language, HCL. You write .tf files, run terraform plan to see changes, then terraform apply to make them.

Language: HCL, a purpose-built declarative language (not general purpose code)
State: stored in a state file, often shared with a team via a remote backend
Ecosystem: the Terraform Registry hosts thousands of providers, including this one
Best fit: teams that want one standard tool with the same workflow everywhere

resource "biznetgio_neolite_vm" "web" {
  vm_name  = "web-1"
  # ... product, OS, keypair, billing settings
}

What is Pulumi?

Pulumi is an IaC tool that lets you write infrastructure in general purpose programming languages: TypeScript, Python, Go, C#, and Java. It also has a declarative YAML mode for when you want Terraform-style config without a full SDK - see the Pulumi quickstart for a YAML example next to the five language ones.

Language: your language, with loops, functions, and types from day one
State: stored on the Pulumi Cloud service (or a self-hosted backend)
Ecosystem: the Pulumi Registry indexes packages, including this one
Best fit: teams that want to share code, use abstractions, and write unit tests for their infrastructure

const vm = new biznetgio.NeoliteVm("web", {
  vmName: "web-1",
  // ... product, OS, keypair, billing settings
});

Terraform vs Pulumi

	Terraform	Pulumi
Language	HCL (declarative DSL)	TypeScript, Python, Go, C#, Java, or declarative YAML
Preview command	`terraform plan`	`pulumi preview`
Apply command	`terraform apply`	`pulumi up`
State	file or backend	Pulumi Cloud or self-hosted
Community	larger for HCL examples	stronger for code-first teams
This provider	terraform-provider-biznetgio	pulumi-biznetgio

How to choose: if your team already writes a lot of Python, Go, or TypeScript, Pulumi fits naturally. If you prefer a minimal language built only for infrastructure, or your company standardizes on HCL, pick Terraform. Both providers here expose the same Biznet GIO resources, so you can switch tools without changing what you can manage.

How the Biznet GIO providers fit in

Both providers wrap the same Biznet GIO Portal API. That means:

You order real services (VPS, bare metal, GPU, storage) through the same API the web portal uses.
You authenticate with an API token from the portal. See Authentication.
Creates and upgrades place real paid orders. Read the billing guide before your first apply.

Glossary

Term	One-line meaning
IaC	Infrastructure as Code: describing servers and services in files
HCL	HashiCorp Configuration Language, the Terraform language
Provider	Plugin that translates your config into API calls for one cloud
Resource	One thing under management (VM, keypair, bucket)
Data source	Read-only lookup (product catalogs, OS lists)
State	The tool’s record of what it manages and the real ids it knows
Plan / Preview	The before-applying diff between files and reality
Apply / Up	The step that makes the API changes for real
Drift	Reality changed outside the tool; the next plan shows it

Next steps

Quickstart (Terraform) - order your first VM in about five minutes
Quickstart (Pulumi) - same, with Pulumi
Authentication - get an API token
Package registries - every place these providers are published

Getting Started

Tutorials

Terraform Provider

Pulumi Provider

Guides

About

The problem IaC solves

The core ideas

How the tools actually work

What is Terraform?

What is Pulumi?

Terraform vs Pulumi

How the Biznet GIO providers fit in

Glossary

Next steps

​The problem IaC solves

​The core ideas

​How the tools actually work

​What is Terraform?

​What is Pulumi?

​Terraform vs Pulumi

​How the Biznet GIO providers fit in

​Glossary

​Next steps

The problem IaC solves

The core ideas

How the tools actually work

What is Terraform?

What is Pulumi?

Terraform vs Pulumi

How the Biznet GIO providers fit in

Glossary

Next steps