Skip to content
ren
back to the quest log
BiznetGIO provider documentation introduction with managed service coverage and repositories
legendary⌘ developer toolinglive

BiznetGIO IaC Providers

One cloud API, two native workflows

Community Terraform and Pulumi providers that manage BiznetGIO compute, GPU, bare metal, and object storage through one documented resource model.

role
Provider and documentation author
org
Independent open source
when
2026

What it is

This project turns the BiznetGIO Portal API into infrastructure that can be reviewed, versioned, and reproduced. The Terraform provider uses the Plugin Framework; the Pulumi provider exposes the same surface through native SDKs.

Across five service families, the providers expose twenty resources and nineteen catalog data sources or functions. Separate example repositories exercise complete stacks, not isolated snippets.

A bilingual documentation site connects quickstarts, authentication, importing, billing behavior, every resource, eight progressive tutorials, registry packages, and the actual example code.

where the effort went

  • API design92
  • Correctness90
  • Documentation96
  • Developer UX88

the numbers

Resources
20
Data sources
19
Product families
5
Pulumi SDKs
5

built with

  • Go
  • Terraform Plugin Framework
  • Pulumi
  • HCL
  • TypeScript
  • Python
  • .NET
  • Java
  • Mintlify
  • GitHub Actions

delivery record

What I made

BiznetGIO users had a portal API but no consistent Terraform or Pulumi path for repeatable environments. I wanted local cloud infrastructure to fit the same review and deployment workflows as larger providers.

  • 01

    Terraform provider on the official Plugin Framework

  • 02

    Pulumi native provider with TypeScript, Python, Go, .NET, and Java SDKs

  • 03

    Twenty resources across VPS, bare metal, GPU, and object storage

  • 04

    Nineteen catalog data sources and functions

  • 05

    Runnable Terraform and Pulumi example repositories

  • 06

    English and Indonesian documentation with eight end-to-end tutorials

  • 07

    Registry packaging, CI workflows, import guidance, and contribution paths

Hard problems

The constraints mattered as much as the finished interface.

01field note

Matching two infrastructure ecosystems

problem
Terraform schemas and Pulumi native SDK generation have different lifecycle, naming, and output conventions.
response
I defined a shared service vocabulary, kept resources aligned by product family, and documented equivalent examples side by side.

Result: Users can choose state-driven Terraform or language-native Pulumi without learning a different cloud model.

02field note

Turning orders into stable resources

problem
Cloud ordering APIs expose asynchronous provisioning, billing effects, and catalog identifiers that do not naturally look like declarative state.
response
Provider resources separate catalog discovery from creation, poll lifecycle transitions, preserve importable identifiers, and call out paid operations before examples run.
03field note

Documentation across five repositories

problem
Provider code, generated SDKs, examples, and tutorials can drift independently.
response
The docs link every managed surface to runnable examples and registries, while contributor guides define the update path for both providers.

Screens

after shipping

What stayed with me

  • An infrastructure provider is a state machine and a compatibility promise, not a thin REST client.

  • Examples should cover a complete environment because lifecycle errors appear between resources, not inside a single snippet.