Documentation on Darren Mair

Automating SentinelOne Deployment Across Azure VMs

darren@example.com (Darren Mair) — Wed, 06 May 2026 00:00:00 +0000

This guide walks through how to automate SentinelOne deployment across Azure virtual machines by using the Sentinel_Check_&_Install_v1.ps1 script. The script scans subscriptions, skips excluded workloads, checks existing SentinelOne extensions, optionally repairs failed deployments, resolves secrets from secure runtime sources, and exports a CSV summary for audit and follow-up.

What the script does

At a high level, the script:

Authenticates to Azure with Connect-AzAccount.
Enumerates one or more subscriptions.
Maps each subscription to a SentinelOne site token based on the subscription name.
Filters out excluded regions and VM names.
Checks whether each VM is running.
Detects whether the SentinelOne extension is already installed.
Flags failed extension provisioning states.
Resolves the SentinelOne API key and site tokens from parameters, environment variables, or Azure Key Vault.
Installs or reinstalls the SentinelOne extension where needed.
Writes a CSV report covering every decision the run made.

Before you run it

You need the following in place first:

Requirement	Why it matters
Azure PowerShell modules, especially `Az.Accounts`, `Az.Compute`, and `Az.Resources`	The script relies on `Get-AzSubscription`, `Get-AzVM`, `Get-AzVMExtension`, `Set-AzVMExtension`, and related commands.
Rights to read subscriptions and manage VM extensions	The script installs and removes Azure VM extensions.
SentinelOne console API key	Required by the extension install process and now supplied securely at runtime.
SentinelOne site tokens for each environment	The script picks a token by matching subscription names such as `prod`, `preprod`, `qa`, and `dev`.
A safe test scope	Start with a limited subscription list and `-WhatIf` before broad rollout.

📝 Note

The script no longer requires hard-coded secrets in the file. Supply the SentinelOne API key and site tokens through explicit parameters, environment variables, or Azure Key Vault.

Step 1: Review the parameters

The script exposes operational parameters for VM targeting and secret-resolution parameters for secure execution.

param(
    [string[]] $SubscriptionIds = @(),
    [string[]] $ExcludedLocations = @('ukwest'),
    [string[]] $ExcludedVMNames = @('ufwduks001v', 'ufwduks002v', 'uavsjbtempuks001'),
  [string] $SentinelOneConsoleAPIKey,
  [string] $ProdSiteToken,
  [string] $PreProdSiteToken,
  [string] $QaSiteToken,
  [string] $DevSiteToken,
  [string] $KeyVaultName,
  [string] $KeyVaultSubscriptionId,
    [switch] $AutoStartVMs,
    [switch] $ReinstallFailedExtensions,
    [string] $CsvPath = ".\SentinelCheck_Results_$((Get-Date).ToString('yyyyMMdd_HHmmss')).csv"
)

Use them like this:

Parameter	Purpose
`SubscriptionIds`	Limits the run to specific subscriptions. If empty, the script scans every subscription visible to the signed-in account.
`ExcludedLocations`	Prevents deployment in selected Azure regions.
`ExcludedVMNames`	Skips known exception VMs.
`SentinelOneConsoleAPIKey` and site token parameters	Optional explicit secret inputs for ad hoc runs.
`KeyVaultName`	Enables direct secret lookup from Azure Key Vault.
`KeyVaultSubscriptionId`	Lets the script switch to a different subscription before reading Key Vault secrets.
`AutoStartVMs`	Starts stopped VMs so they can be remediated.
`ReinstallFailedExtensions`	Removes failed SentinelOne extensions and installs a fresh copy.
`CsvPath`	Controls where the execution report is written.

Step 2: Provide secrets securely

The script now resolves secrets in this order:

Explicit parameter values.
Environment variables.
Azure Key Vault secrets.

That means you can use the same script in three common ways without editing the file.

Option A: Environment variables

For automation platforms, environment variables are the simplest integration point:

$env:SENTINELONE_API_KEY = '<secure value>'
$env:S1_SITE_TOKEN_PROD = '<secure value>'
$env:S1_SITE_TOKEN_PREPROD = '<secure value>'
$env:S1_SITE_TOKEN_QA = '<secure value>'
$env:S1_SITE_TOKEN_DEV = '<secure value>'

The script also accepts alternate names such as SENTINELONE_CONSOLE_API_KEY and SENTINELONE_SITE_TOKEN_PROD, but the shorter names above are the cleanest standard.

Option B: Azure Key Vault

If you want the script to resolve secrets directly from Key Vault, provide the vault name and optionally the subscription that hosts the vault:

.\Sentinel_Check_&_Install_v1.ps1 \
  -SubscriptionIds '00000000-0000-0000-0000-000000000000' \
  -KeyVaultName 'kv-sentinelone-prod' \
  -KeyVaultSubscriptionId '11111111-1111-1111-1111-111111111111' \
  -WhatIf

By default, the script looks for these Key Vault secret names:

Secret	Default name
SentinelOne console API key	`sentinelone-console-api-key`
Production site token	`sentinelone-site-token-prod`
Pre-production site token	`sentinelone-site-token-preprod`
QA site token	`sentinelone-site-token-qa`
Development site token	`sentinelone-site-token-dev`

Option C: Explicit parameters

This is useful for a one-off run, but it is the least desirable option for shared automation because secrets can leak into command history or logs.

Step 3: Confirm the subscription-to-token mapping

The script decides which site token to use by checking the subscription name:

function Get-SentinelSiteTokenForSubscription {
    param([string] $SubscriptionName)
    $name = $SubscriptionName.ToLowerInvariant()
    if ($name -match 'preprod') { return $PreProdSiteToken }
    if ($name -match 'prod')    { return $ProdSiteToken }
    if ($name -match 'qa')      { return $QaSiteToken }
    if ($name -match 'dev')     { return $DevSiteToken }
    return $ProdSiteToken
}

This is simple and effective, but only if your Azure subscription naming standard is consistent. Validate that every targeted subscription name contains one of those environment markers. If not, expand the matching rules before rollout.

Step 4: Run a dry run first

Because the script uses SupportsShouldProcess = $true, you can validate scope with -WhatIf.

Example dry run:

$env:SENTINELONE_API_KEY = '<secure value>'
$env:S1_SITE_TOKEN_PROD = '<secure value>'
$env:S1_SITE_TOKEN_PREPROD = '<secure value>'
$env:S1_SITE_TOKEN_QA = '<secure value>'
$env:S1_SITE_TOKEN_DEV = '<secure value>'

.\Sentinel_Check_&_Install_v1.ps1 \
  -SubscriptionIds '00000000-0000-0000-0000-000000000000' \
  -ExcludedLocations 'ukwest' \
  -ExcludedVMNames 'legacy-vm-01' \
  -WhatIf

During this phase, review:

Which subscriptions are discovered.
How many VMs are excluded.
Which VMs are marked WouldInstall.
Whether any subscriptions default to the wrong site token.

Step 5: Understand the VM checks

For each VM, the script performs four important decisions:

Is the VM in scope after location and name exclusions?
Is the VM currently running?
Does a SentinelOne VM extension already exist?
Is the existing extension healthy or failed?

Stopped VMs are not installed by default. They are logged with status VMStopped, and only started when -AutoStartVMs is provided.

Step 6: Install or repair the extension

When the script finds a VM without a SentinelOne extension, it installs the correct extension based on OS type:

OS	Publisher	Extension type
Windows	`SentinelOne.WindowsExtension`	`WindowsExtension`
Linux	`SentinelOne.LinuxExtension`	`LinuxExtension`

If an existing SentinelOne extension is present but the provisioning state is failed, the script can remove and reinstall it when -ReinstallFailedExtensions is enabled.

Example live run:

$env:SENTINELONE_API_KEY = '<secure value>'
$env:S1_SITE_TOKEN_PROD = '<secure value>'
$env:S1_SITE_TOKEN_PREPROD = '<secure value>'
$env:S1_SITE_TOKEN_QA = '<secure value>'
$env:S1_SITE_TOKEN_DEV = '<secure value>'

.\Sentinel_Check_&_Install_v1.ps1 \
  -SubscriptionIds '00000000-0000-0000-0000-000000000000' \
  -ReinstallFailedExtensions \
  -AutoStartVMs \
  -CsvPath '.\reports\sentinelone-deployment.csv'

Step 7: Read the output categories

The CSV report is the operational record of the run. Expect these statuses:

Status	Meaning
`AlreadyInstalled`	SentinelOne extension already exists and does not show failed provisioning.
`ProvisioningFailed`	Existing extension was detected in a failed state.
`Installed`	SentinelOne was installed during the run.
`ReinstalledAfterFailure`	Failed extension was removed and reinstalled successfully.
`WouldInstall`	Dry-run result produced by `-WhatIf`.
`VMStopped`	VM was skipped because it was not running.
`InspectionFailed`	Extension inspection could not complete.
`InstallFailed` or `ReinstallFailed`	Installation or remediation failed and needs follow-up.
`SkippedSubscription`	Subscription processing failed or token mapping could not be resolved.

This report is suitable for service desk handoff, remediation tracking, or import into a workbook.

Step 8: Roll out safely in phases

For a production rollout, use a staged approach:

Run against one non-production subscription with -WhatIf.
Run live in non-production and review the CSV output.
Enable -ReinstallFailedExtensions only after confirming the extension settings are correct.
Expand to production subscriptions in controlled batches.
Keep the exclusion lists under change control so exceptions stay visible.

Step 9: Harden the script before long-term use

The script already has good operational structure, but a few changes would make it safer and easier to maintain:

Keep secrets outside the script and rotate them through Key Vault or pipeline secret stores.
Log to a structured output folder rather than the current working directory.
Make environment mapping explicit in configuration instead of matching on free-text subscription names.
Add transcript logging for change evidence.
Run it from an automation account, pipeline agent, or scheduled management host instead of a workstation.

Recommended operating model

If you want to turn this from an admin script into a repeatable control, use this pattern:

Store API keys and site tokens in Key Vault.
Trigger the script from Azure DevOps or another automation runner.
Pass SubscriptionIds from pipeline variables.
Publish the CSV as a pipeline artifact.
Review failures and stopped VMs as a separate remediation queue.

Final thoughts

This script is a good foundation for bulk SentinelOne deployment because it combines discovery, filtering, secure secret resolution, installation, remediation, and reporting in one flow. The biggest remaining operational concern is governance around subscription naming, rollout control, and evidence capture rather than secret storage in the script itself. Validate token mapping carefully, keep execution scoped, and use -WhatIf plus phased rollout to move from manual installs to controlled automation.

Running SentinelOne Deployment Safely from Azure DevOps

darren@example.com (Darren Mair) — Wed, 06 May 2026 00:00:00 +0000

This companion guide shows how to run the SentinelOne deployment script from Azure DevOps without storing API keys or site tokens in source control. The pipeline pattern below uses secure variables or Azure Key Vault, limits execution scope, publishes the CSV result, and keeps rollout controls explicit.

Architecture at a glance

The production pattern is simple:

Store the SentinelOne API key and site tokens as protected secrets.
Run the PowerShell script from an Azure DevOps pipeline agent.
Pass only the subscription scope and operational switches at runtime.
Publish the generated CSV report as a build artifact.
Review failures, stopped VMs, and exceptions outside the pipeline.

What changed in the script

The deployment script now supports three secret sources, in this order:

Explicit PowerShell parameters.
Environment variables.
Azure Key Vault secrets.

That means the pipeline does not need to edit the script before each run. It only needs to inject the correct values at execution time.

Recommended secret names

If you use environment variables, align with the names the script already resolves:

Secret	Environment variable
SentinelOne console API key	`SENTINELONE_API_KEY`
Production site token	`S1_SITE_TOKEN_PROD`
Pre-production site token	`S1_SITE_TOKEN_PREPROD`
QA site token	`S1_SITE_TOKEN_QA`
Development site token	`S1_SITE_TOKEN_DEV`

If you use Azure Key Vault, the script defaults to these secret names:

Secret	Key Vault secret name
SentinelOne console API key	`sentinelone-console-api-key`
Production site token	`sentinelone-site-token-prod`
Pre-production site token	`sentinelone-site-token-preprod`
QA site token	`sentinelone-site-token-qa`
Development site token	`sentinelone-site-token-dev`

Option 1: Use Azure DevOps secret variables

This is the quickest secure starting point if you are not yet standardised on Key Vault.

Create a variable group with secret variables for:

SENTINELONE_API_KEY
S1_SITE_TOKEN_PROD
S1_SITE_TOKEN_PREPROD
S1_SITE_TOKEN_QA
S1_SITE_TOKEN_DEV

Then reference that group from the pipeline.

Option 2: Use Azure Key Vault

For longer-term operations, Key Vault is the better pattern because it separates secret lifecycle management from the pipeline definition.

In that model:

The pipeline service connection reads secrets from Key Vault.
The pipeline exports those values as environment variables for the script.
The script runs unchanged.

You can also let the script read Key Vault directly by passing -KeyVaultName and, if required, -KeyVaultSubscriptionId. In Azure DevOps, I prefer retrieving secrets in the pipeline first because it keeps the execution contract visible in one place.

Production-ready pipeline example

The YAML below is designed for a manually triggered operational run. It supports dry runs, targeted subscription scope, optional remediation of failed extensions, and CSV artifact publishing.

trigger: none
pr: none

parameters:
  - name: subscriptionIds
    displayName: Subscription IDs
    type: string
    default: ''

  - name: excludedLocations
    displayName: Excluded locations
    type: string
    default: 'ukwest'

  - name: excludedVmNames
    displayName: Excluded VM names
    type: string
    default: 'ufwduks001v,ufwduks002v,uavsjbtempuks001'

  - name: autoStartVMs
    displayName: Auto-start stopped VMs
    type: boolean
    default: false

  - name: reinstallFailedExtensions
    displayName: Reinstall failed extensions
    type: boolean
    default: false

  - name: whatIf
    displayName: Dry run only
    type: boolean
    default: true

variables:
  - group: sentinelone-deployment-secrets
  - name: scriptPath
    value: scripts/Sentinel_Check_&_Install_v1.ps1
  - name: reportPath
    value: $(Build.ArtifactStagingDirectory)/sentinelone/SentinelCheck_Results.csv

pool:
  vmImage: windows-latest

stages:
  - stage: DeploySentinelOne
    displayName: Deploy SentinelOne
    jobs:
      - job: RunDeployment
        displayName: Run deployment script
        steps:
          - checkout: self

          - task: AzurePowerShell@5
            displayName: Run SentinelOne deployment script
            inputs:
              azureSubscription: 'sc-azure-platform-prod'
              ScriptType: InlineScript
              azurePowerShellVersion: LatestVersion
              Inline: |
                $subscriptionIds = @()
                if ('${{ parameters.subscriptionIds }}'.Trim()) {
                  $subscriptionIds = '${{ parameters.subscriptionIds }}'.Split(',').Trim() | Where-Object { $_ }
                }

                $excludedLocations = '${{ parameters.excludedLocations }}'.Split(',').Trim() | Where-Object { $_ }
                $excludedVmNames = '${{ parameters.excludedVmNames }}'.Split(',').Trim() | Where-Object { $_ }

                $scriptArguments = @{
                  SubscriptionIds = $subscriptionIds
                  ExcludedLocations = $excludedLocations
                  ExcludedVMNames = $excludedVmNames
                  CsvPath = '$(reportPath)'
                }

                if ('${{ parameters.autoStartVMs }}' -eq 'true') {
                  $scriptArguments['AutoStartVMs'] = $true
                }

                if ('${{ parameters.reinstallFailedExtensions }}' -eq 'true') {
                  $scriptArguments['ReinstallFailedExtensions'] = $true
                }

                if ('${{ parameters.whatIf }}' -eq 'true') {
                  $scriptArguments['WhatIf'] = $true
                }

                & '$(Build.SourcesDirectory)/$(scriptPath)' @scriptArguments
            env:
              SENTINELONE_API_KEY: $(SENTINELONE_API_KEY)
              S1_SITE_TOKEN_PROD: $(S1_SITE_TOKEN_PROD)
              S1_SITE_TOKEN_PREPROD: $(S1_SITE_TOKEN_PREPROD)
              S1_SITE_TOKEN_QA: $(S1_SITE_TOKEN_QA)
              S1_SITE_TOKEN_DEV: $(S1_SITE_TOKEN_DEV)

          - task: PublishBuildArtifacts@1
            displayName: Publish SentinelOne report
            condition: succeededOrFailed()
            inputs:
              PathtoPublish: $(Build.ArtifactStagingDirectory)/sentinelone
              ArtifactName: sentinelone-report
              publishLocation: Container

Key pipeline decisions

This example deliberately makes a few opinionated choices:

Decision	Reason
`trigger: none`	Deployment should be an intentional operational action, not a CI side effect.
Manual parameters	Operators can narrow scope without editing YAML.
`whatIf` defaults to `true`	Safe by default. Live execution is a conscious change.
`condition: succeededOrFailed()` on artifact publish	You still want the CSV output when some installs fail.
Windows hosted agent	Keeps execution consistent with Azure PowerShell task behavior.

Key Vault-backed variable groups

If you already use Azure Key Vault with Azure DevOps variable groups, the pipeline gets even cleaner. In that setup:

Link the variable group to your Key Vault.
Map the Key Vault secrets to the same variable names used above.
Keep the YAML unchanged.

This avoids duplicating secret values between Azure DevOps and Key Vault.

For a real enterprise rollout, add these controls around the pipeline:

Restrict who can queue the pipeline.
Separate non-production and production service connections.
Use approvals for production stages if you later split the pipeline into environments.
Log the approved subscription list for every execution.
Keep exception VM names and excluded regions under review.

Recommended repository structure

The pipeline is easier to maintain when the repo structure is explicit:

azure-pipelines/
  sentinelone-deployment.yml
scripts/
  Sentinel_Check_&_Install_v1.ps1
docs/
  sentinelone-runbook.md

If the script currently lives outside source control, move it into a controlled repository before putting the pipeline into service. That gives you traceability for every operational change.

Operational runbook flow

The process for an operator should be straightforward:

Queue the pipeline.
Start with a non-production subscription and dry run enabled.
Review the pipeline log and generated CSV.
Re-run live only after the dry-run scope looks correct.
Review failed installs, stopped VMs, and skipped subscriptions separately.

Final thoughts

The safest way to run the SentinelOne deployment script is to treat it like an operational control, not an admin laptop task. Azure DevOps gives you repeatability, approvals, artifacts, and audit history. Combined with the script’s new secret-resolution logic, that gives you a workable production model without putting credentials in the repo.

Azure DevOps Best Practices - End-to-End Guide

darren@example.com (Darren Mair) — Tue, 05 May 2026 00:00:00 +0000

This guide is designed as an implementation playbook, not a theory article.

It combines:

Delivery operating model practices
Azure Boards structure and governance
Git branching and pull request controls
CI/CD architecture in Azure Pipelines
Secure-by-design controls and permissions
Implementation-ready scripts and templates

Who This Is For

Engineering managers and platform leads
DevOps engineers and SRE teams
Security and compliance teams partnering with delivery
Team leads setting standards across multiple repos/projects

How To Use This Guide

Read the operating model and target-state first.
Implement Boards + Repos controls together.
Add pipeline templates and environment checks.
Roll out secure-by-design controls in phases.
Use the scripts and templates section as your starter kit.

Expanded Table of Contents

Reference Sources

This playbook is aligned with current Microsoft documentation, including:

Azure Boards security model and permissions
Azure Repos branch policies and branching guidance
Azure Pipelines security guidance, templates, environments, approvals/checks
Authentication/authorization and security groups guidance
GitHub Advanced Security for Azure DevOps (secret, dependency, code scanning)

Where this guide makes choices (for example, branching model or gate strictness), those choices are opinionated implementation recommendations intended to be practical in enterprise teams.

Build a Blog with Hugo

darren@example.com (Darren Mair) — Tue, 14 Apr 2026 00:00:00 +0000

Introduction

I wanted a simple way to publish blog posts for free, keep everything in GitHub, and avoid turning a personal blog into a full-time maintenance project. Hugo ended up being a good fit, but a lot of the setup guides I found were either too generic or too deep into Hugo internals.

So this is the version I wish I had when I started: a practical guide that gets you from zero to a working Hugo blog hosted on GitHub Pages.

Prerequisites

This guide assumes:

You are on Windows 10 or 11
You are using PowerShell 7
You want your blog source in GitHub
You want a straightforward setup without unnecessary complexity
You are happy using a simple theme like Tailwind
GitHub Account, create one here https://github.com/

TL;DR

If you want the short version, the overall flow looks like this:

Create a GitHub account and a public repo named username.github.io
Clone that repo locally
Install Git, PowerShell 7, Go, and Hugo Extended
Create a Hugo site inside a site folder
Add the Tailwind theme as a Git submodule
Update site/hugo.toml with your details
Create an About page and your first post
Add a GitHub Actions workflow
Push to main
Open https://username.github.io

If you want the full step-by-step version, keep going.

Installation

Install Git

Git is required because the theme will be added as a submodule.

Download: https://git-scm.com/download/win

During install, select:

Use Git from the command line and also from 3rd-party software

Verify:

`1`	`git --version`

Install or verify PowerShell 7

PowerShell 7 avoids the old BOM and encoding problems that can trip Hugo Extended up on Windows.

Download: https://learn.microsoft.com/powershell/

Verify:

`1`	`pwsh --version`

Install Hugo Extended

Download Hugo

`1`	`Invoke-WebRequest -Uri "https://github.com/gohugoio/hugo/releases/download/v0.160.1/hugo_extended_0.160.1_windows-amd64.zip" -OutFile "hugo_extended.zip"`

You can change the version number (0.160.1) with the latest release from Hugo’s Github Releases page.

Extract Hugo

Once the download is complete, run the following command to extract the ZIP file to a directory (e.g., C:\Hugo):

`1`	`Expand-Archive -Path hugo_extended.zip -DestinationPath C:\Hugo`

Add Hugo to System Path

To make Hugo accessible from anywhere in PowerShell, you need to add it to the system’s PATH variable.

Press Windows + X > System > Advanced system settings.
Click **Environment Variables**.
Under System Variables, find Path and click Edit.
Click New, then add the path C:\Hugo where you extracted hugo.exe.

Click OK to save the changes.

Verify Hugo Installation

Now, open PowerShell and run:

`1`	`hugo version`

You should see the installed version of Hugo, confirming that it’s set up correctly.

Create the GitHub Repository

To use GitHub Pages with your personal GitHub domain, create a new public repository named:

username.blogname

Replace username with your actual GitHub username.

For example, if your username is scoobydoo, the repository must be:

scoobydoo.reponame

Clone the Repository and Prepare the Folder Structure

Open PowerShell 7 and run:

cd C:\LocalDevOps
git clone https://github.com/username/reponame.git
cd reponame`
mkdir site

At this point your repository will hold the Hugo site inside a site directory, which keeps the root tidy.

Add a .gitignore

Create a .gitignore file in the repo root with:

# Hugo gitignores
/site/resources/
/site/public/
.hugo_build.lock

Commit and push this early if you want to confirm your repo and local tooling are working.

Create your first Hugo site

Now move into the site folder and create the Hugo project there:

1
2

cd C:\LocalDevOps\repo\site
hugo new site .

You can test the bare site immediately:

`1`	`hugo server`

Hugo will print a local URL, usually:

http://127.0.0.1:1313

Add the Tailwind Theme

One of the reasons this setup is nice is that the Tailwind theme keeps things simple. You are not signing up for a heavy frontend toolchain just to publish a few posts.

From inside site, run:

1
2

git init
git submodule add https://github.com/tomowang/hugo-theme-tailwind.git themes/tailwind

Activate the Theme

Once the theme is downloaded, open the config.toml file in your Hugo project folder:

Add the following line to the file to set the theme:

theme = “tailwind” That should also create a .gitmodules file in the repo root.

It should look roughly like this:

1
2
3

[submodule "site/themes/tailwind"]
	path = site/themes/tailwind
	url = https://github.com/tomowang/hugo-theme-tailwind.git

At this point, if hugo server is already running, Hugo should detect the config and theme changes and rebuild automatically.

Create the About Page and Your First Post

`1`	`hugo new content about/index.md`

Open site/content/about/index.md and replace the default content with your own details.

---
title: About
description: Everything you need to know about this site and its author.
date: 2026-01-26
lastmod: 2026-01-26
menu:
    main: 
        weight: -90
        params:
            icon: user
---

Create a blog post

Create your first post:

`1`	`hugo new content posts/my-first-post/index.md`

Then use front matter like this:

+++
date = '2026-04-15T23:13:41+01:00'
draft = false
title = 'My First Post'
+++

## Title Test
Welcome to my first post on my new Hugo website!

And then add your content below it, for example:

1
2
3

## Blog header

blog text

Each post should live in its own folder with an index.md file. That makes it easy to add images later.

Run Locally While You Write

From the site folder:

`1`	`hugo server`

Open: http://127.0.0.1:1313

What you want to see:

The site loads locally
Theme styling is applied
Your About page is visible
Your first post appears on the homepage
Hugo rebuilds automatically when you save changes

Add GitHub Actions Deployment

Once the blog looks right locally, set GitHub Pages to deploy from Actions.

In your repo:

Go to Settings
Open Pages
Set the source to GitHub Actions

Then create .github/workflows/hugo.yml in the repository root with this workflow:

name: Build and deploy
env:
    FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: "true"
on:
    push:
        branches:
            - main
    workflow_dispatch:
permissions:
    contents: read
    pages: write
    id-token: write
concurrency:
    group: pages
    cancel-in-progress: false
defaults:
    run:
        shell: bash
jobs:
    build:
        runs-on: ubuntu-latest
        env:
            DART_SASS_VERSION: 1.99.0
            GO_VERSION: 1.26.1
            HUGO_VERSION: 0.160.0
            NODE_VERSION: 24.14.1
            TZ: Europe/Oslo
        steps:
            - name: Checkout
                uses: actions/checkout@v6
                with:
                    submodules: recursive
                    fetch-depth: 0
            - name: Setup Go
                uses: actions/setup-go@v6
                with:
                    go-version: ${{ env.GO_VERSION }}
                    cache: false
            - name: Setup Node.js
                uses: actions/setup-node@v6
                with:
                    node-version: ${{ env.NODE_VERSION }}
            - name: Setup Pages
                id: pages
                uses: actions/configure-pages@v6
            - name: Create directory for user-specific executable files
                run: |
                    mkdir -p "${HOME}/.local"
            - name: Install Dart Sass
                run: |
                    curl -sLJO "https://github.com/sass/dart-sass/releases/download/${DART_SASS_VERSION}/dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz"
                    tar -C "${HOME}/.local" -xf "dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz"
                    rm "dart-sass-${DART_SASS_VERSION}-linux-x64.tar.gz"
                    echo "${HOME}/.local/dart-sass" >> "${GITHUB_PATH}"
            - name: Install Hugo
                run: |
                    curl -sLJO "https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
                    mkdir "${HOME}/.local/hugo"
                    tar -C "${HOME}/.local/hugo" -xf "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
                    rm "hugo_extended_${HUGO_VERSION}_linux-amd64.tar.gz"
                    echo "${HOME}/.local/hugo" >> "${GITHUB_PATH}"
            - name: Verify installations
                run: |
                    echo "Dart Sass: $(sass --version)"
                    echo "Go: $(go version)"
                    echo "Hugo: $(hugo version)"
                    echo "Node.js: $(node --version)"
            - name: Install Node.js dependencies
                run: |
                    [[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true
            - name: Configure Git
                run: |
                    git config core.quotepath false
            - name: Cache restore
                id: cache-restore
                uses: actions/cache/restore@v5
                with:
                    path: ${{ runner.temp }}/hugo_cache
                    key: hugo-${{ github.run_id }}
                    restore-keys:
                        hugo-
            - name: Build the site
                run: |
                    hugo build \
                        --gc \
                        --minify \
                        --baseURL "${{ steps.pages.outputs.base_url }}/" \
                        --cacheDir "${{ runner.temp }}/hugo_cache"
            - name: Cache save
                id: cache-save
                uses: actions/cache/save@v5
                with:
                    path: ${{ runner.temp }}/hugo_cache
                    key: ${{ steps.cache-restore.outputs.cache-primary-key }}
            - name: Upload artifact
                uses: actions/upload-pages-artifact@v3
                with:
                    path: ./public
    deploy:
        if: github.ref == 'refs/heads/main'
        environment:
            name: github-pages
            url: ${{ steps.deployment.outputs.page_url }}
        runs-on: ubuntu-latest
        needs: build
        steps:
            - name: Deploy to GitHub Pages
                id: deployment
                uses: actions/deploy-pages@v5

11. Commit, Push, and Publish

From the repo root:

1
2
3

git add .
git commit -m "Initial Hugo blog setup"
git push origin main

Once the workflow completes, your site should be available at:

https://username.github.io/reponame

Verification Checklist

Before sharing or deploying, confirm all of these:

hugo version includes +extended
Hugo is version 0.160 or newer
Get-Command hugo returns one intended binary path
hugo server runs cleanly
The theme is applied locally
The GitHub Actions workflow completes successfully
GitHub Pages is set to deploy from Actions
Your site opens at https://username.github.io

Common Mistakes (And What They Cause)

Mistake	Result
Editing config in Notepad	BOM can break parsing
Using Windows PowerShell 5.1 for file generation	BOM/encoding issues
Installing Hugo with Winget without checking version	Old/incorrect build
Using standard Hugo instead of Extended	SCSS fails
Multiple Hugo binaries in PATH	Version conflicts
Creating the wrong repo name	Your personal GitHub Pages URL will not work as expected
Forgetting to set Pages source to Actions	Workflow runs, but site does not publish
Leaving draft posts as drafts	Content does not show up on the live site

Recommended Tooling

Editor: VS Code
Shell: PowerShell 7
Theme strategy: Git submodules or Hugo modules
Hosting: GitHub Pages via GitHub Actions

Optional Extras

Once the basics are working, the next things you might want to add are:

A custom domain
Better post images
Analytics
Comments
A cleaner About page
A reusable post template
Local development in Docker Compose or GitHub Codespaces

Final Thoughts

Hugo is one of those tools that can scale from a tiny personal blog to a much more involved static site, which is great, but it also means a lot of guides try to teach everything at once.

If all you want is a simple blog that lives in GitHub, deploys for free, and stays easy to manage, this setup is enough to get you there without dragging in a full frontend toolchain.

If you want, I can turn this into a shorter publish-ready version next, or add a matching follow-up post for Docker Compose or GitHub Codespaces.

Documentation on Darren Mair

Automating SentinelOne Deployment Across Azure VMs

What the script does

Before you run it

Step 1: Review the parameters

Step 2: Provide secrets securely

Option A: Environment variables

Option B: Azure Key Vault

Option C: Explicit parameters

Step 3: Confirm the subscription-to-token mapping

Step 4: Run a dry run first

Step 5: Understand the VM checks

Step 6: Install or repair the extension

Step 7: Read the output categories

Step 8: Roll out safely in phases

Step 9: Harden the script before long-term use

Recommended operating model

Final thoughts

Running SentinelOne Deployment Safely from Azure DevOps

Architecture at a glance

What changed in the script

Recommended secret names

Option 1: Use Azure DevOps secret variables

Option 2: Use Azure Key Vault

Production-ready pipeline example

Key pipeline decisions

Key Vault-backed variable groups

Guardrails I recommend in production

Recommended repository structure

Operational runbook flow

Final thoughts

Azure DevOps Best Practices - End-to-End Guide

Who This Is For

How To Use This Guide

Expanded Table of Contents

Reference Sources

Build a Blog with Hugo

Introduction

Prerequisites

TL;DR

Installation

Install Git

Install or verify PowerShell 7

Install Hugo Extended

Download Hugo

Extract Hugo

Add Hugo to System Path

Verify Hugo Installation

Create the GitHub Repository

Clone the Repository and Prepare the Folder Structure

Add a .gitignore

Create your first Hugo site

Add the Tailwind Theme

Activate the Theme

Create the About Page and Your First Post

Create a blog post

Run Locally While You Write

Add GitHub Actions Deployment

11. Commit, Push, and Publish

Verification Checklist

Common Mistakes (And What They Cause)

Recommended Tooling

Optional Extras

Final Thoughts

Happy Blogging!