Provisioning Software: Infrastructure vs User Provisioning, and How to Choose

Provisioning software creates and configures things automatically, and the phrase covers two unrelated jobs: infrastructure provisioning, where tools like Terraform, OpenTofu, Pulumi, Ansible and cloud-init create servers and networks, and user provisioning, where identity systems use SCIM to create and remove accounts in your apps.

Search for the term and you get both meanings mixed together, because vendors in each camp use the same word for different work. A platform engineer and an IT administrator can read the same page and come away with opposite ideas about what it sells. The first step in choosing anything is knowing which problem you have. This guide separates the two meanings, explains the tools in each and how they fit together, and ends with a rule for picking, including the honest observation that a managed platform can remove one entire layer of provisioning work from your list.

Table of contents

• Two meanings, one word
• Infrastructure provisioning: declare what should exist
• Configuration and first boot: Ansible and cloud-init
• User provisioning and SCIM
• How to choose provisioning software
• A managed platform removes a layer
• How this fits the rest of the stack
• FAQ

Two meanings, one word

Provisioning simply means preparing something so it is ready to use. What gets prepared decides everything else about the software you need.

Infrastructure provisioning prepares compute. You want a server, a database, a network and a load balancer, and you want them to exist, be configured and be reproducible. The people doing this are developers, DevOps engineers and platform teams. The output is running infrastructure, and the failure mode is a server that nobody can rebuild.

User provisioning, also called identity provisioning, prepares people. A new employee joins, and they need an account in the email system, the ticketing tool, the code host and the design app, each with the right role. When they leave, all of it has to go away promptly. The people doing this are IT and security teams. The output is accounts with correct access, and the failure mode is a former employee who still has admin rights in a tool nobody remembered.

There is a third, rarer usage: provisioning devices, such as enrolling laptops and phones with the right settings and apps. It is closer to the identity meaning in practice. Most searches, and most of the useful tooling, fall into the first two, so that is what this guide covers.

Infrastructure provisioning: declare what should exist

The modern approach is infrastructure as code. You describe the resources you want in text files, keep them in Git, and a tool compares the description to reality and makes the changes. Terraform popularised this with a declarative language called HCL. After its licence change in 2023, an open-source fork called OpenTofu was created under the Linux Foundation, and it is largely compatible for existing configurations. Pulumi does the same job using general-purpose languages like TypeScript and Python, which appeals to teams who would rather write loops and functions than learn a configuration language.

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.small"

  tags = {
    Name = "web-1"
  }
}

The declarative model has a real advantage: running it twice is safe, because the second run sees that nothing needs to change. The tool keeps a state file recording what it created, and that file is the sharp edge. Lose it, corrupt it, or let two people apply at once, and you have a mess, which is why teams store state remotely with locking.

Cloud providers offer their own native tools too, such as AWS CloudFormation, and they integrate deeply with one provider at the price of portability. The Terraform infrastructure as code post and the IaC tools comparison go into the differences, and the AWS IaC guide covers the native side.

Configuration and first boot: Ansible and cloud-init

Creating a server is half the job. Something still has to install packages, write configuration files, create users and start services. That is configuration management, and it is usually the second tool in the chain.

Ansible is the common choice. It connects over SSH, needs no agent on the target, and runs playbooks written in YAML that describe the desired state of a machine.

- hosts: web
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

cloud-init runs earlier and more simply. Most cloud images support it: you pass a small configuration file when the server is created, and on first boot it sets the hostname, adds SSH keys, installs packages and runs commands. It is ideal for getting a machine to the point where Ansible or your application can take over.

#cloud-config
package_update: true
packages:
  - docker.io
users:
  - name: deploy
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... you@laptop
runcmd:
  - systemctl enable --now docker

A typical chain looks like this: Terraform creates the server and passes cloud-init as user data, cloud-init prepares the basics, and Ansible finishes the configuration. Alternatively, bake an image ahead of time with a tool like Packer, so new servers start already configured. Each layer you add is another thing to maintain, which is worth remembering when a simpler option exists.

User provisioning and SCIM

On the identity side, the standard that matters is SCIM, the System for Cross-domain Identity Management, defined in RFC 7643 and RFC 7644. It is a REST API with a defined JSON schema for users and groups, so that an identity provider can create, update and deactivate accounts in any application that implements it, without a custom integration for every pair.

POST /scim/v2/Users
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "[email protected]",
  "name": { "givenName": "Ada", "familyName": "Lovelace" },
  "emails": [{ "value": "[email protected]", "primary": true }],
  "active": true
}

The identity provider, such as Okta or Microsoft Entra ID, is the source of truth. When HR marks someone as joined, the provider pushes a create request to every connected app. When they leave, it sends an update setting active to false, or a delete. The value is offboarding you can trust: no more trawling through forty admin panels.

SCIM only helps if the applications you use support it, and this is where reality bites. Many vendors gate SCIM behind their most expensive plan, which is an entirely legitimate factor in software selection. If you build software that other companies will use, implementing SCIM endpoints is a common enterprise requirement, and one worth planning for. The securing SaaS applications guide covers the surrounding security expectations.

Dedicated user provisioning products layer workflows, approvals and access reviews on top of SCIM, for organisations where compliance is the driver. Small teams can often get by with the SCIM connectors in their identity provider and a checklist.

How to choose provisioning software

Start by naming the object being provisioned. If it is servers, networks and databases, you want infrastructure tooling. If it is accounts and access, you want an identity provider with SCIM. If your answer is both, you are buying two products, and that is fine as long as you know it.

For infrastructure, choose on team skills and target. A team living in one cloud and comfortable with declarative files will be productive with Terraform or OpenTofu. A team of application developers may be happier with Pulumi in a language they already use. Use Ansible or cloud-init for what happens inside the machine. Insist on remote state, code review on every change, and the ability to rebuild from scratch, because a provisioning tool you cannot run from an empty account has not solved the problem.

For identity, choose on the applications you actually use. List them, check which support SCIM and on which plan, and let that decide which provider you need. A provider with beautiful features is no use if your important apps cannot receive its updates.

Then apply the most useful test of all: what is the smallest amount of provisioning that gets the job done? Every tool in this guide exists to manage complexity. The best outcome is sometimes having less of it, and a short list of things you provision is a feature, not a lack of ambition.

A managed platform removes a layer

Here is the part people rarely say. If you are provisioning servers only to run your own web application and its database, then the servers are not the goal. They are a means, and the provisioning stack around them exists to get your code running on a machine that someone patches.

With a managed platform, that entire layer moves to the provider. You do not write Terraform for a virtual machine, a cloud-init file, or an Ansible playbook to install a runtime, because you never touch the machine. You connect a repository, choose a runtime and a plan, and the platform provisions the compute, the routing and the certificate. The database is a managed instance rather than a package you install and back up. Infrastructure as code still has a place for networks, DNS and cloud resources you genuinely need to control, but it stops being the price of shipping a web app.

This is a judgement about scope, not a claim that infrastructure tools are bad. If you run dozens of services, need custom networking, or have compliance rules about where things run, provisioning software earns its place. If you run a handful of apps, ask which layers you are maintaining only because nobody questioned them.

How this fits the rest of the stack

If your provisioning list is mostly servers for a web app and a database, the shortest path is to remove items from it. A service that deploys from a repository, plus a managed Postgres or MySQL instance, replaces a Terraform module, a cloud-init file and a configuration playbook. The RunxBuild hosting calculator shows the service and the database as line items, so you can compare that cost against the time you spend keeping the provisioning stack alive. Create the pieces in the RunxBuild dashboard, read the services introduction for the supported runtimes and the database documentation for the managed side, and keep your Terraform for the parts of your infrastructure that genuinely need it. Environment variables, logs and rollback replace the ad hoc scripts most teams write on top.

Useful related references:

• Terraform and infrastructure as code
• Infrastructure as code tools compared
• AWS infrastructure as code
• Services on RunxBuild

FAQ

What is provisioning software?

It is software that automatically creates and configures resources so they are ready to use. The term covers infrastructure provisioning, where tools create servers and networks from code, and user provisioning, where identity systems create and remove accounts in applications using standards like SCIM.

What is the difference between provisioning and configuration management?

Provisioning creates the resource, such as a server, a network or a user account. Configuration management sets up what runs inside it, such as packages, files and services. Terraform provisions; Ansible configures. In practice teams use both, often with cloud-init handling the first boot.

What is SCIM provisioning?

SCIM is a REST standard for managing user accounts across applications. An identity provider such as Okta or Entra ID sends create, update and deactivate requests to each connected app, so joiners get access automatically and leavers lose it promptly, without manual work in every tool.

Terraform vs Ansible: which should I use?

They solve different problems. Terraform declares and creates infrastructure such as servers, networks and databases, and tracks them in state. Ansible connects to machines and configures software on them. Many teams use Terraform to create servers and Ansible or cloud-init to prepare them.

Do I still need provisioning tools with a managed platform?

Less of them. A managed platform provisions compute, routing, certificates and databases for you, so you do not write code for servers. You may still use infrastructure as code for networks, DNS or other cloud resources outside the platform, and identity provisioning is a separate concern.