Skip to main content

Published · Updated

Device provisioning across application, identity and VPN systems

I built the central provisioning application in Laravel 11. It ties together device records, Authentik, WireGuard configuration, the reverse-proxy layer and the Bash scripts that set up the device, for registration batches of around 2,000–3,000 devices. This note is mostly about one decision: which system owns which piece of device state.

  • Laravel
  • device provisioning
  • WireGuard
  • Authentik
  • Redis
  • REST API
  • automation

One owner for each piece of state

Registration takes single serial numbers and ranges, and the same workflow has to create the identity and network configuration the device needs during setup.

Each of those pieces has one owner. Laravel holds the device record and the business rules, Authentik handles identity and access, WireGuard with wg-portal covers VPN configuration, Nginx Proxy Manager covers the proxy, and the setup scripts only apply changes on the device. None of the components keeps its own copy of the device state.

The workflow in Laravel

The application uses PostgreSQL for data and Redis queues for work that shouldn’t block an administrator’s request. Laravel Horizon shows how the queue is progressing and which jobs failed. Administrative actions go through Laravel Policies, and access is protected with TOTP MFA and recovery codes.

An administrator can paste a mixed, comma-separated list of single serial numbers and ranges, for example E000001-E000230. The application deduplicates it into one list for the administrator to approve. It then generates the WireGuard configuration, and the Bash scripts on the device fetch it through a REST API, which is the only interface for device-side automation.

  • Single serial numbers and ranges in one input, deduplicated before approval.
  • Administrative actions controlled by Laravel Policies, with TOTP MFA.
  • Queues for work that doesn’t need to block the request, visible in Horizon.
  • One REST API as the interface for device-side automation.

Scope and limits

The flow handles single devices and ranges in batches of a few thousand. My part ended in March 2025. I don’t have before-and-after measurements and I don’t know how many devices run on the system today, so apart from the batch size I don’t give numbers.

Related project

Related case study: