DEV Community: Ali Shaikh

Secure Self-Hosted OpenClaw AI Assistant: Step-by-Step Proxmox Template Guide with Tailscale Integration

Ali Shaikh — Sun, 01 Feb 2026 16:15:50 +0000

For the last few weeks, you could not escape seeing "Clawd" everywhere - the viral AI assistant that went from zero to 100,000 GitHub stars in just two months. Originally called Clawdbot, now rebranded as OpenClaw, it's an open-source AI that actually does things instead of just chatting. So this weekend, I set it up on my Proxmox homelab.

Now I have a digital assistant that I can communicate with through WhatsApp and Telegram. I asked it to choose its own name and persona, and now it is called Lyra. I gave it a dedicated email and GitHub account.

This guide walks through creating a reusable Proxmox template with all dependencies pre-installed. Clone the template, boot it, configure OpenClaw and Tailscale, and you're done.

What you get:

Debian 13 VM template with Node.js 24, OpenClaw CLI, and Tailscale pre-installed
Automatic installation via cloud-init (no manual package installs)
Secure HTTPS access via Tailscale Serve (no public exposure)
Progress indicators and status helpers baked in
~15 minutes from template creation to running AI assistant

GitHub: OpenClaw Proxmox Template Script

What is OpenClaw?

OpenClaw is an autonomous AI assistant that actually executes tasks:

Controls browsers (fill forms, scrape data, automate workflows)
Manages files on your system
Integrates with WhatsApp, Telegram, Discord
Runs terminal commands
All through a web UI or chat interfaces

Think of it as the plumbing layer that connects AI models (Claude, GPT-4o, Gemini) to real-world actions.

The catch: It's powerful, which means it needs proper isolation. Hence the dedicated VM approach.

Architecture

Your Browser
    │
    │ HTTPS (Tailscale Serve)
    ▼
OpenClaw VM (Proxmox)
    │
    ├─ Tailscale Serve → http://127.0.0.1:18789
    │
    ├─ OpenClaw Gateway
    │ ├─ Control UI
    │ └─ AI agent + channels
    │
    └─ Internet (outbound only)
        └─ WhatsApp/Telegram/AI APIs

Key design:

Gateway binds to loopback (127.0.0.1) only
Tailscale Serve proxies HTTPS from your Tailnet
No public exposure, no firewall rules needed
Messaging platforms connect over regular internet
If using Tailscale, the server is only accessible through your Tailscale network, ensuring secure, private access

Prerequisites

You'll need:

Proxmox VE 8.x (ensure it's updated: apt update && apt full-upgrade via SSH or web console)
At least 4GB RAM and 20GB storage available per VM (adjust based on workload)
SSH access to Proxmox (or use the web console as a fallback)
A Tailscale account (free tier works)
Your SSH public key
Cloud-init enabled in Proxmox (check under Datacenter > Options; if not, enable it)

Quick Tip: If you're new to Tailscale, start with their quickstart guide: Tailscale Docs.

Part 1: Create the Template

Download the Script

SSH into Proxmox and download the script directly to avoid copy-paste errors:

ssh root@your-proxmox-host
wget https://raw.githubusercontent.com/Ali-Shaikh/proxmox-toolbox/main/templates/openclaw/debian-13-openclaw-ready-template.sh -O debian-13-openclaw-ready-template.sh

Configure It

Open the script and modify these values:

nano debian-13-openclaw-ready-template.sh

Change these:

VMID=10010 # Template ID (pick any unused ID; check with `qm list`)
STORAGE="local-lvm" # Your Proxmox storage pool (verify with `pvesm list`)
MEMORY=4096 # 4GB RAM minimum
CORES=2 # CPU cores

CI_USER="debian"
CI_PASSWORD="$(openssl passwd -6 $(pwgen -s 16 1))" # Generate a strong password with pwgen or similar; install pwgen if needed: apt install pwgen

# Replace with YOUR SSH public key
echo "ssh-rsa AAAA... your-email@example.com" > ~/ssh.pub

Note: Homebrew (Linuxbrew) is installed via cloud-init for certain dependencies; it's not native to Debian but works fine for this setup.

Run It

chmod +x debian-13-openclaw-ready-template.sh
./debian-13-openclaw-ready-template.sh

The script will:

Download Debian 13 cloud image
Create a VM with UEFI support
Configure cloud-init to install Node.js, OpenClaw, Tailscale, pnpm, Homebrew
Convert it to a template

Time: ~2-3 minutes

Part 2: Deploy a VM

Clone the template (replace IDs if needed; check for conflicts with qm list):

qm clone 10010 201 --name openclaw-prod --full
qm start 201

Wait 5-7 minutes. Cloud-init is installing everything. You can watch progress:

# Get the VM's IP (once it boots)
qm guest cmd 201 network-get-interfaces

# SSH in and watch the install
ssh debian@<vm-ip>
sudo tail -f /var/log/openclaw-install.log

When you see "Installation Complete", you're ready.

Verify Installation

# Quick check
check-install-status

# Or check versions manually
cat /root/install-versions.txt

You should see Node.js 24, npm, pnpm, OpenClaw, Tailscale, and Homebrew all installed.

Part 3: Configure OpenClaw

Connect to Tailscale

Get an auth key from https://login.tailscale.com/admin/settings/keys (set to expire in 30-90 days for security).

sudo tailscale up --authkey=tskey-auth-YOUR_KEY_HERE
tailscale status # Verify connection

Set Up pnpm (Required for Skills)

pnpm setup
source ~/.bashrc

Run OpenClaw Onboarding

openclaw onboard --install-daemon

Critical configuration choices:

Question	Answer	Why?
Setup type	Local gateway (this machine)	Keeps everything self-contained.
Bind address	Loopback (127.0.0.1) - MUST BE LOOPBACK	Prevents direct exposure to LAN or internet; required for secure Tailscale proxying.
Authentication	Token (Recommended)	Stronger than alternatives for access control.
Expose via	Tailscale Serve	Secure Tailnet-only access without public exposure.

Important:

Never select "LAN (0.0.0.0)" for bind address
Do not select "Funnel" (exposes to public internet)
If you get a Tailscale binary warning, choose "No" and continue

Save Your Token

The wizard will display your gateway token. Save it:

cat ~/.openclaw/openclaw.json | jq -r '.gateway.auth.token'

Output: claw_abc123def456...

Write this down. You'll need it to access the UI.

Verify Tailscale Serve

tailscale serve status

Expected output:

https://openclaw-host.tail-scale.ts.net/ (Tailscale Serve)
|-- / proxy http://127.0.0.1:18789

If empty, configure manually:

sudo tailscale serve --bg --https=443 http://127.0.0.1:18789

Check Gateway Status

openclaw status
openclaw health
openclaw gateway logs # Watch for errors

Part 4: Access the UI

From any device on your Tailscale network:

# Get all access info in one command
openclaw-access-info

This shows your Tailscale URL and gateway token. Open the URL in your browser.

Example: https://openclaw-host.tail-scale.ts.net/

Enter your gateway token when prompted. If "allowTailscale": true is enabled in your config, you'll be auto-authenticated - see Configuration File for trade-offs.

Important: Based on common troubleshooting (though not explicitly in OpenClaw docs), when using Tailscale Serve, you may need to add "controlUi": { "allowInsecureAuth": true } to your config file to avoid "pairing required" WebSocket errors. This skips device pairing for compatibility but reduces security slightly; use only if needed and combine with strong token auth.

Configuration File

Your OpenClaw config lives at ~/.openclaw/openclaw.json:

{
  "gateway": {
    "port": 18789,
    "bind": "127.0.0.1",
    "tailscale": {
      "mode": "serve"
    },
    "auth": {
      "mode": "token",
      "token": "your-gateway-token-here",
      "allowTailscale": false // Set to true for auto-auth via Tailscale identity (convenience trade-off: trust your Tailnet fully or use token-only for stricter security)
    },
    "controlUi": {
      "allowInsecureAuth": true // May be needed for Tailscale Serve to fix WebSocket errors; skips device pairing (use with caution)
    }
  }
}

Key settings:

bind: "127.0.0.1" - Gateway only listens on loopback (required for Tailscale Serve)
tailscale.mode: "serve" - Tailnet-only access
auth.allowTailscale: false - Prefer token auth; enable true only if you fully trust your Tailnet (trade-off: easier access vs. potential risk if Tailnet is compromised)
controlUi.allowInsecureAuth: true - May be needed for Tailscale Serve - Skips device pairing to prevent "pairing required" WebSocket errors (trade-off: fixes compatibility but weakens pairing-based security; not explicitly required in OpenClaw docs but helps with common issues)

View your config:

cat ~/.openclaw/openclaw.json | jq

Add Chat Integrations

openclaw channels login
# Scan QR code with WhatsApp > Settings > Linked Devices (note: WhatsApp limits linked devices; check your account limits)

openclaw configure --section channels.telegram
# Add bot token from @BotFather

Discord

openclaw configure --section channels.discord
# Add bot token from Discord Developer Portal

Note: For LLM integrations (e.g., Claude, GPT-4o keys), add them securely via openclaw configure --section models. Store keys in environment variables or a secrets manager for best practices.

Troubleshooting

Tailscale Serve Not Working

Check Tailscale status:

tailscale status
sudo systemctl status tailscaled

Manually configure Serve:

sudo tailscale serve --bg --https=443 http://127.0.0.1:18789
tailscale serve status

Ensure HTTPS is enabled for your Tailnet:

Visit https://login.tailscale.com/admin/dns
Enable HTTPS if prompted

Can't Access from Remote Device

Verify both devices are on Tailscale:

tailscale status # Run on both devices

Test connectivity:

ping openclaw-host
curl -k https://openclaw-host.tail-scale.ts.net/health

WebSocket Errors: "pairing required" (1008)

Edit your config:

nano ~/.openclaw/openclaw.json

Add under the gateway section:

"controlUi": {
  "allowInsecureAuth": true
}

Restart the gateway:

systemctl --user restart openclaw-gateway

This skips device pairing for Tailscale compatibility.

Installation Seems Stuck

# Check cloud-init progress
sudo tail -100 /var/log/cloud-init-output.log

# Check OpenClaw install progress
sudo tail -100 /var/log/openclaw-install.log

# Current step
cat /var/run/openclaw-install-progress

pnpm Global Bin Error

If you see ERR_PNPM_NO_GLOBAL_BIN_DIR when installing skills:

pnpm setup
source ~/.bashrc
openclaw onboard --install-daemon # Retry

Proxmox-Specific Issues

VM won't boot: Check UEFI settings in Proxmox VM hardware tab; ensure BIOS is set to OVMF (UEFI).
No IP assigned: Verify DHCP in your Proxmox network bridge; restart VM if needed.

Reset Everything

Start over if needed:

openclaw gateway stop
rm -rf ~/.openclaw/
openclaw onboard --install-daemon

Diagnostic Commands

openclaw doctor # Comprehensive health check
openclaw status --all # Deep status
openclaw health # Quick health probe
openclaw gateway logs -f # Follow gateway logs

Security Considerations

OpenClaw can execute commands and access your system. Here's how to secure it:

Gateway Security

1. Loopback binding only

{ "gateway": { "bind": "127.0.0.1" } }

2. Token authentication

{
  "gateway": {
    "auth": {
      "mode": "token",
      "allowTailscale": false // Token-only is stricter; enable true only if Tailnet is highly trusted
    }
  }
}

3. Rotate tokens regularly (every 90 days)

openclaw configure --section gateway.auth

4. Monitor access logs

openclaw gateway logs | grep -i "error\|unauthorised\|failed"

Tailscale Security

Use Serve (Tailnet-only), not Funnel (public).
Generate auth keys with 30-90 day expiration; rotate them.
Enable firewall (e.g., UFW: sudo ufw enable and allow only necessary outbound traffic).

System Security

Regular updates:

sudo apt update && sudo apt upgrade -y
openclaw update

Consider automating via cron: crontab -e and add 0 2 * * * /usr/bin/apt update && /usr/bin/apt upgrade -y.

Backups:

Take Proxmox snapshots before changes: qm snapshot 201 pre-config --description 'Before updates'.

Also, backup config:

tar -czf openclaw-backup-$(date +%Y%m%d).tar.gz ~/.openclaw/

Best Practices:

Use token authentication
Enable Tailscale Serve (not Funnel)
Regular backups and updates
Monitor logs for issues
Rotate credentials periodically
Never expose gateway on 0.0.0.0
Never commit tokens to git
Install monitoring tools like Fail2Ban for SSH: sudo apt install fail2ban
For least privilege (e.g., running OpenClaw as non-root user), we'll cover it in a future article when we deep dive into securing it.
Consider sandboxing with Docker inside the VM for extra isolation.

Testing and Validation

After setup, run a smoke test:

Access the UI via Tailscale URL.
Send a test message via WhatsApp/Telegram: "Hello, what's the weather in Dubai?" (assuming LLM integration).
Verify browser control: Ask it to open a safe site and scrape non-sensitive data.
Check logs for errors: openclaw gateway logs.

If issues arise, use the troubleshooting section.

The Template Script (Full Code)

Here is the full code for reference (you can copy-paste this into a file if the wget fails, but using the raw URL is recommended):

#!/bin/bash

# ===== PRODUCTION-READY OPENCLAW PROXMOX TEMPLATE =====
# This script creates a Debian 13 VM template with OpenClaw pre-installed
#
# Author: Ali Shaikh <alishaikh.me>
#
# Features:
# - Cloud-init progress indication
# - Login warnings during initialization
# - Automatic pnpm setup
# - Status check commands
# - Access info helper command
# - Proper error handling
#
# ===== CONFIGURABLE PARAMETERS =====

VMID=10010
VM_NAME="debian-13-openclaw-ready-template"
STORAGE="local-lvm"
MEMORY=4096
SOCKETS=1
CORES=2
DISK_ADDITIONAL_SIZE="+15G"

IMAGE_URL="https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2"
IMAGE_PATH="/var/lib/vz/template/iso/$(basename ${IMAGE_URL})"

CI_USER="debian"
CI_PASSWORD="$(openssl passwd -6 debian)" # For production, use a stronger password

# Replace with your actual SSH public key
echo "ssh-rsa " > ~/ssh.pub

# Download Debian 13 Cloud Image
if [! -f "${IMAGE_PATH}"]; then
  echo "Downloading Debian 13 Cloud Image..."
  wget -P /var/lib/vz/template/iso/ "${IMAGE_URL}"
else
  echo "Image already exists at ${IMAGE_PATH}"
fi

set -x

# Destroy existing VM if it exists
qm destroy $VMID 2>/dev/null || true

# Create VM
qm create ${VMID} \
  --name "${VM_NAME}" \
  --ostype l26 \
  --memory ${MEMORY} \
  --cores ${CORES} \
  --agent 1 \
  --bios ovmf --machine q35 --efidisk0 ${STORAGE}:0,pre-enrolled-keys=0 \
  --cpu host --socket ${SOCKETS} --cores ${CORES} \
  --vga serial0 --serial0 socket \
  --net0 virtio,bridge=vmbr0

# Import disk
qm importdisk ${VMID} "${IMAGE_PATH}" ${STORAGE}
qm set $VMID --scsihw virtio-scsi-pci --virtio0 $STORAGE:vm-${VMID}-disk-1,discard=on
qm resize ${VMID} virtio0 ${DISK_ADDITIONAL_SIZE}
qm set $VMID --boot order=virtio0
qm set $VMID --scsi1 $STORAGE:cloudinit

# Create snippets directory
mkdir -p /var/lib/vz/snippets/

# Create Cloud-Init configuration with proper YAML formatting
cat << 'CLOUDCONFIG' | tee /var/lib/vz/snippets/debian13_openclaw_ready.yaml
#cloud-config

package_update: true
package_upgrade: true

packages:
  - curl
  - wget
  - git
  - build-essential
  - procps
  - file
  - ca-certificates
  - gnupg
  - qemu-guest-agent
  - htop
  - vim
  - tmux
  - jq
  - cron

write_files:
  # Login status checker - runs on every login to show progress
  - path: /etc/profile.d/cloud-init-status.sh
    permissions: '0755'
    owner: root:root
    content: |
      #!/bin/bash
      # Check cloud-init and installation status on login

      RED='\033[0;31m'
      GREEN='\033[0;32m'
      YELLOW='\033[1;33m'
      BLUE='\033[0;34m'
      NC='\033[0m' # No Color

      # Check if cloud-init is still running
      if cloud-init status 2>/dev/null | grep -q "running"; then
        echo ""
        echo -e "${YELLOW}========================================${NC}"
        echo -e "${YELLOW} SYSTEM INITIALISATION IN PROGRESS${NC}"
        echo -e "${YELLOW}========================================${NC}"
        echo ""
        echo -e "${BLUE}Cloud-init is still running. Please wait...${NC}"
        echo ""
        echo "Monitor progress:"
        echo " sudo tail -f /var/log/cloud-init-output.log"
        echo " sudo tail -f /var/log/openclaw-install.log"
        echo ""
        echo "Check status:"
        echo " cloud-init status"
        echo " cat /var/run/openclaw-install-progress"
        echo ""
        echo -e "${YELLOW}Some commands may not be available yet!${NC}"
        echo ""
      elif [-f /var/run/openclaw-install-progress]; then
        PROGRESS=$(cat /var/run/openclaw-install-progress 2>/dev/null)
        if ["$PROGRESS" != "COMPLETE"]; then
          echo ""
          echo -e "${YELLOW}Installation in progress: $PROGRESS${NC}"
          echo "Run: sudo tail -f /var/log/openclaw-install.log"
          echo ""
        fi
      elif [-f /root/.openclaw-ready]; then
        # Only show ready message once per session
        if [-z "$OPENCLAW_READY_SHOWN"]; then
          echo ""
          echo -e "${GREEN}System is ready! Run: setup-openclaw.sh${NC}"
          echo ""
          export OPENCLAW_READY_SHOWN=1
        fi
      fi

  - path: /usr/local/bin/openclaw-access-info
    permissions: '0755'
    owner: root:root
    content: |
      #!/bin/bash
      echo "==========================================="
      echo "OpenClaw Access Information"
      echo "==========================================="
      echo ""
      echo "Tailscale Serve URL:"
      tailscale serve status 2>/dev/null | grep -o 'https://[^]*' || echo " Not configured - run: openclaw onboard --install-daemon"
      echo ""
      if [-f ~/.openclaw/openclaw.json]; then
        echo "Gateway Token:"
        cat ~/.openclaw/openclaw.json | jq -r '.gateway.auth.token' 2>/dev/null || echo " Not found"
        echo ""
        echo "Allow Tailscale Auth:"
        cat ~/.openclaw/openclaw.json | jq -r '.gateway.auth.allowTailscale' 2>/dev/null || echo " Not configured"
      else
        echo "OpenClaw not configured yet"
        echo "Run: openclaw onboard --install-daemon"
      fi
      echo "==========================================="

  - path: /usr/local/bin/setup-openclaw.sh
    permissions: '0755'
    owner: root:root
    content: |
      #!/bin/bash
      echo "======================================"
      echo "OpenClaw Setup Helper"
      echo "======================================"
      echo ""
      echo "Installed versions:"
      echo " Node.js: $(node --version 2>/dev/null || echo 'Not found')"
      echo " npm: $(npm --version 2>/dev/null || echo 'Not found')"
      echo " pnpm: $(pnpm --version 2>/dev/null || echo 'Not installed')"
      echo " OpenClaw: $(openclaw --version 2>/dev/null || echo 'Not installed - run: npm install -g openclaw@latest')"
      echo " Tailscale: $(tailscale version 2>/dev/null || echo 'Not found')"
      echo " Homebrew: $(brew --version 2>/dev/null | head -n1 || echo 'Not found - source ~/.bashrc first')"
      echo ""
      echo "Quick Start Guide:"
      echo "=================="
      echo ""
      echo "1. Connect to Tailscale:"
      echo " Get auth key: https://login.tailscale.com/admin/settings/keys"
      echo " sudo tailscale up --authkey=tskey-auth-YOUR_KEY"
      echo ""
      echo "2. Configure pnpm (required for skills):"
      echo " pnpm setup && source ~/.bashrc"
      echo ""
      echo "3. Configure OpenClaw:"
      echo " openclaw onboard --install-daemon"
      echo ""
      echo " Configuration choices:"
      echo " - Setup: Local gateway (this machine)"
      echo " - Bind: Loopback (127.0.0.1) <- REQUIRED"
      echo " - Auth: Token (Recommended)"
      echo " - Tailscale: Serve (for HTTPS)"
      echo ""
      echo "4. Get access info:"
      echo " openclaw-access-info"
      echo ""
      echo "5. Verify:"
      echo " openclaw status"
      echo " openclaw health"
      echo " tailscale serve status"
      echo ""
      echo "Docs: https://docs.openclaw.ai"
      echo ""

  # Progress checker command
  - path: /usr/local/bin/check-install-status
    permissions: '0755'
    owner: root:root
    content: |
      #!/bin/bash
      echo "========================================"
      echo "Installation Status Check"
      echo "========================================"
      echo ""

      # Cloud-init status
      echo "Cloud-init status:"
      cloud-init status 2>/dev/null || echo " Unable to check"
      echo ""

      # Progress file (cleared after reboot, so may not exist)
      if [-f /var/run/openclaw-install-progress]; then
        echo "Current step: $(cat /var/run/openclaw-install-progress)"
      fi

      # Ready marker (use sudo to check /root)
      if sudo test -f /root/.openclaw-ready 2>/dev/null; then
        echo "Status: READY"
      else
        echo "Status: IN PROGRESS (or checking permissions...)"
      fi
      echo ""

      # Installed versions (use sudo to read /root)
      if sudo test -f /root/install-versions.txt 2>/dev/null; then
        echo "Installed versions:"
        sudo cat /root/install-versions.txt | sed 's/^/ /'
      fi
      echo ""

      echo "Logs:"
      echo " sudo tail -f /var/log/openclaw-install.log"

  - path: /root/install-openclaw.sh
    permissions: '0755'
    owner: root:root
    content: |
      #!/bin/bash
      # Don't use set -e - we want to continue even if some commands fail
      exec > /var/log/openclaw-install.log 2>&1

      # Progress update function
      update_progress() {
        echo "$1" > /var/run/openclaw-install-progress
        echo ">>> PROGRESS: $1"
      }

      echo "=== OpenClaw Installation Started at $(date) ==="
      update_progress "Starting installation..."

      # Install Tailscale
      update_progress "Installing Tailscale..."
      curl -fsSL https://tailscale.com/install.sh | sh
      if command -v tailscale &> /dev/null; then
        echo "Tailscale version: $(tailscale version)"
      else
        echo "WARNING: Tailscale installation may have failed"
      fi

      # Install Node.js 24
      update_progress "Installing Node.js 24..."
      curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
      apt-get install -y nodejs
      echo "Node.js version: $(node --version)"
      echo "npm version: $(npm --version)"

      # Install pnpm globally
      update_progress "Installing pnpm..."
      npm install -g pnpm@latest
      echo "pnpm version: $(pnpm --version)"

      # Setup pnpm global bin directory (required for OpenClaw skills)
      pnpm setup
      source /root/.bashrc 2>/dev/null || true
      # Also setup for debian user
      sudo -u debian bash -c 'pnpm setup' 2>/dev/null || true

      # Install OpenClaw via npm
      update_progress "Installing OpenClaw..."
      npm install -g openclaw@latest

      # Verify installation and add to PATH if needed
      if command -v openclaw &> /dev/null; then
        echo "OpenClaw version: $(openclaw --version)"
      else
        echo "OpenClaw not in PATH, checking npm global bin..."
        NPM_BIN=$(npm bin -g)
        if [-f "$NPM_BIN/openclaw"]; then
          echo "Found at $NPM_BIN/openclaw, creating symlink..."
          ln -sf "$NPM_BIN/openclaw" /usr/local/bin/openclaw
          echo "OpenClaw version: $(openclaw --version)"
        else
          echo "ERROR: OpenClaw installation failed"
          echo "NPM global bin: $NPM_BIN"
          ls -la "$NPM_BIN/" 2>/dev/null || echo "Cannot list npm bin directory"
        fi
      fi

      # Install Homebrew for debian user (for plugins)
      update_progress "Installing Homebrew (this may take a while)..."
      # Create the debian user's home if it doesn't exist
      mkdir -p /home/debian
      chown debian:debian /home/debian

      # Install Homebrew as debian user
      sudo -u debian bash -c 'NONINTERACTIVE=1 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"' || {
        echo "WARNING: Homebrew installation failed"
      }

      # Add Homebrew to debian user's PATH
      if [-d "/home/linuxbrew/.linuxbrew"]; then
        sudo -u debian bash -c 'echo "# Homebrew" >> ~/.bashrc'
        sudo -u debian bash -c 'echo "eval \"$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)\"" >> ~/.bashrc'
        echo "Homebrew installed successfully"
      else
        echo "WARNING: Homebrew directory not found after installation"
      fi

      update_progress "Finalising..."

      echo "=== Installation Complete at $(date) ==="
      echo "Node.js: $(node --version 2>/dev/null || echo 'FAILED')" > /root/install-versions.txt
      echo "npm: $(npm --version 2>/dev/null || echo 'FAILED')" >> /root/install-versions.txt
      echo "pnpm: $(pnpm --version 2>/dev/null || echo 'FAILED')" >> /root/install-versions.txt
      echo "OpenClaw: $(openclaw --version 2>/dev/null || echo 'FAILED')" >> /root/install-versions.txt
      echo "Tailscale: $(tailscale version 2>/dev/null || echo 'FAILED')" >> /root/install-versions.txt
      echo "Homebrew: $(sudo -u debian /home/linuxbrew/.linuxbrew/bin/brew --version 2>/dev/null | head -n1 || echo 'FAILED')" >> /root/install-versions.txt

      # Mark installation as complete
      update_progress "COMPLETE"
      touch /root/.openclaw-ready

      echo ""
      echo "Check /root/install-versions.txt for results"

runcmd:
  - systemctl enable qemu-guest-agent
  - systemctl start qemu-guest-agent
  - echo "INITIALISING" > /var/run/openclaw-install-progress
  - chmod +x /root/install-openclaw.sh
  - /root/install-openclaw.sh
  - chown debian:debian /usr/local/bin/setup-openclaw.sh
  - |
    cat >> /etc/motd << 'MOTD'

    ========================================
    OpenClaw Ready Template
    ========================================
    Created by Ali Shaikh
    https://alishaikh.me

    Pre-installed (globally):
      - Node.js 24 (NodeSource)
      - pnpm (latest)
      - OpenClaw CLI
      - Tailscale (official)
      - Homebrew (for plugins)

    Check installation: cat /root/install-versions.txt
    Check status: check-install-status
    Setup guide: setup-openclaw.sh
    Access info: openclaw-access-info (after configuration)

    MOTD
  - apt-get clean
  - apt-get autoremove -y

power_state:
  mode: reboot
  message: "Rebooting after OpenClaw installation"
  timeout: 30
  condition: True

CLOUDCONFIG

# Apply Cloud-Init configuration
qm set $VMID --cicustom "vendor=local:snippets/debian13_openclaw_ready.yaml"
qm set $VMID --tags debian-template,openclaw-ready,nodejs24,production
qm set ${VMID} --ciuser ${CI_USER} --cipassword "${CI_PASSWORD}"
qm set $VMID --sshkeys ~/ssh.pub
qm set $VMID --ipconfig0 ip=dhcp

# Convert to template
qm template ${VMID}

echo ""
echo "=========================================="
echo "PRODUCTION TEMPLATE CREATED SUCCESSFULLY"
echo "=========================================="
echo "Template ID: ${VMID}"
echo "Template Name: ${VM_NAME}"
echo ""
echo "Globally installed:"
echo " - Node.js 24 (NodeSource)"
echo " - pnpm (latest)"
echo " - OpenClaw CLI"
echo " - Tailscale (official)"
echo " - Homebrew (for plugins)"
echo ""
echo "DEPLOYMENT:"
echo " qm clone ${VMID} 201 --name openclaw-prod --full"
echo " qm start 201"
echo ""
echo "IMPORTANT: Wait 5-7 minutes for installation to complete"
echo ""
echo "CHECK INSTALLATION STATUS:"
echo " ssh debian@<vm-ip>"
echo " check-install-status # Quick status check"
echo " tail -f /var/log/openclaw-install.log"
echo " cat /root/install-versions.txt"
echo ""

Conclusion

You now have a production-ready AI assistant running on your own infrastructure, accessible from anywhere via WhatsApp, Telegram, or your browser, with zero public exposure. Your conversations and command history stay on your server, your files remain under your control, and you decide exactly what the AI can access. However, be clear about the privacy boundary: when you use cloud models like Claude, GPT-4o, or Gemini, your prompts and responses still go to Anthropic, OpenAI, or Google. Self-hosting OpenClaw gives you infrastructure control and data residency for everything except the LLM API calls. For true end-to-end privacy, you'd need to run local models via Ollama or LM Studio, though at the cost of performance compared to cloud models.

Before you start feeding your assistant sensitive data, remember what you've built: a system that can execute arbitrary commands, access files, and interact with external services. The security measures in this guide (loopback binding, token authentication, Tailscale isolation) are foundational, not exhaustive. Treat this like any other privileged service: rotate credentials regularly, monitor access logs, keep the system patched, and never expose the gateway publicly. The Proxmox snapshot feature is your friend - take one before major changes so you can roll back easily.

The Proxmox template makes this repeatable: clone it whenever you need a fresh instance, whether for testing new configurations or deploying assistants for different use cases. OpenClaw is still evolving rapidly (remember, it went from zero to 100k stars in two months), so expect frequent updates and new capabilities. Consider this deployment a learning platform first, a production tool second. Test destructively in clones, understand the permission model, and gradually increase what you trust it to do. Report issues or contribute on the GitHub repo.

Self-hosting means self-responsibility, but it also means you're not at the mercy of a vendor's API changes or pricing decisions. Join the community, experiment with custom skills, contribute back what you learn, and most importantly, keep your gateway token secure. Stay vigilant, stay curious, and enjoy having an AI that actually works for you. Happy automating! 🦞

References

Kubernetes 1.35: In-Place Pod Vertical Scaling Reaches GA

Ali Shaikh — Mon, 29 Dec 2025 20:48:39 +0000

Kubernetes v1.35, released on 17 December 2025, brings the long-awaited in-place pod vertical scaling feature to general availability (GA). This feature, officially called 'In-Place Pod Resize', allows administrators to adjust CPU and memory resources for running containers without recreating pods.

The Traditional Approach to Resource Scaling

Before this feature, scaling pod resources required deleting and recreating the pod:

1. Update deployment/pod specification with new resource values
2. Kubernetes terminates the existing pod
3. Scheduler creates a new pod with updated resources
4. Container runtime starts the new pod
5. Application initialises and becomes ready

This approach causes:

Dropped network connections
Loss of in-memory application state
Service disruption during pod restart
Extended downtime for applications with long startup times

What is In-Place Pod Vertical Scaling?

In-Place Pod Vertical Scaling enables runtime modification of CPU and memory resource requests and limits without pod recreation. The Kubelet adjusts cgroup limits for running containers, allowing resource changes with minimal disruption.

Development Timeline

v1.27 (April 2023): Alpha release
v1.33 (May 2025): Beta release
v1.35 (December 2025): General availability (stable)

The feature required 6+ years of development to solve complex challenges, including container runtime coordination, scheduler synchronisation, and memory safety guarantees.

Key Features in v1.35

1. Memory Limit Decrease

Previous versions prohibited memory limit decreases due to out-of-memory (OOM) concerns. Version 1.35 implements best-effort memory decrease with safety checks:

Kubelet verifies current memory usage is below the new limit
Resize fails gracefully if usage exceeds the new limit
Not guaranteed to prevent OOM, but significantly safer than forced decrease

Example:

# Previously prohibited, now allowed
resources:
  requests:
    memory: "512Mi" # Decreased from 1Gi
  limits:
    memory: "1Gi" # Decreased from 2Gi

2. Prioritised Resize Queue

When node capacity is insufficient for all resize requests, Kubernetes prioritises them by:

PriorityClass value (higher first)
QoS class (Guaranteed > Burstable > BestEffort)
Duration deferred (oldest first)

This ensures critical workloads receive resources before lower-priority pods.

3. Enhanced Observability

New metrics and events improve resize operation tracking:

Kubelet Metrics:

pod_resource_resize_requests_total
pod_resource_resize_failures_total
pod_resource_resize_duration_seconds

Pod Conditions:

PodResizePending: Request cannot be immediately granted
PodResizeInProgress: Kubelet is applying changes

4. VPA Integration

Vertical Pod Autoscaler (VPA) InPlaceOrRecreate update mode graduated to beta, enabling automatic resource adjustment using in-place resize when possible.

How It Works

Resize Policies

Containers specify restart behaviour for each resource type:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: app
    image: nginx:1.27
    resources:
      requests:
        cpu: "500m"
        memory: "512Mi"
      limits:
        cpu: "1000m"
        memory: "1Gi"
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired # No restart for CPU changes
    - resourceName: memory
      restartPolicy: RestartContainer # Restart required for memory

Policy Options:

NotRequired: Apply changes without container restart (default for CPU)
RestartContainer: Restart container to apply changes (often needed for memory)

Applying Resource Changes

Use the --subresource=resize flag with kubectl (requires kubectl v1.32+):

kubectl patch pod example --subresource=resize --patch '
{
  "spec": {
    "containers": [
      {
        "name": "app",
        "resources": {
          "requests": {"cpu": "800m"},
          "limits": {"cpu": "1600m"}
        }
      }
    ]
  }
}'

Monitoring Resize Status

Check desired vs actual resources:

# Desired (spec)
kubectl get pod example -o jsonpath='{.spec.containers[0].resources}'

# Actual (status)
kubectl get pod example -o jsonpath='{.status.containerStatuses[0].resources}'

View resize conditions:

kubectl get pod example -o jsonpath='{.status.conditions[?(@.type=="PodResizeInProgress")]}'
kubectl describe pod example | grep -A 10 Events

Use Cases

1. Peak Hour Resource Scaling

Scale resources to match daily traffic patterns without service disruption. For example, scale up CPU/memory at 08:55 for business hours, then scale down at 18:05 after hours, eliminating the need for pod recreation.

2. Database Maintenance Operations

Temporarily increase CPU allocation for intensive maintenance tasks like VACUUM or REINDEX operations, then restore normal allocation once complete. This avoids pod restart and preserves warm database caches.

3. JIT Compilation Warmup

Provide additional CPU during application startup for JIT compilation warmup, then reduce allocation once the application reaches steady state. Particularly beneficial for Java applications with large codebases.

4. Cost Optimisation

Dynamically right-size resources to reduce waste by scaling down during low-traffic periods, reducing over-provisioning based on actual usage patterns, and implementing time-based scaling without pod recreation overhead.

Limitations and Constraints

Resource Support:

Only CPU and memory can be resized (GPU, ephemeral storage, hugepages remain immutable)
Init and ephemeral containers cannot be resized
QoS class cannot change during resize

Platform Requirements:

Not supported on Windows nodes
Requires compatible container runtime (containerd v2.0+, CRI-O v1.25+)
Cannot resize with static CPU or Memory manager policies

Important Behaviours:

Most runtimes (Java, Python, Node.js) require restart for memory changes
Updating Deployment specs does not auto-resize existing pods
Cannot remove requests or limits entirely, only modify values

Upgrading to Kubernetes v1.35

Prerequisites

Kubernetes v1.34.x cluster
kubectl v1.32+ client
Compatible container runtime

Upgrade Process

1. Add v1.35 repository to all nodes:

# On each node
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.35/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-1.35-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-1.35-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.35/deb/ /' | \
  sudo tee /etc/apt/sources.list.d/kubernetes-1.35.list

sudo apt update

2. Upgrade control plane:

sudo apt-mark unhold kubeadm
sudo apt install -y kubeadm=1.35.0-1.1
sudo kubeadm upgrade apply v1.35.0 -y
sudo apt-mark unhold kubelet kubectl
sudo apt install -y kubelet=1.35.0-1.1 kubectl=1.35.0-1.1
sudo systemctl restart kubelet

3. Upgrade workers (one at a time):

kubectl drain <worker-name> --ignore-daemonsets --delete-emptydir-data --force

ssh <worker-node>
sudo apt-mark unhold kubeadm kubelet kubectl
sudo apt install -y kubeadm=1.35.0-1.1 kubelet=1.35.0-1.1 kubectl=1.35.0-1.1
sudo kubeadm upgrade node
sudo systemctl restart kubelet

kubectl uncordon <worker-name>

4. Verify upgrade:

kubectl get nodes
# All nodes should show v1.35.0

Testing In-Place Resize

Basic CPU Resize Test

apiVersion: v1
kind: Pod
metadata:
  name: cpu-test
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    resources:
      requests:
        cpu: "250m"
      limits:
        cpu: "500m"
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired

Create pod and verify baseline:

kubectl apply -f cpu-test.yaml
kubectl get pod cpu-test -o jsonpath='{.status.containerStatuses[0].restartCount}'
# Output: 0

Resize CPU:

kubectl patch pod cpu-test --subresource=resize --patch '
{
  "spec": {
    "containers": [{
      "name": "nginx",
      "resources": {
        "requests": {"cpu": "800m"},
        "limits": {"cpu": "800m"}
      }
    }]
  }
}'

Verify no restart occurred:

kubectl get pod cpu-test -o jsonpath='{.status.containerStatuses[0].restartCount}'
# Output: 0 (unchanged)

kubectl get pod cpu-test -o jsonpath='{.spec.containers[0].resources.requests.cpu}'
# Output: 800m (updated)

Memory Decrease Test

# Create pod with high memory
kubectl apply -f memory-test.yaml

# Increase memory first
kubectl patch pod memory-test --subresource=resize --patch '
{
  "spec": {
    "containers": [{
      "name": "app",
      "resources": {
        "requests": {"memory": "1Gi"},
        "limits": {"memory": "2Gi"}
      }
    }]
  }
}'

# Decrease memory (new in v1.35)
kubectl patch pod memory-test --subresource=resize --patch '
{
  "spec": {
    "containers": [{
      "name": "app",
      "resources": {
        "requests": {"memory": "512Mi"},
        "limits": {"memory": "1Gi"}
      }
    }]
  }
}'

Best Practices

Testing: Verify application behaviour in non-production before enabling in production.

Resize Policies: Use NotRequired for CPU (usually safe), RestartContainer for memory (often requires restart).

Monitoring: Track Kubelet metrics for resize operations, alert on persistent PodResizePending conditions, monitor OOM events after decreases.

Resource Changes: Make incremental adjustments, avoid large jumps, verify current usage before decreasing limits.

Priority: Use PriorityClasses for critical workloads to ensure resize priority during capacity constraints.

Troubleshooting

Resize Rejected (stuck in PodResizePending): Check node capacity (kubectl describe node), verify QoS class compatibility, review kubelet configuration for static resource managers, ensure resize policy allows the change.

Unexpected Restarts: Memory changes often require restart regardless of policy. Use RestartContainer for memory, test application behaviour, monitor OOM events.

OOM After Memory Decrease: Verify current usage first (kubectl top pod), make gradual decreases, ensure application can release memory under pressure, consider using RestartContainer to force release.

Anti-Patterns: When NOT to Use In-Place Resize

Important: In-place pod resize is a powerful feature that can become an anti-pattern if misused. It should be reserved for specific edge cases, not used as a general scaling strategy.

Why It Can Be an Anti-Pattern

1. Violates Immutable Infrastructure: Kubernetes follows "cattle not pets" philosophy with ephemeral, replaceable pods. In-place resize makes pods mutable and long-lived, contradicting this design principle and reducing system resilience.

2. Breaks GitOps: Manual pod patching creates drift between Git repository and cluster reality. Next deployment overwrites manual changes, cluster state doesn't match version control, and you cannot reproduce environments from Git.

3. Configuration Drift: Pods in the same Deployment can have different resource allocations, causing inconsistent behaviour across replicas, difficult debugging, and unpredictable load distribution.

4. Reduces Failure Isolation: Encourages keeping pods alive longer rather than quick replacement, which can hide underlying issues like memory leaks and delay necessary restarts.

5. Better Alternatives Exist: Traffic spikes should use HPA (scale out), resource changes should update Deployments (declarative), and environment differences should use Kustomize/Helm.

Some Valid Use Cases

1. Stateful Applications with Expensive Startup: Databases with 15+ minute startup times (cache warming, index loading). Example: Scale up CPU for PostgreSQL VACUUM/ANALYZE operations, then scale down. Justified because recreation cost exceeds configuration drift cost.

2. Single-Instance Workloads: Legacy applications with shared file locks, non-distributed state, or connection pooling limitations. Justified because horizontal scaling isn't possible without full rewrite.

3. Emergency Production Incidents: Immediate relief for OOM conditions at 3am when proper solutions require hours of testing. Must be temporary (fix properly within 24 hours) and documented.

4. Predictable Temporary Spikes: Monthly report generation requiring 4x CPU for 2 hours. Automate with CronJobs to scale up/down on schedule. Justified because running 4x resources 24/7 wastes 96% of allocation.

5. Testing and Capacity Planning: Non-production experimentation to measure performance at different resource levels and determine optimal production sizing.

Future Enhancements

Kubernetes SIG-Node is working on:

Removing static CPU/Memory manager restrictions
Support for additional resource types
Improved safety for memory decreases (runtime-level checks)
Resource pre-emption (evict lower-priority pods for high-priority resizes)
Better integration with horizontal autoscaling

Conclusion

In-Place Pod Vertical Scaling addresses a long-standing Kubernetes limitation, enabling resource adjustments without service disruption. The v1.35 GA release brings production-ready capability with important improvements including memory decrease support, prioritised queuing, and enhanced observability.

While this feature enables dynamic resource management for stateful workloads and emergency scenarios, it should complement rather than replace traditional scaling patterns. Use HPA for traffic-based scaling, update Deployments for permanent changes, and reserve in-place resize for the specific edge cases where pod recreation cost genuinely exceeds operational complexity.

References

HTTP Status Codes Explained: Unlock the Web’s Secret Signals

Ali Shaikh — Fri, 21 Mar 2025 08:55:41 +0000

Ever clicked a link and wondered what’s happening behind the scenes? Your browser and the server trade quick messages, and HTTP status codes are the server’s way of spilling the beans. These three-digit numbers might seem odd, but they’re packed with info. Let’s break them down and try a fun trick to see them in action!

What Are HTTP Status Codes?

HTTP status codes are short replies from web servers to your browser, summing up what happened with your request. Loading a page, submitting a form, or fetching data—they’ve got a code for it all. Grouped into five categories, they tell you if things went great, got redirected, or hit a snag.

The Five Categories of Status Codes

1xx: Informational Responses

Rarely spotted, these codes mean your request is still cooking.

100 Continue : "Got the first bit—send more!"
101 Switching Protocols : "Switching connections per your request."

2xx: Success Responses

Sweet success! These mean your request nailed it.

200 OK : Perfection—your page loaded without a hitch.
201 Created : You’ve added something new, like a comment.
204 No Content : All good, but nothing to display.

3xx: Redirection Responses

A detour ahead—these point you somewhere else.

301 Moved Permanently : "This page has a new home."
302 Found : "It’s hanging out elsewhere for now."
304 Not Modified : "No updates since last time."

4xx: Client Errors

Uh-oh—something’s funky with your request.

400 Bad Request : "I can’t make sense of that."
401 Unauthorized : "Log in first, please."
403 Forbidden : "No entry allowed here."
404 Not Found : The classic "where’d it go?" error.
418 I’m a Teapot : A goofy joke—servers don’t brew coffee!

5xx: Server Errors

Not your mess—the server’s struggling.

500 Internal Server Error : "We broke something."
502 Bad Gateway : "A middleman dropped the ball."
503 Service Unavailable : "Too busy or down for a tune-up."

Why Status Codes Matter

These tiny numbers power the web:

They tell your browser what’s next (reload, redirect, or error out).
They help developers squash bugs.
They shape your journey, from snappy loads to clear error pages.

Try It Out: Catch a Status Code in the Wild

Want to peek at these codes yourself? Here’s how:

Open Chrome or Firefox on your computer.
Right-click any webpage and hit “Inspect” for Developer Tools.
Click the “Network” tab, then reload the page (Ctrl+R or Cmd+R).
Check the “Status” column—spot 200s, 304s, or a 404 if something’s AWOL.

For kicks, try a fake URL (like alishaikh.me/oops) and watch a 404 appear!

Fun Fact

The 418 I’m a Teapot code hatched from a 1998 April Fools’ prank. Proof the web’s got a playful side!

The Web’s Pulse: What Will You Discover?

From a flawless 200 OK to a cheeky 418, HTTP status codes are the heartbeat of every click. Now that you’ve decoded their signals, you’re no longer just a web surfer—you’re a digital detective. Fire up that “Network” tab and hunt for clues. What’s the wildest code you’ll catch today?

Creating Simple AI Agents: A Beginner's Guide

Ali Shaikh — Tue, 04 Mar 2025 08:33:02 +0000

In today's rapidly evolving tech landscape, AI agents are becoming increasingly accessible to developers of all skill levels. This article introduces the concept of AI agents and walks through creating a simple yet practical example: a landing page generator powered by language models running locally on your system using Ollama.

What Are AI Agents?

AI agents are software programs that can perform tasks with varying degrees of autonomy using artificial intelligence techniques. They typically:

Take input from users or environment
Process information using AI models
Perform actions based on this processing
Provide output or feedback to users

The complexity of AI agents ranges from simple task-specific tools to sophisticated systems with complex reasoning capabilities.

Prerequisites: Running Local LLMs with Ollama

Before diving into our AI agent, make sure you have Ollama set up on your system. If you haven't installed it yet, I've written a comprehensive guide on how to run local LLMs with Ollama. This will walk you through the installation process and get you ready to build your first AI agent.

Anatomy of a Simple AI Agent

The landing page generator we're examining represents a basic AI agent with these key components:

1. User Interface

A command-line interface collecting user requirements and displaying results.

2. AI Integration Layer

Code that formats prompts and communicates with the AI model (Ollama's DeepSeek in this case).

3. Processing Logic

Functions for extracting relevant content from AI responses and saving the output.

4. Action Execution

Code that opens the generated landing page and handles user workflow.

How This Landing Page Generator Works

This agent follows a straightforward workflow:

User Input : Collects a description of the desired landing page
AI Instruction : Sends carefully crafted prompts to the language model
Response Processing : Extracts HTML/CSS code from the model's response
Output Generation : Saves the code as an HTML file
Result Delivery : Opens the file in a browser and offers to create another

Key Design Principles

Looking at the code, we can identify several principles for effective AI agent design:

Clear, Specific Prompts

The system prompt defines the agent's role as a "skilled web developer" and provides specific constraints (using Tailwind CSS, delivering ready-to-use code).

Error Handling

The code gracefully handles potential failures in AI generation, extraction, and file operations.

User Experience Focus

The interface includes progress updates, confirmation prompts, and clear navigation options.

The Landing Page Generator Code

import ollama
import os
import re
from pathlib import Path
from datetime import datetime

def generate_landing_page(description):
    """Use Ollama to generate HTML with Tailwind CSS for a landing page based on description."""
    messages = [
        {"role": "system",
         "content": "You are a skilled web developer who creates clean, responsive landing pages using HTML and Tailwind CSS. Your code should be complete, valid, and ready to use with just the Tailwind CDN."},
        {"role": "user",
         "content": f"Create a complete landing page based on this description: {description}. Use Tailwind CSS for styling (include the CDN link). Provide only the HTML code with Tailwind classes and minimal internal JavaScript if needed. The code should be complete and ready to be saved as an index.html file."}
    ]

    try:
        print("Generating landing page with Tailwind CSS... This may take a minute or two...")
        response = ollama.chat(
            model='deepseek-r1:8b',
            messages=messages
        )

        # Extract HTML code from response
        html_content = response['message']['content']

        # Extract code between ```

html and

 ``` if present
        code_pattern = re.compile(r'```

(?:html)?\s*([\s\S]*?)\s*

```')
        match = code_pattern.search(html_content)

        if match:
            return match.group(1).strip()
        else:
            # If no code blocks found, try to extract just the HTML
            if "<html" in html_content and "</html>" in html_content:
                start = html_content.find("<html")
                end = html_content.find("</html>") + 7
                return html_content[start:end]
            return html_content

    except Exception as e:
        return f"Error generating landing page: {str(e)}"

def save_landing_page(html_content, output_dir="landing_pages"):
    """Save the generated HTML to a file."""
    # Ensure the output directory exists
    Path(output_dir).mkdir(exist_ok=True)

    # Create a filename with timestamp
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    filename = f"{output_dir}/landing_page_{timestamp}.html"

    # Save the HTML content
    with open(filename, "w", encoding="utf-8") as f:
        f.write(html_content)

    return filename

def main():
    """Run the dedicated landing page generator."""
    print("==========================================")
    print(" TAILWIND LANDING PAGE GENERATOR (OLLAMA) ")
    print("==========================================")

    # Get description for the landing page
    print("\nDescribe the landing page you want (be specific about colors, layout, features):")
    description = input("> ")

    if not description:
        print("Error: You must provide a description for the landing page.")
        return

    # Generate the landing page HTML
    html_content = generate_landing_page(description)

    # Save the landing page
    filename = save_landing_page(html_content)

    print(f"\nSuccess! Landing page created and saved to: {filename}")

    # Ask if user wants to open the file
    open_file = input("Would you like to open the landing page now? (y/n): ")
    if open_file.lower() in ['y', 'yes']:
        # Try to open the file in the default browser
        try:
            import webbrowser
            file_path = os.path.abspath(filename)
            webbrowser.open('file://' + file_path)
            print(f"Opened {filename} in your default browser.")
        except Exception as e:
            print(f"Couldn't open the file automatically: {e}")
            print(f"Please open {filename} manually in your browser.")

    # Ask if user wants to create another landing page
    another = input("\nWould you like to create another landing page? (y/n): ")
    if another.lower() in ['y', 'yes']:
        main() # Recursive call
    else:
        print("Thank you for using the Tailwind Landing Page Generator. Goodbye!")

if __name__ == " __main__":
    main()

I am using deepseek-r1:8b and I have also tried qwen2.5-coder:14b which gave me a better result. Feel free to tweak the script to match your setup.

You can visit my GitHub Repo where I will be adding more examples as I continue my journey in this exciting field of AI.

[

GitHub - Ali-Shaikh/ai-playground: AI Playground

AI Playground. Contribute to Ali-Shaikh/ai-playground development by creating an account on GitHub.

GitHubAli-Shaikh

](https://github.com/Ali-Shaikh/ai-playground?ref=alishaikh.me)

Going Beyond: Enhancing Your AI Agents

Again, this is a simple example to help you get up and running with creating an AI Agent. To create more sophisticated AI agents, consider:

Multiple Model Integration : Combine specialised models for different aspects of a task
Memory and Context : Maintain conversation history for more coherent interactions
User Preference Learning : Store and apply user preferences over time
Feedback Loops : Collect user feedback to improve future outputs
Validation Layers : Add code to validate AI outputs before presenting them

Conclusion

The landing page generator demonstrates how even simple AI agents can provide significant value. By combining clear prompts, effective processing, and thoughtful user experience design, developers can create tools that leverage AI to solve specific problems.

As you build your own AI agents, remember that the quality of your prompts, the robustness of your error handling, and the thoughtfulness of your user experience will largely determine your success.

In a nutshell, an AI agent is basically like calling an API with parameters, processing the result, manipulating it to your requirements and displaying the output. Anyone can get started with building an AI agent using Ollama or LM Studio. If you have a modest system, try using any of the smaller models such as qwen2.5-coder:3b or even a smaller model such as qwen2.5-coder:1.5b.

Smaller models are a great starting point, and while they may not offer the same quality as larger models, they are perfect for building your skills. As you get more comfortable with creating AI agents, you’ll be ready to work with larger models to unlock even more powerful capabilities!

Keep creating and innovating, and I would love to hear and see what you create. please feel free to share any comments, questions and examples of what you got done in the comments. If you need any help, feel free to reach out through my LinkedIn.

How to Run Local LLMs with Ollama: Quick Setup Guide

Ali Shaikh — Sun, 02 Mar 2025 08:50:48 +0000

If you've already checked out my guide on running local LLMs with LM Studio, you might be interested in another excellent option: Ollama. This tool offers a streamlined, command-line focused approach to running LLMs locally.

We can also use ollama in our code, integrate with Open WebUI or Continue (VS Code Extension) for a custom cursor IDE-like behaviour. I will publish something on these in the future.

What is Ollama?

Ollama is a lightweight, command-line tool that makes running open-source LLMs locally incredibly simple. It handles model downloads, optimisation, and inference in a single package with minimal configuration needed.

Quick Installation Guide

Windows

Visit Ollama's official website
Download and run the Windows installer
Follow the installation prompts
Once installed, Ollama runs as a background service

macOS

Download the macOS app from Ollama's website
Open the .dmg file
Drag Ollama to your Applications folder
Launch the app (it will run in the background)

Linux

Run this command in your terminal:

curl -fsSL https://ollama.com/install.sh | sh

Using Ollama (Basic Commands)

Once installed, using Ollama is as simple as opening a terminal or command prompt and running:

ollama run deepseek-r1:8b

This command downloads the deepseek-r1 8B model (if not already downloaded) and starts an interactive chat session.

If AI thinks this is funny, then there is a very slim chance of them taking over the world!

If you notice I added a --verbose flag to the run command, this shows us the stats at the end, such as tokens/s.

Popular Models to Try

Ollama makes it easy to experiment with different models:

ollama run llama3 # Meta's latest Llama 3 8B model
ollama run gemma:2b # Google's lightweight Gemma model
ollama run codellama # Specialised for coding tasks
ollama run neural-chat # Optimised for conversation
deepseek-r1:8b # My go to model

To see all available models:

ollama list remote

To see models you've already downloaded:

ollama list

Hardware Considerations

As explained in my LM Studio article, your hardware still matters. The same considerations apply:

Smaller models (2B-7B) work on modest hardware
Larger models (13B+) benefit greatly from a GPU
At least 16GB RAM recommended for a smooth experience

Ollama will automatically optimise for your available hardware.

Integrating with Other Tools

Ollama works well with several companion tools:

Open WebUI : A user-friendly chat interface for Ollama
Continue VS Code Extension : For coding assistance

Integrating with Code

One of Ollama's strongest features is its API, making it easy to integrate into your applications:

Python Integration

import requests

# Simple completion request
response = requests.post('http://localhost:11434/api/generate', 
    json={
        'model': 'deepseek-r1:8b',
        'prompt': 'Explain quantum computing in simple terms'
    }
)

print(response.json()['response'])

JavaScript/Node.js Integration

You can build complete chat applications, coding assistants, or content generation tools using this simple API.

const response = await fetch('http://localhost:11434/api/generate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'deepseek-r1:8b',
    prompt: 'Write a function to calculate fibonacci numbers'
  })
});

const data = await response.json();
console.log(data.response);

You can build complete chat applications, coding assistants, AI agents or content generation tools using this simple API. I will be covering this in future posts also.

For More Details

For a deeper dive into running local LLMs, model selection, and optimisation techniques, check out my full guide on running LLMs with LM Studio. The same principles apply, though the interface is different.

Final Thoughts

Ollama offers a more developer-oriented approach to local LLMs compared to LM Studio's GUI-focused experience. It's perfect for those comfortable with the command line or looking to integrate local AI into their development workflows.

How AI Models Process Text: Understanding Tokens in AI and LLMs with TikTokenizer

Ali Shaikh — Sat, 01 Mar 2025 07:21:51 +0000

In the world of artificial intelligence (AI) and large language models (LLMs), tokens are the essential building blocks that allow these systems to process and understand text. But what exactly are tokens, and how can a tool like TikTokenizer help us explore them? Let’s dive in.

What Are Tokens?

Tokens are the smallest units of text that an AI language model works with. Depending on the tokenization method, a token could be:

A word (e.g., "love" or "AI"),
A subword (e.g., "play" and "##ing" for "playing"),
Or even an individual character (e.g., "A" or "!").

For instance, the sentence "I love AI" might be tokenized as ["I", "love", "AI"]. Tokenization is the process of breaking down raw text into these units, transforming it into a format that a model can interpret. This step is critical because it determines how the model "sees" the text, influencing its ability to generate responses or understand meaning.

Why Tokenization Matters

Tokenization isn’t just a technical detail—it directly affects a model’s performance. The way text is split into tokens impacts:

Efficiency: Smaller tokens might mean more processing steps, while larger ones could simplify things.
Accuracy: Misaligned token boundaries might confuse the model’s interpretation.

Understanding tokenization is key for anyone working with LLMs, whether you're crafting prompts, debugging outputs, or optimizing text inputs.

Enter TikTokenizer

The TikTokenizer tool is a fantastic resource for visualizing and experimenting with tokenization. It’s interactive and user-friendly: simply type in any text, and the tool breaks it down into tokens, showing each one alongside its unique token ID —a numerical value that models use internally. For example, input "I love AI!" and you’ll see how it’s split and numbered.

How to Use It

Visit TikTokenizer.
Enter a sentence—like "Hello, world!"—into the text box.
Watch as it displays the tokens (e.g., ["Hello", ",", "world", "!"]) and their IDs.

You can play around with it by:

Adding punctuation (e.g., "Hello,world" vs. "Hello, world"),
Changing capitalization (e.g., "hello" vs. "HELLO"),
Or trying complex phrases to see how the tokenization adapts.

This hands-on approach makes it easy to see how different choices affect the process.

Why It’s Useful

TikTokenizer isn’t just a fun toy—it’s a practical tool for anyone interested in AI and LLMs. Here’s why it’s worth exploring:

Prompt Engineering: Learn to craft prompts that fit within token limits for better results.
Debugging: Spot why a model might misread your input by checking how it’s tokenized.
Learning: Gain a clearer grasp of NLP concepts if you’re new to the field.
Optimization: Tweak your text preprocessing to improve model performance.

Wrap-Up

Alright, let’s wrap this up! Tokens are the core of how AI language models make sense of text, and TikTokenizer lets you peek under the hood. Type something in, and it breaks it down into tokens with their IDs—super straightforward and honestly kinda cool. It’s perfect whether you’re new to AI or a seasoned pro. Want to see how your words get “read” by a machine? Check out TikTokenizer and give it a spin!

Run a Local LLM with LM Studio

Ali Shaikh — Fri, 28 Feb 2025 13:54:54 +0000

Picture this: your own AI buddy, running right on your computer, ready to chat, code, or solve problems—no internet, no fees, just you and your machine. That’s what running a Large Language Model (LLM) locally offers, and with LM Studio, it’s simpler than you’d think.

Introduction

So I have been tinkering with AI and I wanted to set up a LLM model such as DeepSeek-R1 locally. I came across LM Studio which allowed me run an AI model fully hosted on my PC within 10 minutes. Pretty amazing! I am using my mini PC UM780 XTX with AMD Ryzen 7 7840HS with 32GB of RAM.

This guide will show you how to set up an LLM using LM Studio. I’ll also highlight some popular CPU setups to match your hardware and throw in a quick comparison of top models—including the DeepSeek-R1 distilled series. Let’s get started!

Why Go Local with an LLM?

Running an LLM on your device means privacy, no subscription costs, and offline access. Plus, you can play with open-source models like a kid in a candy store and it is pretty cool!

What’s LM Studio?

LM Studio is a free, all-in-one app for Windows, macOS, and Linux that lets you run LLMs without diving into code (unless you want to). It grabs models from Hugging Face, offers a chat interface, and can even mimic OpenAI’s API locally. It’s optimised for your CPU, making it perfect for folks like me with a Ryzen 7 and no NVIDIA GPU.

Step-by-Step: Running an LLM with LM Studio

Here’s the playbook—I’ve tested it myself to keep it spot-on and straightforward.

1. Check Your Gear

Your computer needs to be up to the task. You can check the full system requirements here but here’s the baseline:

CPU : Modern, with AVX2 support (e.g., Intel Core i5 or AMD Ryzen 5 from the last 8-10 years) or any Apple Silicon (M1-M4—macOS-ready).
RAM : 16GB minimum for small models; 32GB+ is ideal for wiggle room.
Storage : SSD with 10-20GB free (models vary from a few GB to tens of GB).
GPU (Optional): NVIDIA with CUDA speeds things up, but CPU-only works fine—my Radeon 780M sits this one out 😢.

I’ll list some CPU configs later as reference to size up your rig.

2. Grab LM Studio

Head to lmstudio.ai, download the ~400MB installer for your OS, and run it. Follow the steps, launch the app, and you’re in.

3. Choose and Download a Model

Open LM Studio and hit the “Discover” tab (magnifying glass icon). It’ll suggest models your system can handle. Here are some stars to pick from:

Mistral 7B : Fast and flexible for everyday tasks (~8-10GB RAM, quantized).
LLaMA 3.1 8B : A powerhouse for chat and reasoning (~10-12GB RAM).
DeepSeek-R1-Distill-Qwen-7B : A distilled gem for math and logic (~8-12GB RAM).
Phi-3 Mini (3.8B): Tiny but mighty, perfect for light setups (~5-6GB RAM).

Click a model, pick a quantized version (like “Q4_K_M” to save memory), and hit “Download.” Bigger models take a bit, so maybe make some 🍵.

4. Load It Up and Chat

Switch to the “Chat” tab (speech bubble), select your model from the dropdown, and click “Load.” Your CPU will buzz for a sec as it loads into RAM. Once it’s ready, type something and watch it go.

6. Have Fun!

Boom—you’ve got an LLM at your command, offline and private. Test prompts, swap models, or use it to brainstorm. It’s your AI playground.

Comparing the Models

Not sure which model to choose? Here’s a quick rundown of my top picks, including DeepSeek-R1 distilled, based on size, speed, and smarts:

Model	Size	RAM	Speed	Best For
Mistral 7B	7B	8-10GB	8-12 t/s	Writing, Q&A
LLaMA 3.1 8B	8B	10-12GB	5-10 t/s	Chat, Reasoning
DeepSeek-R1 (Qwen-7B)	7B	8-12GB	6-12 t/s	Math, Coding
Phi-3 Mini	3.8B	5-6GB	10-15 t/s	Light Tasks

Winner? If you’re into reasoning or coding, grab DeepSeek-R1-Distill-Qwen-7B. For everyday chatting, LLaMA 3.1 8B is your pal. Mistral’s a speed demon, and Phi-3’s the lightweight champ.

Popular CPU Configurations and What They Can Run

Your CPU and RAM set the stage. Here’s what common setups can handle, checked against real benchmarks:

Entry-Level: Intel Core i5-12400 / AMD Ryzen 5 5600X / Apple M1 + 16GB RAM

Cores/Threads : 6/12 (Intel/AMD), 8/8 (M1)
Models : Phi-3 Mini, Mistral 7B (quantized)
Performance : ~8-12 tokens/sec for 7B
Notes : M1’s efficiency rocks; 16GB caps bigger models.

Mid-Range: Intel Core i7-12700 / AMD Ryzen 7 5800X / Apple M2 + 32GB RAM

Cores/Threads : 8/16 (Ryzen), 12/20 (Intel), 8/10 (M2)
Models : Mistral 7B, LLaMA 3.1 8B, DeepSeek-R1-Distill-Qwen-7B, Qwen-14B
Performance : ~5-10 tokens/sec for 7B-14B
Notes : M2’s neural engine kicks in; my Ryzen 7 7840HS (8/16) fits here—8B models fly.

High-End: Intel Core i9-13900K / AMD Ryzen 9 7950X / Apple M3 Max or M4 + 64GB RAM

Cores/Threads : 16-24/32 (Intel/AMD), 14/14 (M3 Max), 10-12/10-12 (M4 base)
Models : LLaMA 3.1 13B, DeepSeek-R1-Distill-Qwen-32B
Performance : ~3-8 tokens/sec for 13B-32B
Notes : M3 Max and M4 (10-12 cores) soar with macOS tweaks; 64GB tackles big models easy.

Tips to Nail It

Quantize Smart : Use 4-bit models (e.g., Q4_K_M) to fit more in RAM—they’re still sharp.
Free Up Space : Shut down Chrome or games to give your LLM breathing room.
Mix and Match : Download a few models—DeepSeek-R1 for logic, LLaMA for chats.
Troubleshoot : If it lags or crashes, check LM Studio’s logs for hints.

Final Thoughts

So this is how you run a LLM locally with LM Studio, it's SUPER COOL!!. With my Ryzen 7 and 32GB RAM, I’m loving DeepSeek-R1-Distill-Qwen-7B and LLaMA 3.1 8B.

Grab LM Studio and give DeepSeek-R1 a spin on your rig—I’d love to hear how it goes in the comments!

How to Log In to a Remote Linux Machine Using SSH Keys

Ali Shaikh — Sat, 22 Feb 2025 07:02:50 +0000

Photo by Jordan Harrison on Unsplash

SSH (Secure Shell) is a common way to securely connect to remote Linux machines. Instead of using passwords, SSH keys make logging in safer and easier. This guide will show you how to install an SSH server, create SSH keys, add your public key to the remote server and then connect using your SSH keys.

1. Installing the SSH Server

To enable SSH access, the remote Linux machine must have an SSH server installed.

For Debian-based Systems (e.g., Ubuntu)

sudo apt update
sudo apt install openssh-server -y
sudo systemctl enable ssh
sudo systemctl start ssh

For Red Hat-based Systems (e.g., CentOS, Rocky Linux)

sudo yum update -y
sudo yum install -y openssh-server
sudo systemctl enable sshd
sudo systemctl start sshd

Verify SSH Server is Running

sudo systemctl status ssh # For Ubuntu/Debian
sudo systemctl status sshd # For CentOS/RHEL

If the server is running you should see active (running) as shown below.

2. Generating SSH Keys on your Local Machine

SSH keys consist of a private key (kept secure on your local machine) and a public key (placed on the remote server). If you haven’t generated SSH keys before, check out this detailed guide:

🔗 Generating SSH Keys on Windows, Linux, and macOS

Once you’ve generated your SSH keys, proceed to the next step to configure the server for SSH key-based authentication by adding your public key to the remote server.

3. Adding your Public Key to the Remote Machine

Now, we need to copy the public key to the remote server so it can allow your key to be used to log in.

Copy your Public Key from the Local Machine

On your local machine, display the public key by running cat ~/.ssh/id_rsa.pub or opening the .pub file in Notepad, and copy the contents.

Prepare the Remote Server

On the remote machine, create the .ssh directory and authorized_keys file if they do not already exist.

mkdir -p ~/.ssh
touch ~/.ssh/authorized_keys

Add the Public Key to Authorized Keys

Paste the copied key into the ~/.ssh/authorized_keys file on the remote machine. If there's already another key in the file, make sure to add your key on a new line.

Alternatively, you can use echo command on the remote machine and append it directly:

echo "PASTE_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys

Set the correct permissions to ensure security:

Some systems will now allow you to use your SSH keys if the permissions are too open or incorrect. Run the following commands to set the recommended permissions.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

4. Connecting to the Remote Machine Using SSH Keys

Now that the remote machine is ready for SSH-based authentication and your public key has successfully been added, you can connect from your local machine:

ssh username@remote_host

If your private key exists in a non-default location, then provide the path to the private key by using the following command:

ssh -i /path/to/private_key username@remote_host

Conclusion

You have now set up your remote server for SSH access and learned how to log in securely using SSH keys, eliminating the need to enter a password each time. This method enhances security and convenience, making remote access more efficient. With SSH keys in place, you can now connect to your server seamlessly and focus on what matters most.

Cloning GitHub Repositories with SSH: A Step-by-Step Guide

Ali Shaikh — Tue, 18 Feb 2025 04:01:41 +0000

Photo by Roman Synkevych on Unsplash

In the previous guide, we learnt how to generate SSH Keys on Windows, Linux, and macOS, read here.

In this guide, we’ll explain how to use your SSH keys to clone GitHub repositories — a common task for developers working on projects locally. And remember, these SSH keys aren’t just for cloning; they also secure your push and pull operations.

Prerequisites

Before you begin, make sure:

SSH Key Pair: You have generated an SSH key pair, to learn how click here.
Git Installed: Git is installed on your system.
Internet Access: You can access GitHub.

Adding Your SSH Key to GitHub

Step 1: Copy Your Public Key

Your public key is typically stored in a file like ~/.ssh/id_ed25519.pub (or id_rsa.pub if you’re using RSA). You can simply display the key and copy it.

cat ~/.ssh/id_rsa.pub

OR

cat ~/.ssh/id_ed25519.pub

Step 2: Log in to Your GitHub Account

Open your web browser and navigate to GitHub.com. Log in with your credentials.

Step 3: Navigate to SSH Keys Settings

Click your profile icon in the top right corner and select ‘ Settings.’

In the left sidebar, click ‘ SSH and GPG keys.’

Step 4: Add a New SSH Key

Click on the “New SSH key” button.

Title: Enter a descriptive title (e.g., ‘My Laptop Key’).

Key: Paste the copied public key into the key field.

Click “Add SSH key.”

Cloning a Repository Using SSH

Now you are ready to enter the realm of passwordless authentication!

Step 1: Verify Your SSH Connection

Before cloning, verify that your SSH configuration is working:

ssh -T git@github.com

If it’s your first time connecting, you might be asked to confirm the authenticity of GitHub’s host. Type ‘ yes’ to continue.

If all goes well then you will see the following success message.

This means you are now good to go and use SSH to Clone GitHub repositories.

Step 2: Obtain the Repository’s SSH URL

Navigate to your repository on GitHub.
Click the ‘ Code’ button.
Select the ‘ SSH’ tab and copy the URL

Step 3: Clone the Repository

In your terminal, change to the directory where you want the repository and type ‘git clone’ followed by the ‘ SSH repository URL’ you copied earlier and hit enter.

Aaaand that's it! You have successfully learnt how to clone GitHub repositories without having to enter your username and password.

Conclusion

By following these steps, you’ve not only added your SSH key to GitHub but also learned how to clone repositories securely over SSH.

This method works seamlessly for all Git operations, including pushing new commits and pulling updates from remote repositories. You can follow the same steps to add your SSH keys in GitLab, BitBucket, and more.

This is a very convenient way of accessing Git repositories and will make your development workflows more efficient.

Happy coding!

In a future tutorial, we will learn how to SSH into a remote server.

Mastering Proxmox Automation: Build an Ubuntu 24.04 Cloud‑Init Template for Rapid VM Deployment

Ali Shaikh — Mon, 17 Feb 2025 04:01:44 +0000

Photo by Gabriel Heinzer on Unsplash

Recently I embarked on a journey to set up Kubernetes Cluster on my home lab running Proxmox. From my experience designing K8s architectures on AWS EKS and Azure AKS, I knew I would need to create multiple VMs so instead of having to create them 1 by 1 and repeating the same steps I decided to leverage automation and Cloud‑Init enabled VM templates to streamline the process.

How Cloud‑Init and Proxmox Automation Help

Cloud‑Init is a powerful tool designed for early initialisation of cloud instances. By leveraging Cloud‑Init with Proxmox, you can automate the initial configuration of your VMs, installing necessary packages, setting up SSH keys, and even pre-configuring network settings. Once the VM template is created, deploying new VMs becomes a matter of minutes rather than hours, ensuring that each instance is consistently configured and ready to run immediately.

More Automation Queue in Bash — Scripting 😍

Below is the Bash script that automates the entire process, streamlining the configuration and setup of your VM template. Why Type When You Can Script, Eh? 😏

#!/bin/bash

# VM and storage identifiers
VMID=10002
STORAGE=local-lvm

# Define the VM name and Ubuntu image parameters
VM_NAME="ubuntu-2404-cloudinit-template"
STORAGE="local-lvm" # Adjust if using a different storage backend
IMAGE_URL="https://cloud-images.ubuntu.com/daily/server/releases/24.04/release/ubuntu-24.04-server-cloudimg-amd64.img"
IMAGE_PATH="/var/lib/vz/template/iso/$(basename ${IMAGE_URL})"

# Cloud‑Init credentials (consider stronger hashing for production)
CI_USER="ubuntu"
CI_PASSWORD="$(openssl passwd -6 ubuntu)"

# Create an SSH public key file for injecting into the VM
echo "ssh-rsa PASTE YOUR PUBLIC KEY HERE" > ssh.pub

# 1. Download the Ubuntu 24.04 Cloud Image if not already present
if [! -f "${IMAGE_PATH}"]; then
  echo "Downloading Ubuntu 24.04 Cloud Image..."
  wget -P /var/lib/vz/template/iso/ "${IMAGE_URL}"
else
  echo "Image already exists at ${IMAGE_PATH}"
fi

set -x # Enable command echoing for debugging

# Destroy any existing VM with the same VMID to avoid conflicts
qm destroy $VMID 2>/dev/null || true

# Create a new VM with UEFI support and custom hardware configurations
echo "Creating VM ${VM_NAME} with VMID ${VMID}..."
qm create ${VMID} \
  --name "${VM_NAME}" \
  --ostype l26 \
  --memory 2048 \
  --cores 2 \
  --agent 1 \
  --bios ovmf --machine q35 --efidisk0 ${STORAGE}:0,pre-enrolled-keys=0 \
  --cpu host --socket 1 --cores 2 \
  --vga serial0 --serial0 socket \
  --net0 virtio,bridge=vmbr0

# Import the downloaded disk image into Proxmox storage
echo "Importing disk image..."
qm importdisk ${VMID} "${IMAGE_PATH}" ${STORAGE}

# Attach the imported disk as a VirtIO disk using the SCSI controller
qm set $VMID --scsihw virtio-scsi-pci --virtio0 $STORAGE:vm-${VMID}-disk-1,discard=on

# Resize the disk by adding an additional 8G
qm resize ${VMID} virtio0 +8G

# Configure the VM to boot from the VirtIO disk
qm set $VMID --boot order=virtio0

# Attach a Cloud‑Init drive (recommended on UEFI systems using SCSI)
qm set $VMID --scsi1 $STORAGE:cloudinit

# Create a custom Cloud‑Init configuration snippet
cat << EOF | tee /var/lib/vz/snippets/ubuntu.yaml
#cloud-config
runcmd:
    - apt-get update
    - apt-get install -y qemu-guest-agent htop
    - systemctl enable ssh
    - reboot
EOF

# Apply Cloud‑Init customizations and additional VM settings
qm set $VMID --cicustom "vendor=local:snippets/ubuntu.yaml"
qm set $VMID --tags ubuntu-template,noble,cloudinit
qm set ${VMID} --ciuser ${CI_USER} --cipassword "${CI_PASSWORD}"
qm set $VMID --sshkeys ~/ssh.pub
qm set $VMID --ipconfig0 ip=dhcp

# Finally, convert the configured VM into a template for rapid future deployment
echo "Converting VM to template..."
qm template ${VMID}

echo "Template ${VM_NAME} (VMID: ${VMID}) created successfully."

Make It Your Own

Before you run the script there are some things you would need to modify to tailor it to your environment. Here’s a quick rundown of the main components you might consider editing:

# VM and storage identifiers
VMID=10002
STORAGE=local-lvm

# Define the VM name and Ubuntu image parameters
VM_NAME="ubuntu-2404-cloudinit-template"
STORAGE="local-lvm" # Adjust if using a different storage backend
IMAGE_URL="https://cloud-images.ubuntu.com/daily/server/releases/24.04/release/ubuntu-24.04-server-cloudimg-amd64.img"
IMAGE_PATH="/var/lib/vz/template/iso/$(basename ${IMAGE_URL})"

# Cloud‑Init credentials (consider stronger hashing for production)
CI_USER="ubuntu"
CI_PASSWORD="$(openssl passwd -6 ubuntu)"

# Create an SSH public key file for injecting into the VM
echo "ssh-rsa PASTE YOUR PUBLIC KEY HERE" > ssh.pub

VM Identification & Naming: Customize the VMID and VM_NAME to assign a unique identifier and a descriptive name for your template.
Storage Settings: The STORAGE variable lets you define the backend storage (e.g., local-lvm, local-zfs). Adjust this parameter based on your storage setup.
Image Source & Path: The IMAGE_URL points to the cloud image you wish to use, while IMAGE_PATH determines where the image will be stored locally.
Cloud‑Init Credentials: Parameters like CI_USER and CI_PASSWORD are set to pre-configure the default login credentials. Please modify these as per your requirements.
SSH Key Injection: The script injects an SSH public key file for secure access to your VM, saving you the hassle of manually copying SSH keys after deployment. Please add your SSH key here echo "ssh-rsa PASTE YOUR PUBLIC KEY HERE" > ssh.pub. If you need to create a new SSH Key click here to learn how.

How to Use This Script

It’s really simple — just SSH into your Proxmox server, create a new file (e.g., create-ubuntu-2404-template.sh), paste the script into it, make it executable, and run it. The script handles everything for you, from downloading the Ubuntu image to converting the VM into a reusable template.

Here’s a step-by-step guide:

SSH into Your Proxmox Server: ssh your_user@proxmox-server-ip
Create the Script File: Use your preferred text editor to create a new file. For example, using Nano: nano create-ubuntu-2404-template.sh
Paste the script into this file, then save and exit the editor. In Nano, press Ctrl+O to save, then Ctrl+X to exit.
Make the Script Executable: Change the file permissions to make it executable: chmod +x create-ubuntu-2404-template.sh
Run the Script: Execute the script with: ./create

That’s it! With these commands, your Proxmox server will automatically handle downloading the Ubuntu image, setting up the VM, integrating Cloud‑Init, and converting the VM into a reusable template.

Profit!

Awesome! So now you have a shiny template ready to be used. You can use this template to create as many VMs as you want and you will have a brand new VM up and running in minutes. Now let's see how to use this template to create a new VM.

In this example, I will use the ‘ubuntu-2404-cloudinit-k8s-template’. Right-click on the template and click Clone. Fill in the VM ID and Name and click Clone.

Once the cloning is complete, the new VM will appear in your list. You can modify the hardware settings if required, then click Start. The VM will boot up, and Cloud‑Init will automatically perform the initial configuration tasks.

And voila, the VM is created.

In a future tutorial, we will look at how to configure the Cloud-Init configuration to set things like a new user, password, static IP etc. and also I will teach you how to create a Kubernetes-ready template so you can quickly set up as many nodes as you wish.

Feel free to leave any feedback, suggestions or your thoughts down in the comments.

Thank you!

Generating SSH Keys on Windows, Linux, and macOS

Ali Shaikh — Sat, 15 Feb 2025 16:24:28 +0000

Photo by Jakub Żerdzicki on Unsplash

SSH keys are a secure way to authenticate when connecting to remote servers and services such as GitHub Repositories. In this article, we’ll walk through the process of generating SSH keys on three popular operating systems: Windows, Linux, and macOS.

Why Use SSH Keys?

Using SSH keys enhances security by replacing less secure password authentication. Keys are generated as a pair: a public key (which you share with remote servers) and a private key (which you keep secret). Once set up, you can log into your servers or repositories with ease.

Generating SSH Keys on Windows

Install Git for Windows:

Download and install Git for Windows, which includes Git Bash—a command-line environment that supports SSH.
Open Git Bash:

Launch Git Bash from the Start menu.
Generate the Key Pair:

Replace email@cool-domain.com with your email address in the ssh-keygen command.

For example, you might run:

ssh-keygen -t rsa -b 4096 -C "email@cool-domain.com"

Explanation:

-t rsa: Specifies the type of key to create.
-b 4096: Sets the key size to 4096 bits for enhanced security.
-C "email@cool-domain.com": Adds a comment to help identify the key. This can be your email address, computer or device name, or any text that identifies what the key is for.

Follow the Prompts:

Press Enter to accept the default file location (typically C:\Users\{USERNAME}\.ssh\id_rsa). Choose a secure passphrase when prompted, or press Enter to continue without a passphrase.
Complete the Process:

After confirmation, your SSH key pair is created and stored in your user’s .ssh directory. Your public key will have a .pub extension. To view the public key, run:

cat ~/.ssh/id_rsa.pub

Generating SSH Keys on Windows

Using Git Bash

Install Git for Windows: Download and install Git for Windows, which includes Git Bash — a command-line environment that supports SSH.
Open Git Bash: Launch Git Bash from the Start menu.
Generate the Key Pair: Run the following command, replacing 'email@cool-domain.com' with your email address:

ssh-keygen -t rsa -b 4096 -C 'email@cool-domain.com'

-t rsa: Specifies the type of key to create.

-b 4096: Sets the key size to 4096 bits for enhanced security.

-C 'email@cool-domain.com': Adds a comment to help identify the key. This can be your email address, computer or device name or anything that lets you know what this key is for

Follow the Prompts: Press Enter to accept the default file location (typically C:\Users{USERNAME}.ssh\id_rsa). Choose a secure passphrase when prompted or press enter again to continue without a passphrase.
Complete the Process: After confirmation, your SSH key pair is created and stored in your user’s .ssh directory. Your public key will have a .pub extension. You can view the public key by running cat ~/.ssh/id_rsa.pub.

Generating SSH Keys on Linux

Using the Terminal

Open a Terminal Window: Most Linux distributions include a built-in terminal.
Generate the Key Pair: Enter the following command: ssh-keygen -t rsa -b 4096 -C 'email@cool-domain.com' command options are identical to those used in Windows.
Respond to Prompts: Press Enter to accept the default file location (typically ~/.ssh/id_rsa). Choose a secure passphrase when prompted or press enter again to continue without a passphrase.
Locate Your Keys: Your new SSH key pair will be stored in the ~/.ssh/ directory. You can view the public key using: cat ~/.ssh/id_rsa.pub

Generating SSH Keys on macOS

Using the Terminal

Open Terminal: Find Terminal in your Applications > Utilities folder, or use Spotlight to search for it.
Generate the Key Pair: Run the following command in the terminal: ssh-keygen -t rsa -b 4096 -C 'email@cool-domain.com'
Follow the Prompts: Press Enter to accept the default file location (typically ~/.ssh/id_rsa). Choose a secure passphrase when prompted or press enter again to continue without a passphrase.
Verify Your SSH Keys: To display your public key, type: cat ~/.ssh/id_rsa.pub.

Conclusion

Congratulations you have successfully learnt how to generate SSH key pairs. This is a fundamental skill for your IT Toolbox. Remember to keep your private key safe and secure. In a later tutorial, we will learn different ways we can use these keys to enhance your IT workflows.

I encourage you to share your thoughts and ask questions in the comments!

Thank you!

Upgrade AWS Elastic Beanstalk from PHP 7.4 to PHP 8.0

Ali Shaikh — Tue, 11 May 2021 16:28:09 +0000

Upgrade AWS Elastic Beanstalk from PHP 7.4 to PHP 8.0

The AWS Elastic Beanstalk Console currently only permits you to change between minor platform versions (e.g. from 64bit Amazon Linux 2 v3.1.6 running PHP 7.4 to 64bit Amazon Linux 2 v3.2.1 running PHP 7.4), but does not allow changes between major versions (e.g. from 64bit Amazon Linux 2 v3.2.1 running PHP 7.4 to 64bit Amazon Linux 2 v3.2.1 running PHP 8.0).

But, fret not!!! It is possible to update to a major platform version using the AWS Command Line Interface (CLI):

aws elasticbeanstalk update-environment --solution-stack-name "64bit Amazon Linux 2 v3.2.1 running PHP 8.0" --environment-id "x-xxxxxxxxxx" --region "us-west-1"

To find the newest PHP platform version AWS Elastic Beanstalk supports view the Elastic Beanstalk Supported Platforms.

For previous versions see the PHP Platform History.