Aurelia
Clark

Infrastructure as Code: Provisioning Kiosk Fleets via API

Aurelia Clark

Jan 12, 2026

11 min read

Infrastructure as Code: Provisioning Kiosk Fleets via API

In the modern enterprise, “Manual Provisioning” is a liability.

We have normalized Infrastructure as Code (IaC) for the cloud—using Terraform or Ansible to spin up thousands of servers with a single commit. Yet, when it comes to Physical Endpoint Management, many organizations remain stuck in “ClickOps.” Admins log into a GUI, manually click through wizards, and hope they didn’t miss a checkbox.

For a fleet of 10,000 retail kiosks or logistics tablets, this manual approach guarantees configuration drift, security gaps, and slow rollout times.

It is time to treat your Kiosk Fleet like a Kubernetes Cluster.

This guide details how to leverage the Hexnode API to architect a true IaC pipeline for physical devices. We will move beyond simple automation to build a resilient, audit-ready provisioning system that creates locations, enforces policies, and manages state without a single UI interaction.

Browse the Hexnode Developer Hub
💡 What is Infrastructure as Code (IaC)?

Think of IaC as a “Digital Blueprint” for your devices. Instead of manually clicking buttons in a portal to set up each kiosk, you write a simple text file that describes exactly how you want your devices to look and behave.
Why it matters:

  • Speed: Configure 1,000 kiosks as fast as you can configure one.
  • Consistency: Every device gets the exact same settings—zero human error.
  • History: Since it’s a file, you can see exactly who changed a setting and when.

Why MDM Architects are Abandoning “ClickOps”

Before we dive into the code, let’s look at why the industry is shifting from manual console management (ClickOps) to Infrastructure as Code (IaC).

Feature Manual (ClickOps) IaC (Hexnode API)
Setup Speed 15–30 mins per device < 1 second for the entire fleet
Audit Trail Fragmented system logs Git History (Commit Hash & Author)
Configuration Drift High risk; requires manual audits Auto-detected and self-remediated
Consistency Human error-prone 100% bit-identical across 10,000 sites
Scalability Linear effort (More devices = More work) Exponential (10 devices = 10,000 devices)

The Strategic Shift: Kiosk as Code

The core philosophy is simple: The Source of Truth is Git, not the Console.

Instead of configuring a store location inside the Hexnode portal, you define the store’s “Desired State” in a version-controlled JSON or YAML file.

Our provisioning engine reads this manifest and orchestrates the Hexnode API to enforce this state. If the manifest changes, the fleet updates automatically.

Enterprise Kiosk-as-Code Pipeline
Enterprise Kiosk-as-Code Pipeline

Phase 1: The Architecture & Prerequisites

To build this pipeline, we need a secure bridge between your Code Repository and the Hexnode Infrastructure.
Prerequisites:

  1. Hexnode Enterprise Account with API access.
  2. ervice Account API Key: Do not use a personal admin key. Generate a dedicated API key with scoped permissions (Write: Policies, Write: Groups, Read: Devices).
  3. CI/CD Runner: A secure environment (Jenkins, GitHub Actions, GitLab CI) to execute the Python logic.

Phase 2: The Idempotent Provisioning Engine

In an enterprise environment, scripts must be idempotent. Running the script 100 times should result in the same state as running it once, without creating duplicate groups or errors.

Before running the engine, we must define our Desired State. This is the “Code” in Infrastructure as Code.

1. The Manifest & Environment Setup

Create a file named store_manifest.json. This acts as your configuration file for a specific retail site or fleet branch.

Environment Variables

For security, do not hardcode your credentials. Set the following environment variables on your local machine or within your CI/CD runner (e.g., GitHub Secrets):

HEXNODE_API_KEY: Your secret API Key from the Hexnode Portal.

HEXNODE_PORTAL_URL: Your portal address (e.g., company.hexnodemdm.com).

3. The Provisioning Script

Here is the logic for a robust provision_store.py script:

⚠️ Note on policy management:

For a true IaC workflow, the Policy ID must exist in the Hexnode portal before the script runs. We recommend creating your “Golden Master” Kiosk Policy in the UI once (e.g., PCI-Compliance-Kiosk-v1) and storing its ID in your store_manifest.json. This ensures your automation is connecting verified security profiles rather than creating redundant, unmanaged policies for every site.

The “State File” – Your infrastructure’s memory

In the world of Terraform, State is the source of truth that tracks what you actually deployed. Without a state file, your script is blind to what it did yesterday.
To turn our Python engine into a professional IaC tool, we implement a local_state.json. This file records the mapping between your human-readable manifest and the unique IDs returned by the Hexnode API.

Why State Matters:

  • Speed: The script doesn’t have to query the API to “find” IDs every time; it looks at the local state first.
  • De-provisioning: If you remove a store from your manifest, the state file tells the script exactly which Hexnode Group ID needs to be deleted.
  • Drift Detection: It allows you to compare the Desired State (Manifest) vs. Last Known State (Local) vs. Live Reality (Hexnode API).

How the code evolves:

Phase 3: The Enterprise Strategy (Day 2 Operations)

Writing the script is Step 1. Running it at scale requires a strategy for Governance and Observability.

1. Drift Detection (The “Cron” Job)

The biggest risk in IT is “Shadow Configuration”—a local admin manually changing a policy to troubleshoot an issue and forgetting to revert it.

  • The Fix: Run a “Read-Only” version of your script nightly.
  • The Logic: Fetch the live configuration from Hexnode and compare it against store_manifest.json.
  • The Action: If they differ, trigger a PagerDuty alert or auto-remediate the drift by overwriting the manual change.

2. Security & Secret Management

Never hardcode API keys.

  • Vault Integration: Inject HEXNODE_API_KEY at runtime using HashiCorp Vault, AWS Secrets Manager, or GitHub Secrets.
  • IP Allowlisting: Configure Hexnode to accept API calls only from the static IP of your CI/CD NAT Gateway.

3. Audit & Compliance (SOC 2 / PCI-DSS)

By moving to IaC, you gain a perfect audit trail for free.

  • The “Who”: Git Commit Author.
  • The “When”: Git Commit Timestamp.
  • The “What”: The Git Diff shows exactly which policy was changed.
  • The “Why”: The Pull Request description.

When an auditor asks, “Who changed the Kiosk Lockdown Policy on Tuesday?”, you don’t look at logs; you look at the Git History.

Phase 4: Zero-Touch Enrollment via API

Configuring a group and a policy is only half the battle. The true power of IaC is realized when a device is taken out of the box, powered on, and automatically finds its “Desired State” without an admin ever touching the screen.

Pre-Enrollment Configuration

Instead of waiting for devices to check in, we use the Hexnode API to “Pre-Provision” them. By fetching Apple DEP or Android Zero-Touch profiles via the API, you can map serial numbers to your IaC-created groups before the hardware even leaves the warehouse.

Enterprise Workflow:

  • Code: Define the store in store_manifest.json.
  • API: Script creates the Hexnode Group and Policy mapping.
  • Enrollment: Script triggers a POST /api/v1/enrollment/ request to generate a dynamic enrollment URL or binds the device’s Serial Number to the new Group ID.

The Enrollment API Logic

You can automate the generation of enrollment requests so that store managers receive an automated “Setup” email or SMS the moment your script finishes running.

The Ultimate Guide to Kiosk Management: Everything your business needs to know
Featured Resource

The Ultimate Guide to Kiosk Management: Everything your business needs to know

Ready to scale globally? Access our comprehensive guide on security, compliance, and lifecycle management for enterprise architects.

Download the White Paper!

Conclusion: From Admin to Architect

Transitioning to Infrastructure as Code elevates the role of the Endpoint Administrator. You are no longer a “ticket clicker” but a Platform Architect.

By adopting this Hexnode API-driven workflow, you ensure that 1,000 stores look exactly like 1 store. You eliminate human error, secure your configuration chain, and gain the agility to deploy complex fleets in minutes, not months.

Stop clicking. Start coding.

❓ Frequently Asked Questions (FAQs)

📍 Can I manage MDM using Infrastructure as Code (IaC)?

Yes. By leveraging the Hexnode REST API, IT teams can manage physical device fleets using IaC principles. Instead of manual console configuration, administrators define device groups, policies, and app assignments in code (JSON/YAML) and use scripts to automatically provision and enforce these states across thousands of devices.

📍How do I automate Kiosk provisioning with Python?

You can automate Kiosk provisioning by writing a Python script that interacts with the Hexnode API.
The script should:

    • Create a Device Group for the new location.
    • Assign Policies (Lockdown profiles) to that group.
    • Trigger Enrollment, ensuring that when devices activate, they automatically inherit the code-defined configuration without human intervention.
Share

Aurelia Clark

Fuelled by coffee, curiosity, and a mildly concerning number of open tabs

Resources Image