> ## Documentation Index
> Fetch the complete documentation index at: https://biznetgio.creations.ren/llms.txt
> Use this file to discover all available pages before exploring further.

# What is Infrastructure as Code?

> A beginner-friendly introduction to IaC, Terraform, and Pulumi

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.

<Info>
  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.
</Info>

## 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:

1. **Write** configuration files that describe what you want.
2. **Plan** (Terraform) or **preview** (Pulumi): the tool compares your files against reality and shows what it would change.
3. **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.

<Info>
  This is the mechanical reason two rules from the [FAQ](/guides/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.
</Info>

## What is Terraform?

[Terraform](https://developer.hashicorp.com/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](https://registry.terraform.io) hosts thousands of providers, including [this one](https://registry.terraform.io/providers/shirasakaren/biznetgio)
* **Best fit**: teams that want one standard tool with the same workflow everywhere

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

## What is Pulumi?

[Pulumi](https://www.pulumi.com) 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](/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](https://www.pulumi.com/registry) indexes packages, including [this one](https://www.pulumi.com/registry/packages/biznetgio)
* **Best fit**: teams that want to share code, use abstractions, and write unit tests for their infrastructure

```typescript theme={null}
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](https://github.com/shirasakaren/terraform-provider-biznetgio) | [pulumi-biznetgio](https://github.com/shirasakaren/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](https://api.portal.biznetgio.com/v1/docs). 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](https://portal.biznetgio.com). See [Authentication](/authentication).
* Creates and upgrades place real paid orders. Read the [billing guide](/guides/billing) 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)](/quickstart) - order your first VM in about five minutes
* [Quickstart (Pulumi)](/pulumi-quickstart) - same, with Pulumi
* [Authentication](/authentication) - get an API token
* [Package registries](/registries) - every place these providers are published


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.