Environments: dev, staging, and production

One set of configuration files, run against several separate environments, each with its own state and its own settings. That’s the whole idea: the same main.tf or index.ts from the project structure tutorial, applied three times with three different answers to “how big” and “who pays.”

Terraform workspaces

A workspace is an isolated slot of state within the same backend. Every workspace shares the same configuration files.

terraform workspace new staging
terraform workspace new production
terraform workspace list
terraform workspace select staging

Reference the current workspace inside your configuration with terraform.workspace. The data blocks and the biznetgio_neolite_keypair resource are exactly what the quickstart already declared in full - what’s different here is that product_id is no longer products[0]. It’s picked deliberately per workspace, using the real package names from the NEO Lite catalog:

data "biznetgio_neolite_products" "all" {}

locals {
  # Real NEO Lite package names - see /products/neolite for the full pricing table.
  # dev gets the cheapest tier on purpose; staging matches production so it
  # actually catches production-shaped bugs.
  tier_by_workspace = {
    dev        = "XS 1.1" # 1 vCPU / 1 GB - enough to smoke-test a plan/apply cycle
    staging    = "MS 4.2" # 2 vCPU / 4 GB - same tier as production
    production = "MS 4.2"
  }

  matching_products = [
    for p in data.biznetgio_neolite_products.all.products :
    p if p.name == local.tier_by_workspace[terraform.workspace]
  ]

  # Errors at plan time if the name above doesn't match anything on your
  # account, instead of silently falling back to whatever products[0] is.
  selected_product = local.matching_products[0]
}

data "biznetgio_neolite_os_list" "ubuntu" {
  product_id = local.selected_product.product_id
}

resource "biznetgio_neolite_vm" "main" {
  vm_name              = "web-${terraform.workspace}"
  product_id           = local.selected_product.product_id
  select_os            = data.biznetgio_neolite_os_list.ubuntu.oss[0].name
  keypair_id           = biznetgio_neolite_keypair.main.keypair_id
  cycle                = "m"
  ssh_and_console_user = "adminuser"
  console_password     = var.console_password

  # cheap and reversible while testing, real money in production
  pay_with_credit_card = terraform.workspace == "production"
}

Confirm "XS 1.1" and "MS 4.2" against your own account’s catalog output before relying on them - see Step 1 in the catalog overview. select_os still uses oss[0] here since OS lists are usually short and dominated by one obvious choice; apply the same name-filter pattern to it if that’s not true for your account.

Always check which workspace is selected before applying: terraform workspace show. Applying to the wrong workspace is the single most common way people accidentally touch production. Consider wrapping apply in a script or CI job that requires the workspace name as an explicit argument instead of trusting whatever is currently selected.

If dev, staging, and production ever need genuinely different resources (not just different values), workspaces stop being the right tool, since all workspaces share one configuration. At that point, move to a directory per environment (envs/dev, envs/staging, envs/production), each with its own backend configuration and tfvars, all calling the same shared module.

Pulumi stacks

A stack is Pulumi’s native equivalent, and it’s the primitive the quickstart already used without naming it.

pulumi stack init dev
pulumi stack init staging
pulumi stack init production
pulumi stack ls
pulumi stack select staging

Each stack gets its own Pulumi.<stack>.yaml config file and independent state. Set config per stack explicitly with --stack:

pulumi config set --stack dev biznetgio:apiToken <dev-token> --secret
pulumi config set --stack production biznetgio:apiToken <production-token> --secret

Read the current stack’s name inside your program with pulumi.getStack(). keypair and config are exactly what the Pulumi quickstart already declared in full - what’s different here is that productId is no longer products[0]. It’s picked deliberately per stack, using the real package names from the NEO Lite catalog:

import * as pulumi from "@pulumi/pulumi";
import * as biznetgio from "@shirasakaren/biznetgio";

const stack = pulumi.getStack();
const products = biznetgio.neoliteProductsOutput();

// Real NEO Lite package names - see /products/neolite for the full pricing table.
// dev gets the cheapest tier on purpose; staging matches production so it
// actually catches production-shaped bugs.
const tierByStack: Record<string, string> = {
  dev: "XS 1.1", // 1 vCPU / 1 GB - enough to smoke-test a preview/up cycle
  staging: "MS 4.2", // 2 vCPU / 4 GB - same tier as production
  production: "MS 4.2",
};

const productId = products.products.apply((items) => {
  const match = items.find((p) => p.name === tierByStack[stack]);
  if (!match) throw new Error(`no NEO Lite product named '${tierByStack[stack]}' found`);
  return match.productId;
});

const osList = biznetgio.neoliteOsListOutput({ productId: productId });

const vm = new biznetgio.NeoliteVm("main", {
  vmName: `web-${stack}`,
  productId: productId,
  selectOs: osList.oss[0].name,
  keypairId: keypair.keypairId,
  cycle: "m",
  sshAndConsoleUser: "adminuser",
  consolePassword: config.requireSecret("consolePassword"),
  payWithCreditCard: stack === "production",
});

Confirm "XS 1.1" and "MS 4.2" against your own account’s catalog output before relying on them - see Step 1 in the catalog overview. selectOs still uses oss[0] here since OS lists are usually short and dominated by one obvious choice; apply the same name-filter pattern to it if that’s not true for your account.

Same rule as Terraform: check pulumi stack ls (the current one is marked) before pulumi up. Pass --stack <name> explicitly in CI rather than relying on whichever stack was last selected on that runner.

A practical dev/staging/production split

A pattern that works well for these providers specifically:

Environment	`pay_with_credit_card` / `payWithCreditCard`	Product tier	Purpose
dev	`false`	cheapest available	validate plans/previews without a real charge; resource sits `Pending` until paid
staging	`true`	same tier as production	catch real-world behavior before it matters
production	`true`	the real tier	what customers actually use

Read the billing guide for exactly what pay_with_credit_card = false does; it’s the cheapest way to rehearse a whole apply/up cycle before committing real money.

Next steps

State, remote backends, and team collaboration - get each environment’s state off your laptop

Getting Started

Tutorials

Terraform Provider

Pulumi Provider

Guides

About

Environments: dev, staging, and production

Terraform workspaces

Pulumi stacks

A practical dev/staging/production split

Next steps

​Terraform workspaces

​Pulumi stacks

​A practical dev/staging/production split

​Next steps

Terraform workspaces

Pulumi stacks

A practical dev/staging/production split

Next steps