diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index a8bdca88..15196ba6 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -59,6 +59,14 @@
 
 ## Documentation Preferences
 
+### Writing Style
+- **Terse and practical**: Every sentence must convey actionable or necessary information. Remove filler, marketing language, and motivational text.
+- **No fluff sections**: Do not include "What is X?", "Why use X?", "Benefits of X", "Key Features", or "Next Steps" sections. Readers already chose the tool — tell them how to use it.
+- **No troubleshooting sections**: Do not add generic troubleshooting or "Common Issues" sections to docs pages.
+- **Minimal repetition**: State a fact once. Cross-reference instead of restating. If two pages cover overlapping topics, consolidate into one and link.
+- **Lead with commands, config, and examples**: Tables, code blocks, CLI commands, and configuration snippets are preferred over prose explanations.
+- **Short introductions**: A page introduction should be one or two sentences stating what the page covers, then immediately begin the content.
+
 ### Diagrams and Visual Documentation
 - **Always use Mermaid diagrams** instead of ASCII art for workflow diagrams, architecture diagrams, and flowcharts
 - Use appropriate Mermaid diagram types:
@@ -67,10 +75,9 @@
   - `sequenceDiagram` for API interactions
   - `gitgraph` for branch/release strategies
 - Include styling with `classDef` for better visual hierarchy
-- Add descriptive comments and emojis sparingly for clarity
 
 ### Documentation Standards
-- Keep documentation DRY (Don't Repeat Yourself) - reference other docs instead of duplicating
+- Keep documentation DRY — reference other docs instead of duplicating content
 - Use clear cross-references between related documentation files
 - Update the main architecture document when workflow structure changes
 
diff --git a/.github/workflows/build-images.yml b/.github/workflows/build-images.yml
new file mode 100644
index 00000000..1f2b7374
--- /dev/null
+++ b/.github/workflows/build-images.yml
@@ -0,0 +1,76 @@
+name: Build and Push Images
+
+on:
+  push:
+    branches:
+      - '**'
+    tags:
+      - '**'
+    paths:
+      - 'images/**'
+  schedule:
+    # Run weekly on Sunday at 11:00 PM UTC (Sunday-Monday night depending on timezone)
+    - cron: '0 23 * * 0'
+  workflow_dispatch:
+
+env:
+  REGISTRY: ghcr.io
+
+jobs:
+  build-and-push:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Log in to GitHub Container Registry
+        uses: docker/login-action@v3
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Docker Meta (Base)
+        id: meta-base
+        uses: docker/metadata-action@v5
+        with:
+          images: ${{ env.REGISTRY }}/${{ github.repository }}/base
+          bake-target: base
+          tags: |
+            type=sha
+            type=ref,event=branch
+            type=ref,event=tag
+            type=raw,value=latest,enable=${{ github.ref == 'refs/heads/main' }}
+
+      - name: Docker Meta (NodeJS)
+        id: meta-nodejs
+        uses: docker/metadata-action@v5
+        with:
+          images: ${{ env.REGISTRY }}/${{ github.repository }}/nodejs
+          bake-target: nodejs
+          tags: |
+            type=sha
+            type=ref,event=branch
+            type=ref,event=tag
+            type=raw,value=latest,enable=${{ github.ref == 'refs/heads/main' }}
+
+      - name: Build and push
+        uses: docker/bake-action@v5
+        with:
+          workdir: ./images
+          push: true
+          files: |
+            ./docker-bake.hcl
+            ${{ steps.meta-base.outputs.bake-file }}
+            ${{ steps.meta-nodejs.outputs.bake-file }}
+          set: |
+            base.cache-from=type=gha,scope=base-${{ github.ref_name }}
+            base.cache-to=type=gha,mode=max,scope=base-${{ github.ref_name }}
+            nodejs.cache-from=type=gha,scope=nodejs-${{ github.ref_name }}
+            nodejs.cache-to=type=gha,mode=max,scope=nodejs-${{ github.ref_name }}
diff --git a/.github/workflows/build-templates.yml b/.github/workflows/build-templates.yml
deleted file mode 100644
index 80f76f06..00000000
--- a/.github/workflows/build-templates.yml
+++ /dev/null
@@ -1,47 +0,0 @@
-name: Build and Upload Templates
-on:
-  push:
-    paths:
-      - 'packer/**'
-  schedule:
-    - cron: "0 4 * * *"
-  workflow_dispatch:
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    env:
-      PROXMOX_API_URL: ${{ secrets.PROXMOX_API_URL }}
-      PROXMOX_TOKEN_ID: ${{ secrets.PROXMOX_TOKEN_ID }}
-      PROXMOX_TOKEN_SECRET: ${{ secrets.PROXMOX_TOKEN_SECRET }}
-
-    steps:
-      - uses: actions/checkout@v4
-
-      - name: Set TEMPLATE_VERSION
-        run: echo "TEMPLATE_VERSION=$(date +%Y%m%d)" >> $GITHUB_ENV
-
-      - name: Install dependencies
-        run: sudo apt-get update && sudo apt-get install -y packer ansible zstd python3-requests
-
-      - name: Build Debian 12 Template
-        run: |
-          packer build \
-            -var "template_version=${TEMPLATE_VERSION}" \
-            debian12.pkr.hcl
-      
-      - name: Upload Debian 12 Template
-        run: |
-          python3 api/proxmox_upload.py \
-            --file /tmp/output/debian12-fungible_${TEMPLATE_VERSION}.tar.xz
-
-      - name: Build Rocky 9 Template
-        run: |
-          packer build \
-            -var "template_version=${TEMPLATE_VERSION}" \
-            rocky9.pkr.hcl
-
-      - name: Upload Rocky 9 Template
-        run: |
-          python3 api/proxmox_upload.py \
-            --file /tmp/output/rocky9-fungible_${TEMPLATE_VERSION}.tar.xz
\ No newline at end of file
diff --git a/ci-cd-automation/README.md b/ci-cd-automation/README.md
deleted file mode 100644
index b8b97510..00000000
--- a/ci-cd-automation/README.md
+++ /dev/null
@@ -1 +0,0 @@
-# CI/CD Automation
\ No newline at end of file
diff --git a/ci-cd-automation/check-container-exists.sh b/ci-cd-automation/check-container-exists.sh
deleted file mode 100644
index ba0b2c9a..00000000
--- a/ci-cd-automation/check-container-exists.sh
+++ /dev/null
@@ -1,46 +0,0 @@
-#!/bin/bash
-# Script to check if a container exists, and if so, whether it needs to be updated or cloned.
-# Last Modified by Maxwell Klema on July 13th, 2025
-# -----------------------------------------------------
-
-outputError() {
-	echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-	echo -e "${BOLD}${MAGENTA}❌ Script Failed. Exiting... ${RESET}"
-	echo -e "$2"
-	echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-  exit $1
-}
-
-RESET="\033[0m"
-BOLD="\033[1m"
-MAGENTA='\033[35m'
-
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-echo -e "${BOLD}${MAGENTA}🔎 Check Container Exists ${RESET}"
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-
-TYPE_RUNNER="true"
-source /var/lib/vz/snippets/helper-scripts/PVE_user_authentication.sh
-source /var/lib/vz/snippets/helper-scripts/verify_container_ownership.sh
-
-STATUS=$?
-if [ "$STATUS" != 0 ]; then
-    exit 1;
-fi
-
-REPO_BASE_NAME=$(basename -s .git "$PROJECT_REPOSITORY")
-
-# Check if repository folder is present.
-if [ "$PVE1" == "true" ]; then
-    if [ ! -z "$CONTAINER_ID" ] && pct exec $CONTAINER_ID -- test -f /root/container-updates.log; then
-        exit 2; # Update Repository
-    else
-        exit 0; # Clone Repository
-    fi
-else
-    if [ ! -z "$CONTAINER_ID" ] && ssh 10.15.0.5 "pct exec $CONTAINER_ID -- test -f /root/container-updates.log" ; then
-        exit 2; # Update Repository
-    else
-        exit 0; # Clone Repository
-    fi
-fi
\ No newline at end of file
diff --git a/ci-cd-automation/delete-container.sh b/ci-cd-automation/delete-container.sh
deleted file mode 100644
index d46ce23b..00000000
--- a/ci-cd-automation/delete-container.sh
+++ /dev/null
@@ -1,29 +0,0 @@
-#!/bin/bash
-# Script to delete a container permanently
-# Last Modified by Maxwell Klema on July 13th, 2025
-# -----------------------------------------------------
-
-RESET="\033[0m"
-BOLD="\033[1m"
-MAGENTA='\033[35m'
-
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-echo -e "${BOLD}${MAGENTA}🗑️  Delete Container ${RESET}"
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-
-CMD=(
-bash /var/lib/vz/snippets/helper-scripts/delete-runner.sh
-"$PROJECT_REPOSITORY"
-"$GITHUB_PAT"
-"$PROXMOX_USERNAME"
-"$PROXMOX_PASSWORD"
-"$CONTAINER_NAME"
-)
-
-# Safely quote each argument for the shell
-QUOTED_CMD=$(printf ' %q' "${CMD[@]}")
-
-tmux new-session -d -s delete-runner "$QUOTED_CMD"
-
-echo "✅ Container with name \"$CONTAINER_NAME\" will be permanently deleted."
-exit 0 # Container Deleted Successfully
\ No newline at end of file
diff --git a/ci-cd-automation/helper-scripts/PVE_user_authentication.sh b/ci-cd-automation/helper-scripts/PVE_user_authentication.sh
deleted file mode 100755
index f2f07204..00000000
--- a/ci-cd-automation/helper-scripts/PVE_user_authentication.sh
+++ /dev/null
@@ -1,23 +0,0 @@
-#!/bin/bash
-# Script that checks if a user is authenticated in Proxmox PVE Realm @ opensource.mieweb.org 
-# Last Modified by Maxwell Klema on July 13th, 2025
-# -----------------------------------------------------
-
-# Authenticate User (Only Valid Users can Create Containers)
-
-if [ -z "$PROXMOX_USERNAME" ]; then
-	read -p  "Enter Proxmox Username →  " PROXMOX_USERNAME
-fi
-
-if [ -z "$PROXMOX_PASSWORD" ]; then
-	read -sp "Enter Proxmox Password →  " PROXMOX_PASSWORD
-	echo ""
-fi
-
-USER_AUTHENTICATED=$(ssh root@create-container "node /root/bin/js/runner.js authenticateUser \"$PROXMOX_USERNAME\" \"$PROXMOX_PASSWORD\"")
-
-if [ $USER_AUTHENTICATED == 'false' ]; then
-	outputError 1 "Your Proxmox account, $PROXMOX_USERNAME@pve, was not authenticated. Retry with valid credentials."
-fi
-
-echo "🎉 Your proxmox account, $PROXMOX_USERNAME@pve, has been authenticated"
\ No newline at end of file
diff --git a/ci-cd-automation/helper-scripts/create-template.sh b/ci-cd-automation/helper-scripts/create-template.sh
deleted file mode 100755
index 54d5e1ea..00000000
--- a/ci-cd-automation/helper-scripts/create-template.sh
+++ /dev/null
@@ -1,56 +0,0 @@
-#!/bin/bash
-# Creates a template of a LXC container
-# Last modified by Maxwell Klema on July 23rd, 2025.
-# --------------------------------------------------
-
-if [ "${DEPLOY_ON_START^^}" != "Y" ] || [ "${GH_ACTION^^}" != "Y" ]; then
-    return 0
-fi
-
-DEFAULT_BRANCH=$(curl -s https://api.github.com/repos/$REPO_BASE_NAME_WITH_OWNER/$REPO_BASE_NAME | jq -r '.default_branch')
-
-if [ "$DEFAULT_BRANCH" != "$PROJECT_BRANCH" ]; then
-    return 0
-fi
-
-echo "📝 Creating Container Template..."
-
-# Check if template already exists, and if it does, destroy it =====
-
-TEMPLATE_NAME="template-$REPO_BASE_NAME-$REPO_BASE_NAME_WITH_OWNER"
-TEMPLATE_CONTAINER_ID=$( { pct list; ssh root@10.15.0.5 'pct list'; } | awk -v name="$TEMPLATE_NAME" '$3 == name {print $1}')
-
-if [ ! -z "$TEMPLATE_CONTAINER_ID" ]; then
-    pct destroy $TEMPLATE_CONTAINER_ID | true
-fi
-
-# Clone LXC container and convert it into a template =====
-
-NEXT_ID=$(pvesh get /cluster/nextid)
-
-if (( $CONTAINER_ID % 2 == 101 )); then
-    ssh root@10.15.0.5 "
-    pct clone $CONTAINER_ID $NEXT_ID \
-        --hostname "$TEMPLATE_NAME" \
-        --full true
-    pct migrate $NEXT_ID intern-phxdc-pve1 --target-storage containers-pve1
-    " > /dev/null 2>&1
-else
-    pct clone $CONTAINER_ID $NEXT_ID \
-        --hostname "$TEMPLATE_NAME" \
-        --full true
-fi
-
-# AUTH_TOKEN_RESPONSE=$(curl --location --request POST https://api.github.com/repos/$REPO_BASE_NAME_WITH_OWNER/$REPO_BASE_NAME/actions/runners/registration-token --header "Authorization: token $GITHUB_PAT")
-# TOKEN=$(echo "$AUTH_TOKEN_RESPONSE" | jq -r '.token')
-
-# Remove rsa keys ====
-pct start $NEXT_ID
-pct enter $NEXT_ID <<EOF
-rm -rf /root/.ssh/id_rsa.pub && rm -rf /root/.ssh/id_rsa && \
-rm -rf /root/container-updates.log
-EOF
-
-pct stop $NEXT_ID
-pct set $NEXT_ID --tags "$PROXMOX_USERNAME"
-pct template $NEXT_ID
\ No newline at end of file
diff --git a/ci-cd-automation/helper-scripts/delete-runner.sh b/ci-cd-automation/helper-scripts/delete-runner.sh
deleted file mode 100755
index e1d2241f..00000000
--- a/ci-cd-automation/helper-scripts/delete-runner.sh
+++ /dev/null
@@ -1,46 +0,0 @@
-#!/bin/bash
-# Remove Github Runner Associated with Container (and Container itself too)
-
-PROJECT_REPOSITORY="$1"
-GITHUB_PAT="$2"
-PROXMOX_USERNAME="$3"
-PROXMOX_PASSWORD="$4"
-CONTAINER_NAME="$5"
-
-set -x 
-sleep 2
-
-# Delete Container
-
-CONTAINER_ID=$( { pct list; ssh root@10.15.0.5 'pct list'; } | awk -v name="$CONTAINER_NAME" '$3 == name {print $1}')
-echo "echo $CONTAINER_ID"
-
-if (( $CONTAINER_ID % 2 == 0 )); then
-    if ssh root@10.15.0.5 "pct status $CONTAINER_ID" | grep -q "status: running"; then
-        ssh root@10.15.0.5 "pct stop $CONTAINER_ID || true && pct destroy $CONTAINER_ID" > /dev/null 2>&1
-    else
-        ssh root@10.15.0.5 "pct destroy $CONTAINER_ID" > /dev/null 2>&1
-    fi
-else
-    if pct status "$CONTAINER_ID" | grep -q "status: running"; then
-        pct stop "$CONTAINER_ID" && pct destroy "$CONTAINER_ID" > /dev/null 2>&1
-    else
-        pct destroy "$CONTAINER_ID" > /dev/null 2>&1
-    fi
-fi
-
-source /usr/local/bin/prune_iptables.sh
-
-REPO_BASE_NAME=$(basename -s .git "$PROJECT_REPOSITORY")
-REPO_BASE_NAME_WITH_OWNER=$(echo "$PROJECT_REPOSITORY" | cut -d'/' -f4)
-
-RUNNERS=$(curl --location https://api.github.com/repos/$REPO_BASE_NAME_WITH_OWNER/$REPO_BASE_NAME/actions/runners --header "Authorization: token $GITHUB_PAT")
-
-while read -r RUNNER; do
-    RUNNER_NAME=$(echo "$RUNNER" | jq -r '.name')
-    if [ "$RUNNER_NAME" == "$CONTAINER_NAME" ]; then
-        RUNNER_ID=$(echo "$RUNNER" | jq -r '.id')
-        curl --location --request DELETE "https://api.github.com/repos/$REPO_BASE_NAME_WITH_OWNER/$REPO_BASE_NAME/actions/runners/$RUNNER_ID" \
-        --header "Authorization: token $GITHUB_PAT"
-    fi
-done < <(echo "$RUNNERS" | jq -c '.runners[]')
\ No newline at end of file
diff --git a/ci-cd-automation/helper-scripts/repository_status.sh b/ci-cd-automation/helper-scripts/repository_status.sh
deleted file mode 100755
index 5ec73b76..00000000
--- a/ci-cd-automation/helper-scripts/repository_status.sh
+++ /dev/null
@@ -1,37 +0,0 @@
-#!/bin/bash
-# Helper script to determine if container needs to clone repository or simply update it
-# Last Modified by Maxwell Klema on July 21st, 2025
-# -------------------------------------------------
-
-set +e
-TYPE_RUNNER="true"
-source /var/lib/vz/snippets/helper-scripts/PVE_user_authentication.sh
-source /var/lib/vz/snippets/helper-scripts/verify_container_ownership.sh
-
-STATUS=$?
-
-if [ "$STATUS" != 0 ]; then
-    exit 1;
-fi
-
-REPO_BASE_NAME=$(basename -s .git "$PROJECT_REPOSITORY")
-
-# Check if repository folder is present.
-
-if [ "$PVE1" == "true" ]; then
-    if pct exec $CONTAINER_ID -- test -d /root/$REPO_BASE_NAME; then
-        echo "Update"
-        exit 2; # Update Repository
-    else
-        echo "Clone"
-        exit 0; # Clone Repository
-    fi
-else
-    if ssh 10.15.0.5 "pct exec $CONTAINER_ID -- test -d /root/$REPO_BASE_NAME"; then
-        echo "Update"
-        exit 2; # Update Repository
-    else
-        echo "Clone"
-        exit 0; # Clone Repository
-    fi
-fi
\ No newline at end of file
diff --git a/ci-cd-automation/helper-scripts/verify_container_ownership.sh b/ci-cd-automation/helper-scripts/verify_container_ownership.sh
deleted file mode 100755
index f99849ae..00000000
--- a/ci-cd-automation/helper-scripts/verify_container_ownership.sh
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/bash
-# Script to verify container ownership based on name and CTID
-# Last Modified by Maxwell Klema on August 5th, 2025
-# -----------------------------------------------------
-
-CONTAINER_NAME="${CONTAINER_NAME,,}"
-CONTAINER_ID=$( { pct list; ssh root@10.15.0.5 'pct list'; } | awk -v name="$CONTAINER_NAME" '$3 == name {print $1}')
-
-if [ -z "$CONTAINER_ID" ]; then
-    echo "✅ Container with name \"$CONTAINER_NAME\" is available for use."
-    return 1
-fi
-
-CONTAINER_OWNERSHIP=$(ssh root@10.15.20.69 -- "jq '.\"$CONTAINER_NAME\".user' /etc/nginx/port_map.json")
-if [ "$TYPE_RUNNER" == "true" ] && (( $CONTAINER_ID % 2 == 0 )); then
-    PVE1="false"
-elif [ "$TYPE_RUNNER" == "true" ] && (( $CONTAINER_ID % 2 != 0 )); then
-    PVE1="true"
-fi
-
-if [ "$CONTAINER_OWNERSHIP" == "null" ]; then
-    echo "❌ You do not own the container with name \"$CONTAINER_NAME\"."
-    outputError 1 "You do not own the container with name \"$CONTAINER_NAME\"."
-fi
\ No newline at end of file
diff --git a/ci-cd-automation/setup-runner.sh b/ci-cd-automation/setup-runner.sh
deleted file mode 100644
index aaf9fafe..00000000
--- a/ci-cd-automation/setup-runner.sh
+++ /dev/null
@@ -1,141 +0,0 @@
-#!/bin/bash
-# A script for cloning a Distro template, installing, and starting a runner on it.
-# Last Modified by Maxwell Klema on August 5th, 2025
-# ------------------------------------------------
-
-outputError() {
-	echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-	echo -e "${BOLD}${MAGENTA}❌ Script Failed. Exiting... ${RESET}"
-	echo -e "$2"
-	echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-  exit $1
-}
-
-BOLD='\033[1m'
-RESET='\033[0m'
-
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-echo "🧬 Cloning a Template and installing a Runner"
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-
-# Validating Container Name =====
-
-source /var/lib/vz/snippets/helper-scripts/PVE_user_authentication.sh #Authenticate User
-source /var/lib/vz/snippets/helper-scripts/verify_container_ownership.sh #Ensure container does not exist.
-
-if [ ! -z "$CONTAINER_OWNERSHIP" ]; then
-    outputError 1 "You already own a container with name \"$CONTAINER_NAME\". Please delete it before creating a new one."
-fi
-
-# Cloning Container Template and Setting it up =====
-
-REPO_BASE_NAME=$(basename -s .git "$PROJECT_REPOSITORY")
-REPO_BASE_NAME_WITH_OWNER=$(echo "$PROJECT_REPOSITORY" | cut -d'/' -f4)
-
-TEMPLATE_NAME="template-$REPO_BASE_NAME-$REPO_BASE_NAME_WITH_OWNER"
-CTID_TEMPLATE=$( { pct list; ssh root@10.15.0.5 'pct list'; } | awk -v name="$TEMPLATE_NAME" '$3 == name {print $1}')
-
-case "${LINUX_DISTRIBUTION^^}" in
-  "") PACKAGE_MANAGER="apt-get" ;;
-  ROCKY)  PACKAGE_MANAGER="dnf" ;;
-esac
-
-# If no template ID was provided, assign a default based on distro
-
-if [ -z "$CTID_TEMPLATE" ]; then
-  case "${LINUX_DISTRIBUTION^^}" in
-    "") CTID_TEMPLATE="160" ;;
-    ROCKY)  CTID_TEMPLATE="138" ;;
-  esac
-fi
-
-if [ "${LINUX_DISTRIBUTION^^}" != "ROCKY" ]; then
-  LINUX_DISTRIBUTION="DEBIAN"
-fi
-
-REPO_BASE_NAME=$(basename -s .git "$PROJECT_REPOSITORY")
-REPO_BASE_NAME_WITH_OWNER=$(echo "$PROJECT_REPOSITORY" | cut -d'/' -f4)
-
-NEXT_ID=$(pvesh get /cluster/nextid) #Get the next available LXC ID
-
-# Create the Container Clone
-echo "⏳ Cloning Container..."
-pct clone $CTID_TEMPLATE $NEXT_ID \
-	--hostname $CONTAINER_NAME \
-	--full true > /dev/null 2>&1
-
-# Set Container Options
-echo "⏳ Setting Container Properties..."
-pct set $NEXT_ID \
-	--tags "$PROXMOX_USERNAME" \
-  --tags "$LINUX_DISTRIBUTION" \
-	--onboot 1 \
-	--cores 4 \
-  --memory 4096 > /dev/null 2>&1
-
-pct start $NEXT_ID > /dev/null 2>&1
-pveum aclmod /vms/$NEXT_ID --user "$PROXMOX_USERNAME@pve" --role PVEVMUser > /dev/null 2>&1
-
-sleep 5
-echo "⏳ DHCP Allocating IP Address..."
-CONTAINER_IP=$(pct exec $NEXT_ID -- hostname -I | awk '{print $1}')
-
-# Setting Up Github Runner =====
-
-# Get Temporary Token
-echo "🪙  Getting Authentication Token..."
-AUTH_TOKEN_RESPONSE=$(curl --location --request POST https://api.github.com/repos/$REPO_BASE_NAME_WITH_OWNER/$REPO_BASE_NAME/actions/runners/registration-token --header "Authorization: token $GITHUB_PAT" --write-out "HTTPSTATUS:%{http_code}" --silent)
-
-HTTP_STATUS=$(echo "$AUTH_TOKEN_RESPONSE" | grep -o "HTTPSTATUS:[0-9]*" | cut -d: -f2)
-AUTH_TOKEN_BODY=$(echo "$AUTH_TOKEN_RESPONSE" | sed 's/HTTPSTATUS:[0-9]*$//')
-
-if [ "$HTTP_STATUS" != "201" ]; then
-    outputError 1 "Failed to get GitHub authentication token. HTTP Status: $HTTP_STATUS\nResponse: $AUTH_TOKEN_BODY"
-fi
-
-TOKEN=$(echo "$AUTH_TOKEN_BODY" | jq -r '.token')
-
-pct enter $NEXT_ID <<EOF > /dev/null 2>&1
-rm -rf /root/container-updates.log || true && \
-cd /actions-runner && export RUNNER_ALLOW_RUNASROOT=1 && \
-runProcess=\$(ps aux | grep "[r]un.sh" | awk '{print \$2}' | head -n 1) && \
-if [ ! -z "\$runProcess" ]; then kill -9 \$runProcess || true; fi && \
-rm -rf .runner .credentials && rm -rf _work/* /var/log/runner/* 2>/dev/null || true && \
-export RUNNER_ALLOW_RUNASROOT=1 && \
-./config.sh --url $PROJECT_REPOSITORY --token $TOKEN --labels $CONTAINER_NAME --name $CONTAINER_NAME --unattended
-EOF
-
-# Generate RSA Keys =====
-
-echo "🔑 Generating RSA Key Pair..."
-pct exec $NEXT_ID -- bash -c "ssh-keygen -t rsa -N '' -f /root/.ssh/id_rsa -q"
-PUB_KEY=$(pct exec $NEXT_ID -- bash -c "cat /root/.ssh/id_rsa.pub")
-
-# Place public key in all necessary authorized_keys files
-echo "$PUB_KEY" >> /home/create-container/.ssh/authorized_keys
-echo "$PUB_KEY" >> /home/update-container/.ssh/authorized_keys
-echo "$PUB_KEY" >> /home/delete-container/.ssh/authorized_keys
-echo "$PUB_KEY" >> /home/container-exists/.ssh/authorized_keys
-
-echo "🔑 Creating Service File..."
-pct exec $NEXT_ID -- bash -c "cat <<EOF > /etc/systemd/system/github-runner.service
-[Unit]
-Description=GitHub Actions Runner
-After=network.target
-
-[Service]
-Type=simple
-WorkingDirectory=/actions-runner
-Environment=\"RUNNER_ALLOW_RUNASROOT=1\"
-ExecStart=/actions-runner/run.sh
-Restart=always
-
-[Install]
-WantedBy=multi-user.target
-EOF"
-
-pct exec $NEXT_ID -- systemctl daemon-reload
-pct exec $NEXT_ID -- systemctl enable github-runner
-pct exec $NEXT_ID -- systemctl start github-runner
-
-exit 3
diff --git a/ci-cd-automation/update-container.sh b/ci-cd-automation/update-container.sh
deleted file mode 100644
index 0be5e739..00000000
--- a/ci-cd-automation/update-container.sh
+++ /dev/null
@@ -1,324 +0,0 @@
-#!/bin/bash
-# Script to automatically fetch new contents from a branch, push them to container, and restart intern
-# Last Modified on August 17th, 2025 by Maxwell Klema
-# ----------------------------------------
-
-RESET="\033[0m"
-BOLD="\033[1m"
-MAGENTA='\033[35m'
-
-outputError() {
-	echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-	echo -e "${BOLD}${MAGENTA}❌ Script Failed. Exiting... ${RESET}"
-	echo -e "$2"
-	echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-  exit $1
-}
-
-
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-echo -e "${BOLD}${MAGENTA}🔄 Update Container Contents ${RESET}"
-echo -e "${BOLD}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${RESET}"
-
-if [ -z "${RUNTIME_LANGUAGE^^}" ]; then
-    echo "Skipping container update because there is nothing to update."
-    exit 0
-fi
-
-source /var/lib/vz/snippets/helper-scripts/PVE_user_authentication.sh
-source /var/lib/vz/snippets/helper-scripts/verify_container_ownership.sh
-
-# Get Project Details
-
-CONTAINER_NAME="${CONTAINER_NAME,,}"
-
-if [ -z "$PROJECT_REPOSITORY" ]; then
-    read -p "🚀 Paste the link to your project repository →  " PROJECT_REPOSITORY
-else
-    DEPLOY_ON_START="y"
-fi
-
-CheckRepository() {
-    PROJECT_REPOSITORY_SHORTENED=${PROJECT_REPOSITORY#*github.com/}
-    PROJECT_REPOSITORY_SHORTENED=${PROJECT_REPOSITORY_SHORTENED%.git}
-    REPOSITORY_EXISTS=$(curl -s -o /dev/null -w "%{http_code}" https://github.com/$PROJECT_REPOSITORY_SHORTENED)
-}
-
-CheckRepository
-
-if [ "$REPOSITORY_EXISTS" != "200" ]; then
-    outputError 1 "The repository link you provided, \"$PROJECT_REPOSITORY\" was not valid."
-fi
-
-echo "✅ The repository link you provided, \"$PROJECT_REPOSITORY\", was valid."
-
-# Get Project Branch
-
-if [ -z "$PROJECT_BRANCH" ]; then
-    PROJECT_BRANCH="main"
-fi
-
-REPOSITORY_BRANCH_EXISTS=$(curl -s -o /dev/null -w "%{http_code}" https://api.github.com/repos/$PROJECT_REPOSITORY_SHORTENED/branches/$PROJECT_BRANCH)
-
-if [ "$REPOSITORY_BRANCH_EXISTS" != "200" ]; then
-    outputError 1 "The branch you provided, \"$PROJECT_BRANCH\", does not exist on repository at \"$PROJECT_REPOSITORY\"."
-fi
-
-
-# Get Project Root Directroy
-
-if [ "$PROJECT_ROOT" == "." ] || [ -z "$PROJECT_ROOT" ]; then
-    PROJECT_ROOT="/"
-fi
-
-VALID_PROJECT_ROOT=$(ssh root@10.15.234.122 "node /root/bin/js/runner.js authenticateRepo \"$PROJECT_REPOSITORY\" \"$PROJECT_BRANCH\" \"$PROJECT_ROOT\"")
-
-if [ "$VALID_PROJECT_ROOT" == "false" ]; then
-    outputError 1 "The root directory you provided, \"$PROJECT_ROOT\", does not exist on branch, \"$PROJECT_BRANCH\", on repository at \"$PROJECT_REPOSITORY\"."
-fi
-
-REPO_BASE_NAME=$(basename -s .git "$PROJECT_REPOSITORY")
-REPO_BASE_NAME_WITH_OWNER=$(echo "$PROJECT_REPOSITORY" | cut -d'/' -f4)
-
-if [ "$PROJECT_ROOT" == "" ] || [ "$PROJECT_ROOT" == "/" ]; then
-    PROJECT_ROOT="."
-fi
-
-# Install Services ====
-
-echo "🛎️ Installing Services..."
-
-if [ -z "$LINUX_DISTRIBUTION" ]; then
-    LINUX_DISTRIBUTION="debian"
-fi
-
-if [ ! -z "$SERVICES" ] || [ ! -z "$CUSTOM_SERVICES" ]; then
-    REQUIRE_SERVICES="y"
-fi
-
-SERVICE_COMMANDS=$(ssh -o SendEnv="LINUX_DISTRIBUTION SERVICES CUSTOM_SERVICES REQUIRE_SERVICES" \
-    root@10.15.234.122 \
-   "/root/bin/deployment-scripts/gatherServices.sh true")
-
-echo "$SERVICE_COMMANDS" | while read -r line; do
-    pct exec $CONTAINER_ID -- bash -c "$line | true" > /dev/null 2>&1
-done
-
-# Change HTTP port if necessary ====
-
-if [ ! -z "$HTTP_PORT" ]; then
-    if [ "$HTTP_PORT" -lt 80 ] || [ "$HTTP_PORT" -gt 60000 ]; then
-        outputError 1 "Invalid HTTP port: $HTTP_PORT. Must be between 80 and 60000."
-    fi
-    ssh root@10.15.20.69 -- \
-"jq \ '.[\"$CONTAINER_NAME\"].ports.http = $HTTP_PORT' \
-    /etc/nginx/port_map.json > /tmp/port_map.json.new \
-    && mv -f /tmp/port_map.json.new /etc/nginx/port_map.json "
-fi
-
-# Clone repository if needed ====
-
-if (( "$CONTAINER_ID" % 2 == 0 )); then
-    ssh root@10.15.0.5 "
-        pct enter $CONTAINER_ID <<EOF
-if [ ! -d '/root/$REPO_BASE_NAME' ]; then
-cd /root && \
-git clone $PROJECT_REPOSITORY && cd $REPO_BASE_NAME/ && git checkout $PROJECT_BRANCH > /dev/null
-fi
-EOF
-    "
-else
-   pct enter $CONTAINER_ID <<EOF
-if [ ! -d '/root/$REPO_BASE_NAME' ]; then
-cd /root && \
-git clone $PROJECT_REPOSITORY && cd $REPO_BASE_NAME/ && git checkout $PROJECT_BRANCH > /dev/null
-fi
-EOF
-fi
-
-# Update Environment Variables
-
-if [ ! -z "$RUNTIME_LANGUAGE" ] && echo "$RUNTIME_LANGUAGE" | jq . >/dev/null 2>&1; then # If RUNTIME_LANGUAGE is set and is valid JSON
-    MULTI_COMPONENT="Y"
-fi
-
-# Helper Function to write environment variables to a file inside container
-writeEnvToFile() {
-    env_file_path="$1"
-    component_path="$2"
-    env_vars=$(cat "$env_file_path")
-    if (( $CONTAINER_ID % 2 == 0 )); then
-        ssh 10.15.0.5 "pct exec $CONTAINER_ID -- bash -c 'if [ ! -f \"$component_path/.env\" ]; then touch \"$component_path/.env\"; fi; echo \"$env_vars\" >> \"$component_path/.env\"'"
-    else
-        pct exec $CONTAINER_ID -- bash -c "if [ ! -f \"$component_path/.env\" ]; then touch \"$component_path/.env\"; fi; echo \"$env_vars\" >> \"$component_path/.env\""
-    fi
-}
-
-# Check If there are environment variables
-if [ ! -z "$CONTAINER_ENV_VARS" ]; then
-    # generate random temp .env folder to store all env files for different components
-    RANDOM_NUM=$(shuf -i 100000-999999 -n 1)
-    ENV_FOLDER="env_$RANDOM_NUM"
-    ENV_FOLDER_PATH="/var/lib/vz/snippets/container-env-vars/$ENV_FOLDER"
-    mkdir -p "$ENV_FOLDER_PATH"
-
-    if [ "${MULTI_COMPONENT^^}" == "Y" ]; then # Multi-Component
-        if echo "$CONTAINER_ENV_VARS" | jq -e > /dev/null 2>&1; then #if exit status of jq is 0 (valid JSON) // success
-            for key in $(echo "$CONTAINER_ENV_VARS" | jq -r 'keys[]'); do
-                COMPONENT_PATH="/root/$REPO_BASE_NAME/$PROJECT_ROOT/$key"
-                ENV_FILE_NAME=$(echo "$COMPONENT_PATH" | tr '/' '_')
-                ENV_FILE_NAME="$ENV_FILE_NAME.txt"
-                ENV_FILE_PATH="$ENV_FOLDER_PATH/$ENV_FILE_NAME"
-                touch "$ENV_FILE_PATH"
-                echo "$CONTAINER_ENV_VARS" | jq -r --arg key "$key" '.[$key] | to_entries[] | "\(.key)=\(.value)"' > "$ENV_FILE_PATH"
-                writeEnvToFile "$ENV_FILE_PATH" "$COMPONENT_PATH"
-            done
-        else
-            outputError "Your \"CONTAINER_ENV_VARS\" is not valid JSON. Please re-format and try again."
-            writeLog "Invalid JSON in CONTAINER_ENV_VARS (GH_ACTION mode)"
-            exit 16
-        fi
-    else # Single Component
-        ENV_FILE="env_$RANDOM_NUM.txt"
-        ENV_FILE_PATH="$ENV_FOLDER_PATH/$ENV_FILE"
-        touch "$ENV_FILE_PATH"
-        if echo "$CONTAINER_ENV_VARS" | jq -e > /dev/null 2>&1; then #if exit status of jq is 0 (valid JSON) // success
-            COMPONENT_PATH="/root/$REPO_BASE_NAME/$PROJECT_ROOT"
-            echo "$CONTAINER_ENV_VARS " | jq -r 'to_entries[] | "\(.key)=\(.value)"' > "$ENV_FILE_PATH" #k=v pairs
-            writeEnvToFile "$ENV_FILE_PATH" "$COMPONENT_PATH"
-        else
-            outputError "Your \"CONTAINER_ENV_VARS\" is not valid JSON. Please re-format and try again."
-            writeLog "Invalid JSON in CONTAINER_ENV_VARS for single component (GH_ACTION mode)"
-            exit 16
-        fi
-    fi
-fi
-
-# Update Container with New Contents from repository =====
-
-startComponentPVE1() {
-
-    RUNTIME="$1"
-    BUILD_CMD="$2"
-    START_CMD="$3"
-    COMP_DIR="$4"
-    INSTALL_CMD="$5"
-
-    if [ "${RUNTIME^^}" == "NODEJS" ]; then
-        pct set $CONTAINER_ID --memory 4096 --swap 0 --cores 4
-        pct exec $CONTAINER_ID -- bash -c "cd /root/$REPO_BASE_NAME/$PROJECT_ROOT/ && git fetch origin && git reset --hard origin/$PROJECT_BRANCH && git pull" > /dev/null 2>&1
-        pct exec $CONTAINER_ID -- bash -c "cd /root/$REPO_BASE_NAME/$PROJECT_ROOT/$COMP_DIR && $INSTALL_CMD && $BUILD_CMD" > /dev/null 2>&1
-        pct set $CONTAINER_ID --memory 2048 --swap 0 --cores 2
-    elif [ "${RUNTIME^^}" == "PYTHON" ]; then
-        pct set $CONTAINER_ID --memory 4096 --swap 0 --cores 4
-        pct exec $CONTAINER_ID -- bash -c "cd /root/$REPO_BASE_NAME/$PROJECT_ROOT/ && git fetch origin && git reset --hard origin/$PROJECT_BRANCH && git pull" > /dev/null 2>&1
-        pct exec $CONTAINER_ID -- bash -c "cd /root/$REPO_BASE_NAME/$PROJECT_ROOT/$COMP_DIR && source venv/bin/activate && $INSTALL_CMD && $BUILD_CMD" > /dev/null 2>&1
-        pct set $CONTAINER_ID --memory 2048 --swap 0 --cores 2
-    fi
-}
-
-startComponentPVE2() {
-
-    RUNTIME="$1"
-    BUILD_CMD="$2"
-    START_CMD="$3"
-    COMP_DIR="$4"
-    INSTALL_CMD="$5"
-
-    if [ "${RUNTIME^^}" == "NODEJS" ]; then
-        ssh root@10.15.0.5 "
-            pct set $CONTAINER_ID --memory 4096 --swap 0 --cores 4 &&
-            pct exec $CONTAINER_ID -- bash -c 'cd /root/$REPO_BASE_NAME/$PROJECT_ROOT/ && git fetch origin && git reset --hard origin/$PROJECT_BRANCH && git pull' > /dev/null 2>&1
-            pct exec $CONTAINER_ID -- bash -c 'cd /root/$REPO_BASE_NAME/$PROJECT_ROOT/$COMP_DIR && $INSTALL_CMD' && '$BUILD_CMD' > /dev/null 2>&1
-            pct set $CONTAINER_ID --memory 2048 --swap 0 --cores 2
-        "
-    elif [ "${RUNTIME^^}" == "PYTHON" ]; then
-        ssh root@10.15.0.5 "
-            pct set $CONTAINER_ID --memory 4096 --swap 0 --cores 4 &&
-            pct exec $CONTAINER_ID -- bash -c 'cd /root/$REPO_BASE_NAME/$PROJECT_ROOT && git fetch origin && git reset --hard origin/$PROJECT_BRANCH && git pull' > /dev/null 2>&1
-            pct exec $CONTAINER_ID -- bash -c 'cd /root/$REPO_BASE_NAME/$PROJECT_ROOT/$COMP_DIR && source venv/bin/activate && $INSTALL_CMD' && '$BUILD_CMD' > /dev/null 2>&1
-            pct set $CONTAINER_ID --memory 2048 --swap 0 --cores 2
-        "
-    fi
-}
-
-if [ "${MULTI_COMPONENT^^}" == "Y" ]; then
-    for COMPONENT in $(echo "$START_COMMAND" | jq -r 'keys[]'); do
-        START=$(echo "$START_COMMAND" | jq -r --arg k "$COMPONENT" '.[$k]')
-        RUNTIME=$(echo "$RUNTIME_LANGUAGE" | jq -r --arg k "$COMPONENT" '.[$k]')
-        BUILD=$(echo "$BUILD_COMMAND" | jq -r --arg k "$COMPONENT" '.[$k]')
-        INSTALL=$(echo "$INSTALL_COMMAND" | jq -r --arg k "$COMPONENT" '.[$k]')
-        if [ "$BUILD" == "null" ]; then
-            BUILD=""
-        fi
-
-        if (( "$CONTAINER_ID" % 2 == 0 )); then
-            startComponentPVE2 "$RUNTIME" "$BUILD" "$START" "$COMPONENT" "$INSTALL"
-        else
-            startComponentPVE1 "$RUNTIME" "$BUILD" "$START" "$COMPONENT" "$INSTALL"
-        fi
-    done
-    if [ ! -z "$ROOT_START_COMMAND" ]; then
-        if (( $CONTAINER_ID % 2 == 0 )); then
-            ssh root@10.15.0.5 "pct exec $CONTAINER_ID -- bash -c 'cd /root/$REPO_BASE_NAME/$PROJECT_ROOT && $ROOT_START_COMMAND'"
-        else
-            pct exec $CONTAINER_ID -- bash -c "cd /root/$REPO_BASE_NAME/$PROJECT_ROOT && $ROOT_START_COMMAND"
-        fi
-    fi
-    # startComponent "$RUNTIME_LANGUAGE" "$BUILD_COMMAND" "$START_COMMAND" "."
-else
-    if (( $CONTAINER_ID % 2 == 0 )); then
-        startComponentPVE2 "$RUNTIME_LANGUAGE" "$BUILD_COMMAND" "$START_COMMAND" "." "$INSTALL_COMMAND"
-        if [ ! -z "$ROOT_START_COMMAND" ]; then
-			ssh root@10.15.0.5 "pct exec $CONTAINER_ID -- bash -c 'cd /root/$REPO_BASE_NAME/$PROJECT_ROOT && $ROOT_START_COMMAND'" > /dev/null 2>&1
-		fi
-    else
-        startComponentPVE1 "$RUNTIME_LANGUAGE" "$BUILD_COMMAND" "$START_COMMAND" "." "$INSTALL_COMMAND"
-        if [ ! -z "$ROOT_START_COMMAND" ]; then
-			ssh root@10.15.0.5 "pct exec $CONTAINER_ID -- bash -c 'cd /root/$REPO_BASE_NAME/$PROJECT_ROOT && $ROOT_START_COMMAND'" > /dev/null 2>&1
-		fi
-    fi
-fi
-
-# Update Log File
-
-if (( "$CONTAINER_ID" % 2 == 0 )); then
-    ssh root@10.15.0.5 "pct exec $CONTAINER_ID -- bash -c 'echo \"[$(date)]\" >> /root/container-updates.log'"
-else
-    pct exec $CONTAINER_ID -- bash -c "echo \"[$(date)]\" >> /root/container-updates.log"
-fi
-
-# Create new template if on default branch =====
-
-UPDATE_CONTAINER="true"
-BUILD_COMMAND_B64=$(echo -n "$BUILD_COMMAND" | base64)
-RUNTIME_LANGUAGE_B64=$(echo -n "$RUNTIME_LANGUAGE" | base64)
-START_COMMAND_B64=$(echo -n "$START_COMMAND" | base64)
-
-CMD=(
-bash /var/lib/vz/snippets/start_services.sh
-"$CONTAINER_ID"
-"$CONTAINER_NAME"
-"$REPO_BASE_NAME"
-"$REPO_BASE_NAME_WITH_OWNER"
-"$SSH_PORT"
-"$CONTAINER_IP"
-"$PROJECT_ROOT"
-"$ROOT_START_COMMAND"
-"$DEPLOY_ON_START"
-"$MULTI_COMPONENT"
-"$START_COMMAND_B64"
-"$BUILD_COMMAND_B64"
-"$RUNTIME_LANGUAGE_B64"
-"$GH_ACTION"
-"$PROJECT_BRANCH"
-"$UPDATE_CONTAINER"
-)
-
-# Safely quote each argument for the shell
-QUOTED_CMD=$(printf ' %q' "${CMD[@]}")
-
-tmux new-session -d -s "$CONTAINER_NAME" "$QUOTED_CMD"
-echo "✅ Container $CONTAINER_ID has been updated with new contents from branch \"$PROJECT_BRANCH\" on repository \"$PROJECT_REPOSITORY\"."
-echo "Wait a few minutes for all background processes to complete before accessing the container."
-exit 0
diff --git a/create-a-container/bin/create-container.js b/create-a-container/bin/create-container.js
index b9bba84e..7686e68e 100755
--- a/create-a-container/bin/create-container.js
+++ b/create-a-container/bin/create-container.js
@@ -25,7 +25,6 @@
  */
 
 const path = require('path');
-const https = require('https');
 
 // Load models from parent directory
 const db = require(path.join(__dirname, '..', 'models'));
@@ -33,183 +32,7 @@ const { Container, Node, Site } = db;
 
 // Load utilities
 const { parseArgs } = require(path.join(__dirname, '..', 'utils', 'cli'));
-
-/**
- * Low-level HTTP GET that returns status, headers, and body without throwing on 4xx
- * @param {string} url - The URL to fetch
- * @param {object} headers - Optional request headers
- * @returns {Promise<{statusCode: number, headers: object, body: string}>}
- */
-function httpGet(url, headers = {}) {
-  return new Promise((resolve, reject) => {
-    const req = https.get(url, { headers }, (res) => {
-      let data = '';
-      res.on('data', chunk => data += chunk);
-      res.on('end', () => {
-        resolve({ statusCode: res.statusCode, headers: res.headers, body: data });
-      });
-    });
-    req.on('error', reject);
-  });
-}
-
-/**
- * Fetch JSON from a URL with optional headers (throws on non-2xx)
- * @param {string} url - The URL to fetch
- * @param {object} headers - Optional headers
- * @returns {Promise<object>} Parsed JSON response
- */
-async function fetchJson(url, headers = {}) {
-  const res = await httpGet(url, headers);
-  if (res.statusCode >= 400) {
-    throw new Error(`HTTP ${res.statusCode}: ${res.body}`);
-  }
-  return JSON.parse(res.body);
-}
-
-/**
- * Parse a WWW-Authenticate Bearer challenge header
- * Example: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/nginx:pull"
- * @param {string} header - The WWW-Authenticate header value
- * @returns {object|null} Parsed fields { realm, service, scope } or null if not Bearer
- */
-function parseWwwAuthenticate(header) {
-  if (!header || !header.startsWith('Bearer ')) return null;
-  const params = {};
-  const regex = /(\w+)="([^"]*)"/g;
-  let match;
-  while ((match = regex.exec(header)) !== null) {
-    params[match[1]] = match[2];
-  }
-  return params;
-}
-
-/**
- * Fetch JSON from a registry URL with automatic token authentication
- * Implements the Docker Registry Token Authentication spec:
- *   1. Attempt the request
- *   2. If 401, parse WWW-Authenticate for Bearer challenge
- *   3. Request a token from the auth service
- *   4. Retry with the Bearer token
- * @param {string} url - The registry URL to fetch
- * @param {object} headers - Optional request headers
- * @returns {Promise<object>} Parsed JSON response
- */
-async function authenticatedFetchJson(url, headers = {}) {
-  const res = await httpGet(url, headers);
-
-  if (res.statusCode === 200) {
-    return JSON.parse(res.body);
-  }
-
-  if (res.statusCode !== 401) {
-    throw new Error(`HTTP ${res.statusCode}: ${res.body}`);
-  }
-
-  // Parse the Bearer challenge from WWW-Authenticate header
-  const challenge = parseWwwAuthenticate(res.headers['www-authenticate']);
-  if (!challenge || !challenge.realm) {
-    throw new Error(`Registry returned 401 but no Bearer challenge in WWW-Authenticate header`);
-  }
-
-  // Build token request URL with query parameters from the challenge
-  const tokenUrl = new URL(challenge.realm);
-  if (challenge.service) tokenUrl.searchParams.set('service', challenge.service);
-  if (challenge.scope) tokenUrl.searchParams.set('scope', challenge.scope);
-
-  const tokenData = await fetchJson(tokenUrl.toString());
-  if (!tokenData.token) {
-    throw new Error('Auth service did not return a token');
-  }
-
-  // Retry the original request with the Bearer token
-  headers['Authorization'] = `Bearer ${tokenData.token}`;
-  const retryRes = await httpGet(url, headers);
-  if (retryRes.statusCode >= 400) {
-    throw new Error(`HTTP ${retryRes.statusCode} after auth: ${retryRes.body}`);
-  }
-  return JSON.parse(retryRes.body);
-}
-
-/**
- * Get the digest (sha256 hash) of a Docker/OCI image from the registry
- * Handles both single-arch and multi-arch (manifest list) images
- * @param {string} registry - Registry hostname (e.g., 'docker.io')
- * @param {string} repo - Repository (e.g., 'library/nginx')
- * @param {string} tag - Tag (e.g., 'latest')
- * @returns {Promise<string>} Short digest (first 12 chars of sha256)
- */
-async function getImageDigest(registry, repo, tag) {
-  const registryHost = registry === 'docker.io' ? 'registry-1.docker.io' : registry;
-  
-  // Fetch manifest with automatic registry auth challenge-response
-  const acceptHeaders = {
-    'Accept': [
-      'application/vnd.docker.distribution.manifest.v2+json',
-      'application/vnd.oci.image.manifest.v1+json',
-      'application/vnd.docker.distribution.manifest.list.v2+json',
-      'application/vnd.oci.image.index.v1+json'
-    ].join(', ')
-  };
-  
-  const manifestUrl = `https://${registryHost}/v2/${repo}/manifests/${tag}`;
-  let manifest = await authenticatedFetchJson(manifestUrl, { ...acceptHeaders });
-  
-  // Handle manifest list (multi-arch) - select amd64/linux
-  if (manifest.manifests && Array.isArray(manifest.manifests)) {
-    const amd64Manifest = manifest.manifests.find(m => 
-      m.platform?.architecture === 'amd64' && m.platform?.os === 'linux'
-    );
-    if (!amd64Manifest) {
-      throw new Error('No amd64/linux manifest found in manifest list');
-    }
-    
-    // Fetch the actual manifest for amd64 (reuse same auth flow)
-    const archHeaders = {
-      'Accept': 'application/vnd.docker.distribution.manifest.v2+json, application/vnd.oci.image.manifest.v1+json'
-    };
-    const archManifestUrl = `https://${registryHost}/v2/${repo}/manifests/${amd64Manifest.digest}`;
-    manifest = await authenticatedFetchJson(archManifestUrl, { ...archHeaders });
-  }
-  
-  // Get config digest from manifest
-  const configDigest = manifest.config?.digest;
-  if (!configDigest) {
-    throw new Error('No config digest in manifest');
-  }
-  
-  // Return short hash (sha256:abc123... -> abc123...)
-  const hash = configDigest.replace('sha256:', '');
-  return hash.substring(0, 12);
-}
-
-/**
- * Check if a template is a Docker image reference (contains '/')
- * @param {string} template - The template string
- * @returns {boolean} True if Docker image, false if Proxmox template
- */
-function isDockerImage(template) {
-  return template.includes('/');
-}
-
-/**
- * Parse a normalized Docker image reference into components
- * Format: host/org/image:tag
- * @param {string} ref - The normalized Docker reference
- * @returns {object} Parsed components: { registry, namespace, image, tag }
- */
-function parseDockerRef(ref) {
-  // Split off tag
-  const [imagePart, tag] = ref.split(':');
-  const parts = imagePart.split('/');
-  
-  // Format is always host/org/image after normalization
-  const registry = parts[0];
-  const image = parts[parts.length - 1];
-  const namespace = parts.slice(1, -1).join('/');
-  
-  return { registry, namespace, image, tag };
-}
+const { isDockerImage, parseDockerRef, getImageDigest } = require(path.join(__dirname, '..', 'utils', 'docker-registry'));
 
 /**
  * Generate a filename for a pulled Docker image
@@ -225,6 +48,62 @@ function generateImageFilename(parsed, digest) {
   return sanitized;
 }
 
+/**
+ * Setup ACL for container owner
+ * Grants PVEVMUser role to username@ldap on /vms/{vmid}
+ * Non-blocking: logs errors but continues on failure
+ * @param {ProxmoxApi} client - Proxmox API client
+ * @param {string} nodeName - Node name for logging
+ * @param {number} vmid - Container VMID
+ * @param {string} username - Container owner username
+ * @returns {Promise<boolean>} True if ACL created successfully, false otherwise
+ */
+async function setupContainerAcl(client, nodeName, vmid, username) {
+  const userWithRealm = `${username}@ldap`;
+  const aclPath = `/vms/${vmid}`;
+  
+  console.log(`Setting up ACL for ${userWithRealm} on ${aclPath}...`);
+  
+  try {
+    // Attempt to create ACL
+    await client.updateAcl(aclPath, 'PVEVMUser', null, true, null, userWithRealm);
+    console.log(`ACL created successfully: ${userWithRealm} -> PVEVMUser on ${aclPath}`);
+    return true;
+  } catch (firstError) {
+    console.log(`ACL creation failed: ${firstError.message}`);
+    
+    // Check if error is due to user not existing
+    const errorMsg = firstError.response?.data?.errors || firstError.message || '';
+    const isUserNotFound = errorMsg.toLowerCase().includes('user') && 
+                          (errorMsg.toLowerCase().includes('not found') || 
+                           errorMsg.toLowerCase().includes('does not exist'));
+    
+    if (isUserNotFound) {
+      console.log('User not found in Proxmox LDAP realm, attempting LDAP sync...');
+      
+      try {
+        // Sync LDAP realm
+        await client.syncLdapRealm('ldap');
+        console.log('LDAP realm sync completed successfully');
+        
+        // Retry ACL creation
+        console.log('Retrying ACL creation...');
+        await client.updateAcl(aclPath, 'PVEVMUser', null, true, null, userWithRealm);
+        console.log(`ACL created successfully after sync: ${userWithRealm} -> PVEVMUser on ${aclPath}`);
+        return true;
+      } catch (syncError) {
+        console.log(`LDAP sync or retry failed: ${syncError.message}`);
+        console.log('Continuing without ACL - container owner will need manual access grant');
+        return false;
+      }
+    } else {
+      console.log('ACL creation failed for non-user-related reason');
+      console.log('Continuing without ACL - container owner will need manual access grant');
+      return false;
+    }
+  }
+}
+
 /**
  * Main function
  */
@@ -446,6 +325,9 @@ async function main() {
       console.log('Environment/entrypoint configuration applied');
     }
     
+    // Setup ACL for container owner
+    await setupContainerAcl(client, node.name, vmid, container.username);
+    
     // Store the VMID now that creation succeeded
     await container.update({ containerId: vmid });
     console.log(`Container VMID ${vmid} stored in database`);
diff --git a/create-a-container/compose.ldap.env b/create-a-container/compose.ldap.env
new file mode 100644
index 00000000..397bf5d2
--- /dev/null
+++ b/create-a-container/compose.ldap.env
@@ -0,0 +1,10 @@
+LOG_LEVEL=debug
+DIRECTORY_BACKEND=sql
+REQUIRE_AUTH_FOR_SEARCH=false
+AUTH_BACKENDS=sql
+LDAP_COMMON_NAME=ldap
+LDAP_BASE_DN=dc=docker,dc=internal
+SQL_QUERY_ALL_USERS='SELECT "uid" AS username, "uidNumber" AS uid_number, "gidNumber" AS gid_number, "cn" AS full_name, "sn" AS last_name, "mail", "homeDirectory" AS home_directory, "userPassword" AS password, "givenName" as first_name FROM "Users"'
+SQL_QUERY_ONE_USER='SELECT "uid" AS username, "uidNumber" AS uid_number, "gidNumber" AS gid_number, "cn" AS full_name, "sn" AS last_name, "mail", "homeDirectory" AS home_directory, "userPassword" AS password, "givenName" as first_name FROM "Users" WHERE "uid" = ?'
+SQL_QUERY_ALL_GROUPS='SELECT g."cn" AS name, g."gidNumber" AS gid_number FROM "Groups" g'
+SQL_QUERY_GROUPS_BY_MEMBER='SELECT g."cn" AS name, g."gidNumber" AS gid_number FROM "Groups" g INNER JOIN "UserGroups" ug ON g."gidNumber" = ug."gidNumber" INNER JOIN "Users" u ON ug."uidNumber" = u."uidNumber" WHERE u."uid" = ?'
diff --git a/create-a-container/compose.yml b/create-a-container/compose.yml
index d3a6a344..8308c6c5 100644
--- a/create-a-container/compose.yml
+++ b/create-a-container/compose.yml
@@ -11,5 +11,11 @@ services:
     ports:
       - 5432:5432
 
+  ldap:
+    image: ghcr.io/mieweb/ldap-gateway:latest
+    env_file: compose.ldap.env
+    environment:
+      SQL_URI: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DATABASE}
+
 volumes:
-  postgres-data:
\ No newline at end of file
+  postgres-data:
diff --git a/create-a-container/routers/containers.js b/create-a-container/routers/containers.js
index 120003ea..ab2639da 100644
--- a/create-a-container/routers/containers.js
+++ b/create-a-container/routers/containers.js
@@ -7,6 +7,7 @@ const { requireAuth } = require('../middlewares');
 const ProxmoxApi = require('../utils/proxmox-api');
 const serviceMap = require('../data/services.json');
 const { isApiRequest } = require('../utils/http');
+const { parseDockerRef, getImageConfig, extractImageMetadata } = require('../utils/docker-registry');
 
 /**
  * Normalize a Docker image reference to full format: host/org/image:tag
@@ -54,6 +55,48 @@ function normalizeDockerRef(ref) {
   return `${host}/${org}/${image}:${tag}`;
 }
 
+// GET /sites/:siteId/containers/metadata - Fetch Docker image metadata
+router.get('/metadata', requireAuth, async (req, res) => {
+  try {
+    const { image } = req.query;
+    
+    if (!image || !image.trim()) {
+      return res.status(400).json({ error: 'Image parameter is required' });
+    }
+    
+    // Normalize the image reference
+    const normalizedImage = normalizeDockerRef(image.trim());
+    
+    // Parse into components
+    const parsed = parseDockerRef(normalizedImage);
+    const repo = `${parsed.namespace}/${parsed.image}`;
+    
+    // Fetch image config from registry
+    const config = await getImageConfig(parsed.registry, repo, parsed.tag);
+    
+    // Extract metadata
+    const metadata = extractImageMetadata(config);
+    
+    return res.json(metadata);
+  } catch (err) {
+    console.error('Error fetching image metadata:', err);
+    
+    let errorMessage = 'Failed to fetch image metadata';
+    if (err.message.includes('HTTP 404')) {
+      errorMessage = 'Image not found in registry';
+    } else if (err.message.includes('timeout')) {
+      errorMessage = 'Request timed out. Registry may be unavailable.';
+    } else if (err.message.includes('auth')) {
+      errorMessage = 'Authentication failed. Image may be private.';
+    }
+    
+    return res.status(500).json({ 
+      error: errorMessage,
+      details: err.message 
+    });
+  }
+});
+
 // GET /sites/:siteId/containers/new - List available templates via API or HTML form
 router.get('/new', requireAuth, async (req, res) => {
   const siteId = parseInt(req.params.siteId, 10);
@@ -67,38 +110,6 @@ router.get('/new', requireAuth, async (req, res) => {
     return res.redirect('/sites');
   }
   
-  // Get valid container templates from all nodes in this site
-  const templates = [];
-  const nodes = await Node.findAll({
-    where: {
-      [Sequelize.Op.and]: {
-        siteId,
-        apiUrl: { [Sequelize.Op.ne]: null },
-        tokenId: { [Sequelize.Op.ne]: null },
-        secret: { [Sequelize.Op.ne]: null }
-      }
-    },
-  });
-
-  for (const node of nodes) {
-    try {
-      const client = await node.api();
-      const lxcTemplates = await client.getLxcTemplates(node.name);
-      
-      for (const lxc of lxcTemplates) {
-        templates.push({
-          // Proxmox usually returns 'name' (filename) or 'volid'
-          name: lxc.name || lxc.volid, 
-          vmid: lxc.vmid,
-          size: lxc.size,
-          node: node.name
-        });
-      }
-    } catch (err) {
-      console.error(`Error fetching templates from node ${node.name}:`, err.message);
-    }
-  }
-
   // Get external domains for this site
   const externalDomains = await ExternalDomain.findAll({
     where: { siteId },
@@ -108,7 +119,6 @@ router.get('/new', requireAuth, async (req, res) => {
   if (isApi) {
     return res.json({
       site_id: site.id,
-      templates: templates, 
       domains: externalDomains
     });
   }
@@ -116,7 +126,6 @@ router.get('/new', requireAuth, async (req, res) => {
 
   return res.render('containers/form', { 
     site,
-    templates,
     externalDomains,
     container: undefined, 
     req 
@@ -687,4 +696,4 @@ router.delete('/:id', requireAuth, async (req, res) => {
   return res.redirect(`/sites/${siteId}/containers`);
 });
 
-module.exports = router;
\ No newline at end of file
+module.exports = router;
diff --git a/create-a-container/routers/register.js b/create-a-container/routers/register.js
index 6eb88cdc..e1afb524 100644
--- a/create-a-container/routers/register.js
+++ b/create-a-container/routers/register.js
@@ -61,15 +61,18 @@ router.post('/', async (req, res) => {
     status = 'pending'; // Regular registrations are pending
   }
   
+  const givenName = req.body.givenName.trim();
+  const sn = req.body.sn.trim();
+  
   const userParams = {
     uidNumber: await User.nextUidNumber(),
     uid: req.body.uid,
-    sn: req.body.sn,
-    givenName: req.body.givenName,
+    sn,
+    givenName,
     mail: req.body.mail,
     userPassword: req.body.userPassword,
     status,
-    cn: `${req.body.givenName} ${req.body.sn}`,
+    cn: `${givenName} ${sn}`,
     homeDirectory: `/home/${req.body.uid}`,
   };
 
diff --git a/create-a-container/routers/sites.js b/create-a-container/routers/sites.js
index 0824deae..cf1ea5aa 100644
--- a/create-a-container/routers/sites.js
+++ b/create-a-container/routers/sites.js
@@ -168,8 +168,9 @@ router.get('/:siteId/ldap.conf', requireLocalhost, async (req, res) => {
       ${qi.quoteIdentifier('uid')} AS username,
       ${qi.quoteIdentifier('uidNumber')} AS uid_number,
       ${qi.quoteIdentifier('gidNumber')} AS gid_number,
+      ${qi.quoteIdentifier('givenName')} AS first_name,
       ${qi.quoteIdentifier('cn')} AS full_name,
-      ${qi.quoteIdentifier('sn')} AS surname,
+      ${qi.quoteIdentifier('sn')} AS last_name,
       ${qi.quoteIdentifier('mail')},
       ${qi.quoteIdentifier('homeDirectory')} AS home_directory,
       ${qi.quoteIdentifier('userPassword')} AS password
diff --git a/create-a-container/routers/users.js b/create-a-container/routers/users.js
index a6afe0b0..3ca642c3 100644
--- a/create-a-container/routers/users.js
+++ b/create-a-container/routers/users.js
@@ -132,7 +132,10 @@ router.get('/:id/edit', async (req, res) => {
 // POST /users - Create a new user
 router.post('/', async (req, res) => {
   try {
-    const { uid, givenName, sn, mail, userPassword, status, groupIds } = req.body;
+    const { uid, givenName: rawGivenName, sn: rawSn, mail, userPassword, status, groupIds } = req.body;
+    
+    const givenName = rawGivenName.trim();
+    const sn = rawSn.trim();
     
     const user = await User.create({
       uidNumber: await User.nextUidNumber(),
@@ -178,7 +181,10 @@ router.put('/:id', async (req, res) => {
       return res.redirect('/users');
     }
 
-    const { uid, givenName, sn, mail, userPassword, status, groupIds } = req.body;
+    const { uid, givenName: rawGivenName, sn: rawSn, mail, userPassword, status, groupIds } = req.body;
+    
+    const givenName = rawGivenName.trim();
+    const sn = rawSn.trim();
     
     // Update user fields
     user.uid = uid;
diff --git a/create-a-container/utils/docker-registry.js b/create-a-container/utils/docker-registry.js
new file mode 100644
index 00000000..7afdc7b0
--- /dev/null
+++ b/create-a-container/utils/docker-registry.js
@@ -0,0 +1,380 @@
+/**
+ * docker-registry.js
+ * 
+ * Utility functions for interacting with Docker/OCI registries.
+ * Implements the Docker Registry HTTP API V2 specification.
+ * Supports automatic token-based authentication challenges.
+ */
+
+const https = require('https');
+
+/**
+ * Low-level HTTP GET that returns status, headers, and body without throwing on 4xx
+ * @param {string} url - The URL to fetch
+ * @param {object} headers - Optional request headers
+ * @returns {Promise<{statusCode: number, headers: object, body: string}>}
+ */
+function httpGet(url, headers = {}, redirectCount = 0) {
+  const MAX_REDIRECTS = 5;
+  
+  return new Promise((resolve, reject) => {
+    if (redirectCount > MAX_REDIRECTS) {
+      return reject(new Error('Too many redirects'));
+    }
+    
+    let timedOut = false;
+    const req = https.get(url, { headers }, (res) => {
+      // Handle redirects
+      if (res.statusCode === 301 || res.statusCode === 302 || res.statusCode === 307 || res.statusCode === 308) {
+        const location = res.headers.location;
+        if (!location) {
+          return reject(new Error(`Redirect without Location header (status ${res.statusCode})`));
+        }
+        // Follow redirect (without auth headers for CDN)
+        return httpGet(location, {}, redirectCount + 1)
+          .then(resolve)
+          .catch(reject);
+      }
+      
+      let data = '';
+      res.on('data', chunk => data += chunk);
+      res.on('end', () => {
+        if (timedOut) return;
+        resolve({ statusCode: res.statusCode, headers: res.headers, body: data });
+      });
+    });
+    req.on('error', (err) => {
+      if (!timedOut) reject(err);
+    });
+    req.setTimeout(120000, () => {
+      timedOut = true;
+      req.destroy();
+      reject(new Error('Request timeout after 120 seconds'));
+    });
+  });
+}
+
+/**
+ * Fetch JSON from a URL with optional headers (throws on non-2xx)
+ * @param {string} url - The URL to fetch
+ * @param {object} headers - Optional headers
+ * @returns {Promise<object>} Parsed JSON response
+ */
+async function fetchJson(url, headers = {}) {
+  const res = await httpGet(url, headers);
+  if (res.statusCode >= 400) {
+    throw new Error(`HTTP ${res.statusCode}: ${res.body}`);
+  }
+  if (!res.body || res.body.trim() === '') {
+    throw new Error('Empty response body');
+  }
+  try {
+    return JSON.parse(res.body);
+  } catch (err) {
+    throw new Error(`Failed to parse JSON: ${err.message}. Body: ${res.body.substring(0, 200)}`);
+  }
+}
+
+/**
+ * Parse a WWW-Authenticate Bearer challenge header
+ * Example: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/nginx:pull"
+ * @param {string} header - The WWW-Authenticate header value
+ * @returns {object|null} Parsed fields { realm, service, scope } or null if not Bearer
+ */
+function parseWwwAuthenticate(header) {
+  if (!header || !header.startsWith('Bearer ')) return null;
+  const params = {};
+  const regex = /(\w+)="([^"]*)"/g;
+  let match;
+  while ((match = regex.exec(header)) !== null) {
+    params[match[1]] = match[2];
+  }
+  return params;
+}
+
+/**
+ * Fetch JSON from a registry URL with automatic token authentication
+ * Implements the Docker Registry Token Authentication spec:
+ *   1. Attempt the request
+ *   2. If 401, parse WWW-Authenticate for Bearer challenge
+ *   3. Request a token from the auth service
+ *   4. Retry with the Bearer token
+ * @param {string} url - The registry URL to fetch
+ * @param {object} headers - Optional request headers
+ * @returns {Promise<object>} Parsed JSON response
+ */
+async function authenticatedFetchJson(url, headers = {}) {
+  const res = await httpGet(url, headers);
+
+  if (res.statusCode === 200) {
+    if (!res.body || res.body.trim() === '') {
+      throw new Error('Empty response body from registry');
+    }
+    try {
+      return JSON.parse(res.body);
+    } catch (err) {
+      throw new Error(`Failed to parse JSON response: ${err.message}`);
+    }
+  }
+
+  if (res.statusCode !== 401) {
+    throw new Error(`HTTP ${res.statusCode}: ${res.body}`);
+  }
+
+  // Parse the Bearer challenge from WWW-Authenticate header
+  const challenge = parseWwwAuthenticate(res.headers['www-authenticate']);
+  if (!challenge || !challenge.realm) {
+    throw new Error(`Registry returned 401 but no Bearer challenge in WWW-Authenticate header`);
+  }
+
+  // Build token request URL with query parameters from the challenge
+  const tokenUrl = new URL(challenge.realm);
+  if (challenge.service) tokenUrl.searchParams.set('service', challenge.service);
+  if (challenge.scope) tokenUrl.searchParams.set('scope', challenge.scope);
+
+  const tokenData = await fetchJson(tokenUrl.toString());
+  if (!tokenData.token) {
+    throw new Error('Auth service did not return a token');
+  }
+
+  // Retry the original request with the Bearer token
+  headers['Authorization'] = `Bearer ${tokenData.token}`;
+  const retryRes = await httpGet(url, headers);
+  if (retryRes.statusCode >= 400) {
+    throw new Error(`HTTP ${retryRes.statusCode} after auth: ${retryRes.body}`);
+  }
+  if (!retryRes.body || retryRes.body.trim() === '') {
+    throw new Error('Empty response body after auth');
+  }
+  try {
+    return JSON.parse(retryRes.body);
+  } catch (err) {
+    throw new Error(`Failed to parse authenticated response: ${err.message}`);
+  }
+}
+
+/**
+ * Check if a template is a Docker image reference (contains '/')
+ * @param {string} template - The template string
+ * @returns {boolean} True if Docker image, false if Proxmox template
+ */
+function isDockerImage(template) {
+  return template.includes('/');
+}
+
+/**
+ * Parse a normalized Docker image reference into components
+ * Format: host/org/image:tag
+ * @param {string} ref - The normalized Docker reference
+ * @returns {object} Parsed components: { registry, namespace, image, tag }
+ */
+function parseDockerRef(ref) {
+  // Split off tag
+  const [imagePart, tag] = ref.split(':');
+  const parts = imagePart.split('/');
+  
+  // Format is always host/org/image after normalization
+  const registry = parts[0];
+  const image = parts[parts.length - 1];
+  const namespace = parts.slice(1, -1).join('/');
+  
+  return { registry, namespace, image, tag };
+}
+
+/**
+ * Get the digest (sha256 hash) of a Docker/OCI image from the registry
+ * Handles both single-arch and multi-arch (manifest list) images
+ * @param {string} registry - Registry hostname (e.g., 'docker.io')
+ * @param {string} repo - Repository (e.g., 'library/nginx')
+ * @param {string} tag - Tag (e.g., 'latest')
+ * @returns {Promise<string>} Short digest (first 12 chars of sha256)
+ */
+async function getImageDigest(registry, repo, tag) {
+  const registryHost = registry === 'docker.io' ? 'registry-1.docker.io' : registry;
+  
+  // Fetch manifest with automatic registry auth challenge-response
+  const acceptHeaders = {
+    'Accept': [
+      'application/vnd.docker.distribution.manifest.v2+json',
+      'application/vnd.oci.image.manifest.v1+json',
+      'application/vnd.docker.distribution.manifest.list.v2+json',
+      'application/vnd.oci.image.index.v1+json'
+    ].join(', ')
+  };
+  
+  const manifestUrl = `https://${registryHost}/v2/${repo}/manifests/${tag}`;
+  let manifest = await authenticatedFetchJson(manifestUrl, { ...acceptHeaders });
+  
+  // Handle manifest list (multi-arch) - select amd64/linux
+  if (manifest.manifests && Array.isArray(manifest.manifests)) {
+    const amd64Manifest = manifest.manifests.find(m => 
+      m.platform?.architecture === 'amd64' && m.platform?.os === 'linux'
+    );
+    if (!amd64Manifest) {
+      throw new Error('No amd64/linux manifest found in manifest list');
+    }
+    
+    // Fetch the actual manifest for amd64 (reuse same auth flow)
+    const archHeaders = {
+      'Accept': 'application/vnd.docker.distribution.manifest.v2+json, application/vnd.oci.image.manifest.v1+json'
+    };
+    const archManifestUrl = `https://${registryHost}/v2/${repo}/manifests/${amd64Manifest.digest}`;
+    manifest = await authenticatedFetchJson(archManifestUrl, { ...archHeaders });
+  }
+  
+  // Get config digest from manifest
+  const configDigest = manifest.config?.digest;
+  if (!configDigest) {
+    throw new Error('No config digest in manifest');
+  }
+  
+  // Return short hash (sha256:abc123... -> abc123...)
+  const hash = configDigest.replace('sha256:', '');
+  return hash.substring(0, 12);
+}
+
+/**
+ * Fetch the image configuration blob from the registry
+ * Contains metadata like EXPOSE, ENV, ENTRYPOINT, CMD
+ * @param {string} registry - Registry hostname (e.g., 'docker.io')
+ * @param {string} repo - Repository (e.g., 'library/nginx')
+ * @param {string} tag - Tag (e.g., 'latest')
+ * @returns {Promise<object>} Image config object
+ */
+async function getImageConfig(registry, repo, tag) {
+  const registryHost = registry === 'docker.io' ? 'registry-1.docker.io' : registry;
+  
+  // First, fetch the manifest to get the config digest
+  const acceptHeaders = {
+    'Accept': [
+      'application/vnd.docker.distribution.manifest.v2+json',
+      'application/vnd.oci.image.manifest.v1+json',
+      'application/vnd.docker.distribution.manifest.list.v2+json',
+      'application/vnd.oci.image.index.v1+json'
+    ].join(', ')
+  };
+  
+  const manifestUrl = `https://${registryHost}/v2/${repo}/manifests/${tag}`;
+  let manifest = await authenticatedFetchJson(manifestUrl, { ...acceptHeaders });
+  
+  // Handle manifest list (multi-arch) - select amd64/linux
+  if (manifest.manifests && Array.isArray(manifest.manifests)) {
+    const amd64Manifest = manifest.manifests.find(m => 
+      m.platform?.architecture === 'amd64' && m.platform?.os === 'linux'
+    );
+    if (!amd64Manifest) {
+      throw new Error('No amd64/linux manifest found in manifest list');
+    }
+    
+    const archHeaders = {
+      'Accept': 'application/vnd.docker.distribution.manifest.v2+json, application/vnd.oci.image.manifest.v1+json'
+    };
+    const archManifestUrl = `https://${registryHost}/v2/${repo}/manifests/${amd64Manifest.digest}`;
+    manifest = await authenticatedFetchJson(archManifestUrl, { ...archHeaders });
+  }
+  
+  // Get config digest from manifest
+  const configDigest = manifest.config?.digest;
+  if (!configDigest) {
+    throw new Error('No config digest in manifest');
+  }
+  
+  // Fetch the config blob
+  const blobUrl = `https://${registryHost}/v2/${repo}/blobs/${configDigest}`;
+  const config = await authenticatedFetchJson(blobUrl);
+  
+  return config;
+}
+
+/**
+ * Extract metadata from image config for container creation
+ * @param {object} config - Raw image config from registry
+ * @returns {object} Structured metadata: { ports, httpServices, env, entrypoint }
+ */
+function extractImageMetadata(config) {
+  const metadata = {
+    ports: [],
+    httpServices: [],
+    env: {},
+    entrypoint: ''
+  };
+  
+  // Extract HTTP service from OCI labels first
+  // Label: org.mieweb.opensource-server.services.http.default-port
+  let httpServicePort = null;
+  if (config.config?.Labels) {
+    const httpPortLabel = config.config.Labels['org.mieweb.opensource-server.services.http.default-port'];
+    if (httpPortLabel) {
+      const port = parseInt(httpPortLabel, 10);
+      if (!isNaN(port) && port > 0 && port <= 65535) {
+        httpServicePort = port;
+        metadata.httpServices.push({
+          port: port
+        });
+      }
+    }
+  }
+  
+  // Extract exposed ports (excluding HTTP service port on TCP to avoid duplicates)
+  // Format: { "80/tcp": {}, "443/tcp": {}, "8080/udp": {} }
+  if (config.config?.ExposedPorts) {
+    for (const portSpec of Object.keys(config.config.ExposedPorts)) {
+      const [port, protocol = 'tcp'] = portSpec.split('/');
+      const portNum = parseInt(port, 10);
+      
+      // Skip if this port is designated as an HTTP service AND it's TCP
+      // (HTTP runs over TCP, but keep UDP ports even if same number)
+      if (portNum === httpServicePort && protocol.toLowerCase() === 'tcp') {
+        continue;
+      }
+      
+      metadata.ports.push({
+        port: portNum,
+        protocol: protocol.toLowerCase()
+      });
+    }
+  }
+  
+  // Extract environment variables
+  // Format: ["KEY1=value1", "KEY2=value2", "PATH=/usr/bin"]
+  const skipEnvVars = new Set(['PATH', 'HOME', 'HOSTNAME', 'TERM', 'USER']);
+  if (config.config?.Env && Array.isArray(config.config.Env)) {
+    for (const envStr of config.config.Env) {
+      const eqIndex = envStr.indexOf('=');
+      if (eqIndex > 0) {
+        const key = envStr.substring(0, eqIndex);
+        const value = envStr.substring(eqIndex + 1);
+        if (!skipEnvVars.has(key)) {
+          metadata.env[key] = value;
+        }
+      }
+    }
+  }
+  
+  // Extract and concatenate ENTRYPOINT + CMD
+  // Both are arrays of strings
+  const entrypointParts = [];
+  if (config.config?.Entrypoint && Array.isArray(config.config.Entrypoint)) {
+    entrypointParts.push(...config.config.Entrypoint);
+  }
+  if (config.config?.Cmd && Array.isArray(config.config.Cmd)) {
+    entrypointParts.push(...config.config.Cmd);
+  }
+  if (entrypointParts.length > 0) {
+    metadata.entrypoint = entrypointParts.join(' ');
+  }
+  
+  return metadata;
+}
+
+module.exports = {
+  httpGet,
+  fetchJson,
+  parseWwwAuthenticate,
+  authenticatedFetchJson,
+  isDockerImage,
+  parseDockerRef,
+  getImageDigest,
+  getImageConfig,
+  extractImageMetadata
+};
diff --git a/create-a-container/utils/proxmox-api.js b/create-a-container/utils/proxmox-api.js
index 505c8fbe..8a287a13 100644
--- a/create-a-container/utils/proxmox-api.js
+++ b/create-a-container/utils/proxmox-api.js
@@ -81,7 +81,7 @@ class ProxmoxApi {
    * @param {string} path 
    * @param {string} roles 
    * @param {string|null} groups 
-   * @param {boolean} propogate 
+   * @param {boolean} propagate 
    * @param {string|null} tokens 
    * @param {string|null} users 
    * @returns {Promise<void>}
@@ -94,6 +94,20 @@ class ProxmoxApi {
     );
   }
 
+  /**
+   * Sync LDAP realm to update user list from LDAP server
+   * @param {string} realm - The realm name (e.g., 'ldap')
+   * @returns {Promise<void>}
+   */
+  async syncLdapRealm(realm = 'ldap') {
+    const response = await axios.post(
+      `${this.baseUrl}/api2/json/access/domains/${realm}/sync`,
+      {},
+      this.options
+    );
+    return response.data.data;
+  }
+
   /**
    * Get the list of Proxmox Nodes
    * @returns {Promise<object>} - The API response data
diff --git a/create-a-container/views/containers/form.ejs b/create-a-container/views/containers/form.ejs
index e1d57637..af72f82a 100644
--- a/create-a-container/views/containers/form.ejs
+++ b/create-a-container/views/containers/form.ejs
@@ -38,13 +38,8 @@ const breadcrumbLabel = isEdit ? 'Edit' : 'New';
         <% } else { %>
           <select id="templateSelect" name="template" required>
             <option value="">Select a template...</option>
-            <% if (typeof templates !== 'undefined' && templates && templates.length > 0) { %>
-              <% templates.forEach(template => { %>
-                <option value="<%= template.node %>,<%= template.vmid %>">
-                  <%= template.name %> (<%= template.node %>)
-                </option>
-              <% }) %>
-            <% } %>
+            <option value="ghcr.io/mieweb/opensource-server/base:latest">Debian 13</option>
+            <option value="ghcr.io/mieweb/opensource-server/nodejs:latest">NodeJS 24</option>
             <option value="custom">Custom Docker Image...</option>
           </select>
           <div id="customTemplateContainer" style="display: none; margin-top: 8px;">
@@ -173,12 +168,22 @@ const breadcrumbLabel = isEdit ? 'Edit' : 'New';
   const customTemplateInput = document.getElementById('customTemplate');
   
   if (templateSelect) {
-    templateSelect.addEventListener('change', function() {
+    templateSelect.addEventListener('change', async function() {
       if (this.value === 'custom') {
         customTemplateContainer.style.display = 'block';
         customTemplateInput.required = true;
         this.removeAttribute('name'); // Don't submit the select value
+      } else if (this.value) {
+        // Standard image selected (not empty and not custom)
+        customTemplateContainer.style.display = 'none';
+        customTemplateInput.required = false;
+        customTemplateInput.value = '';
+        this.setAttribute('name', 'template'); // Submit select value
+        
+        // Fetch metadata for standard image
+        await fetchAndPopulateMetadata(this.value, this);
       } else {
+        // Empty selection
         customTemplateContainer.style.display = 'none';
         customTemplateInput.required = false;
         customTemplateInput.value = '';
@@ -187,6 +192,132 @@ const breadcrumbLabel = isEdit ? 'Edit' : 'New';
     });
   }
 
+  // Docker image metadata fetching
+  let metadataLoadTimeout = null;
+  let lastFetchedImage = '';
+  
+  // Reusable function to fetch metadata for any image reference
+  async function fetchAndPopulateMetadata(imageRef, sourceElement) {
+    // Skip if empty or already fetched
+    if (!imageRef || imageRef === lastFetchedImage) return;
+    
+    // Clear any pending timeout
+    if (metadataLoadTimeout) clearTimeout(metadataLoadTimeout);
+    
+    // Show loading indicator
+    const loadingMsg = document.createElement('small');
+    loadingMsg.style.color = '#666';
+    loadingMsg.style.display = 'block';
+    loadingMsg.style.marginTop = '4px';
+    loadingMsg.textContent = '🔄 Fetching image metadata...';
+    loadingMsg.id = 'metadataLoadingMsg';
+    sourceElement.parentElement.appendChild(loadingMsg);
+    
+    lastFetchedImage = imageRef;
+    
+    try {
+      const response = await fetch(`/sites/<%= site.id %>/containers/metadata?image=${encodeURIComponent(imageRef)}`);
+      
+      // Remove loading message
+      const existingMsg = document.getElementById('metadataLoadingMsg');
+      if (existingMsg) existingMsg.remove();
+      
+      if (!response.ok) {
+        const errorData = await response.json();
+        throw new Error(errorData.error || `HTTP ${response.status}`);
+      }
+      
+      const metadata = await response.json();
+      
+      // Show success message
+      const successMsg = document.createElement('small');
+      successMsg.style.color = '#28a745';
+      successMsg.style.display = 'block';
+      successMsg.style.marginTop = '4px';
+      successMsg.textContent = '✅ Metadata loaded successfully';
+      successMsg.id = 'metadataSuccessMsg';
+      sourceElement.parentElement.appendChild(successMsg);
+      
+      // Auto-dismiss success message after 3 seconds
+      metadataLoadTimeout = setTimeout(() => {
+        const msg = document.getElementById('metadataSuccessMsg');
+        if (msg) msg.remove();
+      }, 3000);
+      
+      // Populate form with metadata
+      populateMetadata(metadata);
+      
+    } catch (error) {
+      console.error('Error fetching metadata:', error);
+      
+      // Remove loading message if still present
+      const existingMsg = document.getElementById('metadataLoadingMsg');
+      if (existingMsg) existingMsg.remove();
+      
+      // Show error message
+      const errorMsg = document.createElement('small');
+      errorMsg.style.color = '#dc3545';
+      errorMsg.style.display = 'block';
+      errorMsg.style.marginTop = '4px';
+      errorMsg.textContent = `⚠️ Could not fetch metadata: ${error.message}`;
+      errorMsg.id = 'metadataErrorMsg';
+      sourceElement.parentElement.appendChild(errorMsg);
+      
+      // Auto-dismiss error message after 5 seconds
+      metadataLoadTimeout = setTimeout(() => {
+        const msg = document.getElementById('metadataErrorMsg');
+        if (msg) msg.remove();
+      }, 5000);
+    }
+  }
+  
+  // Handle custom Docker image input
+  if (customTemplateInput) {
+    customTemplateInput.addEventListener('blur', async function() {
+      const imageRef = this.value.trim();
+      await fetchAndPopulateMetadata(imageRef, this);
+    });
+  }
+  
+  function populateMetadata(metadata) {
+    // Clear existing auto-populated rows (not manually added ones)
+    // We'll just append to existing for now to avoid data loss
+    
+    // Pre-populate HTTP Services from OCI labels
+    if (metadata.httpServices && Array.isArray(metadata.httpServices)) {
+      for (const httpService of metadata.httpServices) {
+        // Use container hostname as the external hostname
+        const hostname = document.getElementById('hostname')?.value || '';
+        // Auto-select first domain if available
+        const firstDomainId = externalDomains.length > 0 ? externalDomains[0].id : '';
+        addServiceRow('http', httpService.port, hostname, firstDomainId);
+      }
+    }
+    
+    // Pre-populate Transport Services from EXPOSE directives
+    if (metadata.ports && Array.isArray(metadata.ports)) {
+      for (const portInfo of metadata.ports) {
+        const type = portInfo.protocol || 'tcp';
+        addServiceRow(type, portInfo.port);
+      }
+    }
+    
+    // Pre-populate Environment Variables
+    if (metadata.env && typeof metadata.env === 'object') {
+      for (const [key, value] of Object.entries(metadata.env)) {
+        addEnvVarRow(key, value);
+      }
+    }
+    
+    // Pre-populate Entrypoint
+    if (metadata.entrypoint) {
+      const entrypointField = document.getElementById('entrypoint');
+      if (entrypointField && !entrypointField.value) {
+        entrypointField.value = metadata.entrypoint;
+      }
+    }
+  }
+
   function addServiceRow(type = 'http', internalPort = '', externalHostname = '', externalDomainId = '', serviceId = null, externalPort = null, dnsName = '') {
     const row = document.createElement('tr');
     row.id = `service-row-${serviceCounter}`;
diff --git a/create-a-container/views/nginx-conf.ejs b/create-a-container/views/nginx-conf.ejs
index b4dbe4fc..318877fd 100644
--- a/create-a-container/views/nginx-conf.ejs
+++ b/create-a-container/views/nginx-conf.ejs
@@ -94,7 +94,7 @@ http {
       proxy_request_buffering off;
 
       # Allow large uploads
-      client_max_body_size 100M;
+      client_max_body_size 2G;
     }
     <%_ } else { _%>
     return 404;
@@ -160,7 +160,7 @@ http {
       proxy_request_buffering off;
       
       # Allow large uploads
-      client_max_body_size 100M;
+      client_max_body_size 2G;
     }
   }
   <%_ }) _%>
@@ -261,7 +261,7 @@ http {
       proxy_request_buffering off;
       
       # Allow large uploads
-      client_max_body_size 100M;
+      client_max_body_size 2G;
     }
   }
   <%_ }) _%>
diff --git a/images/base/Dockerfile b/images/base/Dockerfile
new file mode 100644
index 00000000..ca390800
--- /dev/null
+++ b/images/base/Dockerfile
@@ -0,0 +1,37 @@
+# syntax=docker/dockerfile:1
+# This first layer is only to build the root filesystem. We use Proxmox's
+# minimal Debian template as it is well maintained and optimized for LXC usage.
+FROM debian:13 AS builder
+RUN apt-get update && apt-get install -y \
+    curl tar zstd
+ARG URL=http://download.proxmox.com/images/system/debian-13-standard_13.1-2_amd64.tar.zst
+RUN mkdir /rootfs && curl "$URL" | tar --zstd -x -C /rootfs
+
+# Stage 2 of the build uses the root filesystem built in stage 1. The rest of
+# the Dockerfile builds from there.
+FROM scratch
+COPY --from=builder /rootfs /
+
+# Install and setup sssd autoconfiguration
+RUN apt-get update && \
+    apt-get install -y sssd sudo tmux curl git jq && \
+    pam-auth-update --enable mkhomedir && \
+    apt-get clean && \
+    rm -rf /var/lib/apt/lists/*
+COPY --chmod=0440 sssd.conf /etc/sssd/sssd.conf
+COPY --chmod=0440 ldapusers /etc/sudoers.d/ldapusers
+
+# The following service ensures environment variables set in the OCI metadata
+# or container configuration are passed to programs executed by systemd which
+# includes user sessions
+COPY environment.sh /usr/local/bin/environment.sh
+COPY environment.service /etc/systemd/system/environment.service
+RUN systemctl enable environment.service
+
+# Configure systemd to run properly in a container. This isn't nessary for LXC
+# in Proxmox, but is useful for testing with Docker directly.
+STOPSIGNAL SIGRTMIN+3
+ENTRYPOINT [ "/sbin/init" ]
+
+# Service metadata, includes port 22/tcp for automatic SSH exposure
+EXPOSE 22
diff --git a/images/base/environment.service b/images/base/environment.service
new file mode 100644
index 00000000..f6d1c801
--- /dev/null
+++ b/images/base/environment.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=Sync Container Environment and /etc/environment
+# Run before standard system initialization
+DefaultDependencies=no
+Before=sysinit.target
+# But after the rootfs is writable
+After=systemd-remount-fs.target
+
+[Service]
+Type=oneshot
+ExecStart=/usr/local/bin/environment.sh
+
+[Install]
+WantedBy=sysinit.target
diff --git a/images/base/environment.sh b/images/base/environment.sh
new file mode 100755
index 00000000..ed6d20db
--- /dev/null
+++ b/images/base/environment.sh
@@ -0,0 +1,7 @@
+#!/usr/bin/env bash
+# This script runs as root, reads PID 1's environment variables and inserts
+# them into /etc/environment. This allows the container runtime (LXC or Docker)
+# to set environment variables for system containers, that are then processed
+# by pam_env.so such that all processes in the container inhert those variables
+# We filter out certain variables that may cause issues with user sessions.
+</proc/1/environ tr '\0' '\n' | grep -vE '^(HOME)' >/etc/environment
diff --git a/images/base/ldapusers b/images/base/ldapusers
new file mode 100644
index 00000000..e8aa00dd
--- /dev/null
+++ b/images/base/ldapusers
@@ -0,0 +1,2 @@
+# enable passwordless sudo for all local ldap users
+%ldapusers ALL=(ALL) NOPASSWD: ALL
diff --git a/images/base/sssd.conf b/images/base/sssd.conf
new file mode 100644
index 00000000..3086ee24
--- /dev/null
+++ b/images/base/sssd.conf
@@ -0,0 +1,11 @@
+[sssd]
+domains = default
+
+[domain/default]
+id_provider = ldap
+auth_provider = ldap
+ldap_uri = ldaps://ldap1:636, ldaps://ldap2:636
+ldap_tls_reqcert = allow
+
+# set a timeout long enough for a push notification to be responded to
+ldap_opt_timeout = 60
diff --git a/images/docker-bake.hcl b/images/docker-bake.hcl
new file mode 100644
index 00000000..42000f5e
--- /dev/null
+++ b/images/docker-bake.hcl
@@ -0,0 +1,14 @@
+group "default" {
+    targets = ["base", "nodejs"]
+}
+
+target "base" {
+    context = "./base"
+}
+
+target "nodejs" {
+    context = "./nodejs"
+    contexts = {
+        base = "target:base"
+    }
+}
diff --git a/images/nodejs/Dockerfile b/images/nodejs/Dockerfile
new file mode 100644
index 00000000..9cc9d7f1
--- /dev/null
+++ b/images/nodejs/Dockerfile
@@ -0,0 +1,15 @@
+# syntax=docker/dockerfile:1
+FROM base
+
+# We install the binary release from NodeSource to get the most up-to-date
+# NodeJS releases.
+ARG NODE_MAJOR_VERSION=24
+RUN curl -fsSL https://deb.nodesource.com/setup_$NODE_MAJOR_VERSION.x | bash - && \
+    apt-get update && \
+    apt-get install -y nodejs && \
+    apt-get clean && \
+    rm -rf /var/lib/apt/lists/*
+
+# The following label is used by the frontend to determine the default port for
+# an HTTP service with the same name as the container.
+LABEL org.mieweb.opensource-server.services.http.default-port=3000
diff --git a/mie-opensource-landing/docs/admins/concepts.md b/mie-opensource-landing/docs/admins/concepts.md
deleted file mode 100644
index dc8a2eb2..00000000
--- a/mie-opensource-landing/docs/admins/concepts.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-sidebar_position: 2
----
-
-# Core Concepts
-
-Understanding the data model and organizational structure is essential for effectively administering the MIE Opensource Proxmox Cluster. This section covers the key concepts you'll work with daily.
-
-## Organizational Hierarchy
-
-The cluster management system is organized hierarchically:
-
-**Sites** → **Nodes** → **Containers**
-
-Each level serves a specific purpose in managing your infrastructure.
-
-## Key Concepts
-
-### [Users & Groups →](users-and-groups)
-
-User accounts and group-based permissions for access control and LDAP authentication.
-
-### [Sites →](sites)
-
-Top-level organization units that define network configuration and house nodes and containers.
-
-### [External Domains →](external-domains)
-
-Domain configuration for exposing HTTP services with automatic SSL/TLS certificate management.
-
-### [Nodes →](nodes)
-
-Individual Proxmox VE servers within a site that host containers.
-
-### [Containers →](containers)
-
-Linux containers (LXC) running on nodes - see the [User Documentation](/docs/users/creating-containers/web-gui) for creation guides.
-
----
-
-## Getting Started
-
-New administrators should configure these elements in order:
-
-1. **Users & Groups**: Set up your team's accounts and permissions
-2. **Sites**: Create your first site with network configuration
-3. **External Domains**: Configure domains for service exposure (optional)
-4. **Nodes**: Import or add your Proxmox nodes
-5. **Containers**: Begin deploying containers for your users
-
-Each concept page includes detailed explanations and step-by-step guides for using the web interface.
diff --git a/mie-opensource-landing/docs/admins/containers.md b/mie-opensource-landing/docs/admins/containers.md
deleted file mode 100644
index 75372db3..00000000
--- a/mie-opensource-landing/docs/admins/containers.md
+++ /dev/null
@@ -1,223 +0,0 @@
----
-sidebar_position: 7
----
-
-# Containers
-
-Containers are Linux containers (LXC) that run on Proxmox nodes within your site. This section provides an administrative overview of container management.
-
-## Container Overview
-
-From an administrator's perspective, containers are:
-- Lightweight virtualized environments running on Proxmox nodes
-- Assigned IP addresses from the site's DHCP range
-- Accessible via the built-in LDAP authentication system
-- Exposed to the internet via external domains (optional)
-
-## User Documentation
-
-Most container operations are performed by end users through the web interface or command line.
-
-### Creating Containers
-
-For detailed guides on creating and managing containers, see the User Documentation:
-
-- **[Web GUI Guide →](/docs/users/creating-containers/web-gui)**: Step-by-step container creation via web interface
-- **[Command Line Guide →](/docs/users/creating-containers/command-line)**: Creating containers via API with curl
-
-## Administrative Tasks
-
-As an administrator, you'll manage containers at a higher level:
-
-### Container Lifecycle
-
-- **Creation**: Users create containers, which are assigned IPs and configured automatically
-- **Running**: Containers run on assigned nodes with allocated resources
-- **Monitoring**: Track container resource usage and health
-- **Deletion**: Users or admins can delete containers to free resources
-
-### Resource Management
-
-Containers consume resources from their host node:
-- **CPU**: Virtual cores allocated to the container
-- **Memory**: RAM assigned from the node's available memory
-- **Storage**: Disk space from the node's storage pools
-- **Network**: IP addresses from the site's DHCP range
-
-:::tip Resource Monitoring
-Use the Proxmox web interface to monitor node resource usage and identify which containers are consuming the most resources.
-:::
-
-### Network Management
-
-Each container receives:
-- **IP Address**: Automatically assigned from the site's DHCP range
-- **DNS Name**: `container-name.INTERNAL_DOMAIN`
-- **Gateway**: Site's configured gateway
-- **DNS Servers**: Site's configured DNS forwarders
-
-### LDAP Authentication
-
-The built-in LDAP server provides authentication to all containers:
-- Users in the **ldapusers** group can SSH into any container
-- Credentials are synchronized automatically
-- Group memberships are reflected in container access
-
-## Container States
-
-Containers can be in various states:
-
-| State | Description | User Access |
-|-------|-------------|-------------|
-| **Running** | Container is active and accessible | Full access via SSH/web |
-| **Stopped** | Container is stopped but not deleted | No access |
-| **Creating** | Container is being provisioned | No access yet |
-| **Failed** | Creation or startup failed | No access |
-
-## Troubleshooting Containers
-
-### Container Won't Start
-
-Common causes:
-- Insufficient resources on the host node
-- Corrupted container filesystem
-- Network configuration issues
-- Storage pool problems
-
-**Check Proxmox logs:**
-```bash
-# On the Proxmox node
-pct list  # List all containers
-journalctl -u pve-container@CTID.service  # Check container logs
-```
-
-### User Can't Access Container
-
-Verify:
-- User status is **Active** (not Pending or Suspended)
-- User is member of **ldapusers** group
-- LDAP service is running on the management container
-- Container is running and network is configured correctly
-
-**Test LDAP authentication:**
-```bash
-# From the management container
-ldapsearch -x -H ldap://localhost -b "dc=cluster,dc=internal"
-```
-
-### Container Has No Network Connectivity
-
-Check:
-- Container has an IP address: `pct config CTID`
-- IP is within the site's DHCP range
-- Gateway is reachable from the container
-- DNS servers are configured correctly
-
-**Test from within the container:**
-```bash
-# SSH into the container
-ip addr  # Check IP address
-ip route  # Check gateway
-ping GATEWAY_IP  # Test gateway connectivity
-ping 8.8.8.8  # Test internet connectivity
-```
-
-### Container Using Too Many Resources
-
-To limit container resources:
-
-1. Open the Proxmox web interface
-2. Navigate to the container
-3. Go to **Resources** tab
-4. Adjust limits:
-   - CPU Cores
-   - CPU Limit
-   - Memory
-   - Swap
-
-Changes typically require restarting the container.
-
-## Service Exposure
-
-Users can expose HTTP services from containers using external domains:
-
-- Services are automatically configured with SSL/TLS certificates
-- Reverse proxy routes traffic from external domains to container services
-- DNS records are created automatically in Cloudflare
-
-See [External Domains](external-domains) for configuration details.
-
-## Backup and Recovery
-
-:::note Backup Strategies
-Container backup functionality depends on your Proxmox configuration. Refer to Proxmox documentation for setting up automated backups using:
-- Proxmox Backup Server
-- vzdump (built-in backup tool)
-- Storage replication
-:::
-
-### Manual Backup
-
-To manually backup a container:
-
-```bash
-# On the Proxmox node
-vzdump CTID --compress zstd --mode snapshot --dumpdir /path/to/backup
-```
-
-### Restoring a Container
-
-```bash
-# On the Proxmox node
-pct restore CTID /path/to/backup/vzdump-lxc-CTID-*.tar.zst
-```
-
-## Security Considerations
-
-### Container Isolation
-
-- Containers share the host kernel but are isolated from each other
-- Use LXC security features (AppArmor, seccomp) for additional isolation
-- Privileged containers should be avoided unless absolutely necessary
-
-### Access Control
-
-- Review user group memberships regularly
-- Audit LDAP access logs for unauthorized attempts
-- Suspend users immediately upon termination or security concerns
-
-### Network Security
-
-- Containers within a site can communicate with each other
-- Use Proxmox firewall rules to restrict inter-container traffic if needed
-- External services are exposed only when explicitly configured
-
-## Performance Optimization
-
-### Node Selection
-
-Distribute containers across nodes based on:
-- Current resource utilization
-- Workload characteristics (CPU-intensive vs. I/O-intensive)
-- Network proximity requirements
-
-### Resource Allocation
-
-- Allocate CPU and memory based on actual usage patterns
-- Use memory limits to prevent runaway processes
-- Monitor and adjust allocations over time
-
-### Storage Performance
-
-- Use faster storage (SSD/NVMe) for I/O-intensive containers
-- Consider separate storage pools for different workload types
-- Enable compression on storage to save space (if CPU allows)
-
-## Next Steps
-
-For more detailed container management:
-
-- Review [User Documentation](/docs/users/creating-containers/web-gui) for creation workflows
-- Set up monitoring for container health and resource usage
-- Configure automated backups in Proxmox
-- Review Proxmox documentation for advanced LXC features
diff --git a/mie-opensource-landing/docs/admins/core-concepts/_category_.json b/mie-opensource-landing/docs/admins/core-concepts/_category_.json
new file mode 100644
index 00000000..a041659c
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/core-concepts/_category_.json
@@ -0,0 +1,9 @@
+{
+  "label": "Core Concepts",
+  "position": 2,
+  "collapsed": false,
+  "link": {
+    "type": "doc",
+    "id": "admins/core-concepts/index"
+  }
+}
diff --git a/mie-opensource-landing/docs/admins/core-concepts/containers.md b/mie-opensource-landing/docs/admins/core-concepts/containers.md
new file mode 100644
index 00000000..1688190d
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/core-concepts/containers.md
@@ -0,0 +1,25 @@
+---
+sidebar_position: 7
+---
+
+# Containers
+
+Containers are LXC instances running on Proxmox nodes. For creating and managing containers, see the [Web GUI Guide](/docs/users/creating-containers/web-gui) or [Command Line Guide](/docs/users/creating-containers/command-line).
+
+## LDAP Authentication
+
+Users in the **ldapusers** group can SSH into any container using their cluster credentials. Group memberships and password changes propagate automatically.
+
+## Container States
+
+| State | Description |
+|-------|-------------|
+| **Running** | Active and accessible via SSH/web |
+| **Stopped** | Stopped but not deleted |
+| **Creating** | Being provisioned |
+| **Failed** | Creation or startup failed |
+
+## Service Exposure
+
+Users can expose HTTP services from containers using [external domains](external-domains). Services are automatically configured with SSL/TLS certificates, reverse proxy routing, and DNS records.
+
diff --git a/mie-opensource-landing/docs/admins/core-concepts/external-domains.md b/mie-opensource-landing/docs/admins/core-concepts/external-domains.md
new file mode 100644
index 00000000..7c53f451
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/core-concepts/external-domains.md
@@ -0,0 +1,58 @@
+---
+sidebar_position: 5
+---
+
+# External Domains
+
+External domains expose container HTTP services to the internet with automatic SSL/TLS certificate management via ACME (Let's Encrypt). Domains are associated with a site and available to all containers within it.
+
+## Prerequisites
+
+- A registered domain with Cloudflare DNS (only supported provider)
+- Cloudflare API token with **Zone:DNS:Edit** permissions
+
+## Domain Properties
+
+| Field | Description |
+|-------|-------------|
+| **Domain** | Top-level domain (e.g., `example.com`) |
+| **Site** | Associated site |
+| **ACME Email** | Certificate expiration notifications |
+| **ACME Directory** | CA endpoint (Let's Encrypt Production/Staging) |
+| **Cloudflare API Token** | For DNS-01 challenge authentication |
+
+:::tip
+Use Let's Encrypt **Staging** for testing — it has higher rate limits. Switch to **Production** once verified.
+:::
+
+:::warning
+If you don't configure ACME, you'll need to manage SSL certificates manually. Instructions for doing so are out-of-scope for this documentation.
+:::
+
+## Setup
+
+1. Add your domain to Cloudflare and update nameservers
+2. Create a Cloudflare API token with **Zone:DNS:Edit** permissions
+3. In the admin interface, navigate to **External Domains** → **Create New External Domain**
+4. Enter domain, ACME email, ACME directory, Cloudflare API token, and site
+5. Save — the system validates Cloudflare API access automatically
+
+## How It Works
+
+When a container exposes an HTTP service on an external domain:
+
+1. DNS-01 challenge created via Cloudflare API
+2. Certificate issued and auto-installed
+3. Certificates auto-renew before expiration (~every 60 days)
+4. DNS records and reverse proxy routing configured automatically
+
+## Using with Services
+
+When creating a container service, users select an external domain and specify a subdomain (e.g., `app` for `app.example.com`). DNS records, SSL certificates, and reverse proxy routing are all configured automatically. See the [Web GUI guide](/docs/users/creating-containers/web-gui) for details.
+
+## Security
+
+- Store Cloudflare API tokens with minimal permissions (Zone:DNS:Edit only)
+- Rotate tokens periodically; revoke immediately if compromised
+- Private keys never leave the cluster
+
diff --git a/mie-opensource-landing/docs/admins/core-concepts/index.md b/mie-opensource-landing/docs/admins/core-concepts/index.md
new file mode 100644
index 00000000..18213c04
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/core-concepts/index.md
@@ -0,0 +1,15 @@
+---
+sidebar_position: 0
+---
+
+# Core Concepts
+
+The cluster is organized: **Sites** → **Nodes** → **Containers**
+
+- **[Users & Groups](users-and-groups)** — Accounts, groups, LDAP authentication
+- **[Sites](sites)** — Network configuration, DHCP, DNS
+- **[External Domains](external-domains)** — Public domains with automatic SSL/TLS
+- **[Nodes](nodes)** — Proxmox VE servers within a site
+- **[Containers](containers)** — LXC instances on nodes ([user guide](/docs/users/creating-containers/web-gui))
+
+**Setup order:** Users & Groups → Sites → External Domains (optional) → Nodes → Containers
diff --git a/mie-opensource-landing/docs/admins/core-concepts/nodes.md b/mie-opensource-landing/docs/admins/core-concepts/nodes.md
new file mode 100644
index 00000000..6e0b414e
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/core-concepts/nodes.md
@@ -0,0 +1,59 @@
+---
+sidebar_position: 6
+---
+
+# Nodes
+
+Nodes are Proxmox VE servers within a site that host containers.
+
+## Node Properties
+
+- **Name**: Must exactly match the Proxmox hostname
+- **IP Address**: For internal DNS resolution
+- **API URL**: e.g., `https://192.168.1.10:8006/api2/json`
+- **Authentication**: Username/password or API token
+- **TLS Verification**: Enable/disable certificate validation
+
+## Adding Nodes
+
+### Import Nodes (Recommended)
+
+Discovers all nodes in a Proxmox cluster automatically:
+
+1. Navigate to **Nodes** → select site → **Import Nodes**
+2. Enter API URL of any node, credentials, and TLS setting
+3. Click **Import** — all cluster nodes are discovered and imported
+
+:::tip
+Import only needs credentials for one node. It discovers all other nodes in the same cluster.
+:::
+
+### Manual Node Creation
+
+1. Navigate to **Nodes** → select site → **Create New Node**
+2. Enter name (must match Proxmox hostname exactly), IP, API URL, and credentials
+
+:::important
+Name mismatches cause API communication failures.
+:::
+
+## Authentication
+
+Use `root@pam` credentials for both import and manual node creation. The Proxmox API requires root-level access to configure container settings needed for nested containerization.
+
+**Username & Password:**
+```
+Username: root@pam
+Password: your-root-password
+```
+
+## TLS Verification
+
+Proxmox uses self-signed certificates by default. Either disable TLS verification (acceptable for isolated networks) or install valid certificates from a trusted CA (recommended for production).
+
+## Managing Nodes
+
+- **Edit**: Update credentials or settings from the node detail page
+- **Delete**: Remove a node (must have no active containers first)
+- **Multi-node**: Proxmox supports HA features — see [Proxmox HA docs](https://pve.proxmox.com/wiki/High_Availability)
+
diff --git a/mie-opensource-landing/docs/admins/core-concepts/sites.md b/mie-opensource-landing/docs/admins/core-concepts/sites.md
new file mode 100644
index 00000000..67781330
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/core-concepts/sites.md
@@ -0,0 +1,36 @@
+---
+sidebar_position: 4
+---
+
+# Sites
+
+A site groups Proxmox nodes, defines network configuration, and manages container networking. Create at least one site before adding nodes.
+
+## Site Properties
+
+| Field | Description | Example |
+|-------|-------------|---------|
+| **Display Name** | Human-readable name | `Production Cluster` |
+| **Internal Domain** | DNS domain for internal network | `cluster.example.internal` |
+| **DHCP Range** | IP range for containers | `192.168.100.100-192.168.100.200` |
+| **Subnet Mask** | Network mask | `255.255.255.0` |
+| **Gateway IP** | Default gateway | `192.168.100.1` |
+| **DNS Forwarders** | Upstream DNS (comma-separated) | `8.8.8.8,1.1.1.1` |
+
+## Creating a Site
+
+1. Navigate to **Sites** → **Create New Site**
+2. Enter display name and internal domain
+3. Configure DHCP range, subnet mask, gateway, and DNS forwarders
+4. Save
+
+:::important
+Ensure the DHCP range doesn't conflict with static IPs (Proxmox nodes, management container, infrastructure devices).
+:::
+
+## DHCP and DNS
+
+- Containers automatically receive IPs from the DHCP range
+- Internal DNS resolves `container-name.INTERNAL_DOMAIN`
+- External queries forwarded to configured DNS forwarders
+- All records created/removed automatically with container lifecycle
diff --git a/mie-opensource-landing/docs/admins/core-concepts/users-and-groups.md b/mie-opensource-landing/docs/admins/core-concepts/users-and-groups.md
new file mode 100644
index 00000000..00171967
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/core-concepts/users-and-groups.md
@@ -0,0 +1,43 @@
+---
+sidebar_position: 3
+---
+
+# Users & Groups
+
+## Groups
+
+Groups organize users and define permissions. Two built-in groups:
+
+- **ldapusers**: LDAP authentication to all containers
+- **sysadmins**: Full admin access to Proxmox nodes and management software
+
+### Creating a Group
+
+Navigate to **Groups** → **Create New Group**. Required fields:
+- **Name**: LDAP common name (CN)
+- **GID**: Unique numeric Group ID
+- **Administrator**: Toggle for full admin privileges
+
+### Inviting Users
+
+Admins can invite users via email: **Users** → **Invite User** → enter email → **Send Invitation**.
+
+The recipient gets a secure link (expires in 24 hours). Registering via the link pre-fills and locks the email, and the account is **automatically activated**.
+
+:::important
+SMTP must be configured in [Settings](../settings) before sending invitations.
+:::
+
+## User Statuses
+
+| Status | Description |
+|--------|-------------|
+| **Pending** | Awaiting admin approval |
+| **Active** | Can authenticate to all cluster services |
+| **Suspended** | Access revoked |
+
+To approve: navigate to the user, change status to **Active**, optionally add to additional groups.
+
+## LDAP Integration
+
+Users in **ldapusers** can SSH into any container with their cluster credentials. GIDs, UIDs, and password changes are synchronized across all containers automatically.
diff --git a/mie-opensource-landing/docs/admins/external-domains.md b/mie-opensource-landing/docs/admins/external-domains.md
deleted file mode 100644
index 2e85ff50..00000000
--- a/mie-opensource-landing/docs/admins/external-domains.md
+++ /dev/null
@@ -1,211 +0,0 @@
----
-sidebar_position: 5
----
-
-# External Domains
-
-External domains enable you to expose HTTP/HTTPS services running in containers to the internet with automatic SSL/TLS certificate management.
-
-## What is an External Domain?
-
-An external domain is a public domain name (e.g., `example.com`) configured to:
-- Route traffic to services running in containers
-- Automatically obtain and renew SSL/TLS certificates via ACME (Let's Encrypt, etc.)
-- Support multiple services on subdomains
-
-External domains are associated with a specific site and can be used by any container within that site.
-
-## Prerequisites
-
-Before configuring an external domain, you need:
-
-- **A registered domain**: Ownership of a public domain name
-- **Cloudflare account**: Currently the only supported DNS provider for automatic certificate validation
-- **Cloudflare API credentials**: Token or API key for DNS-01 challenge authentication
-
-:::note DNS Provider Support
-Only Cloudflare is currently supported for automatic certificate management. If you use another DNS provider, you'll need to manage SSL certificates manually.
-:::
-
-## Domain Properties
-
-An external domain requires:
-
-### Basic Configuration
-
-- **Domain**: The top-level domain (e.g., `example.com` or `example.org`)
-- **Site**: The site this domain is associated with
-
-### ACME (Certificate Management)
-
-- **ACME Email**: Email address for certificate expiration notifications
-- **ACME Directory**: The certificate authority endpoint
-  - Let's Encrypt Production (recommended for live services)
-  - Let's Encrypt Staging (for testing)
-  - Other ACME-compatible providers
-
-- **Cloudflare API Token**: API credentials for DNS-01 challenge
-  - Can use either an API Token (recommended) or API Key
-
-:::tip ACME Directory Selection
-Use Let's Encrypt **Staging** initially to test your configuration. Staging has higher rate limits and won't count against production quotas. Switch to **Production** once verified.
-:::
-
-## Creating an External Domain
-
-### 1. Prepare Cloudflare
-
-Before adding the domain to the cluster:
-
-1. Add your domain to Cloudflare
-2. Update your domain registrar's nameservers to Cloudflare's nameservers
-3. Create a Cloudflare API token with **Zone:DNS:Edit** permissions for the domain
-
-:::important API Token Permissions
-The API token must have permission to create and delete DNS TXT records for the domain. This is required for the DNS-01 ACME challenge.
-:::
-
-### 2. Add Domain to Site
-
-1. Log in to the administration interface
-2. Navigate to **External Domains**
-3. Click **Create New External Domain**
-
-### 3. Configure Domain Settings
-
-Enter the configuration:
-
-**Example:**
-```
-Domain: example.com
-ACME Email: admin@example.com
-ACME Directory: Let's Encrypt Production
-Cloudflare API Token: [your-api-token]
-Site: Production Cluster
-```
-
-### 4. Save and Test
-
-1. Click **Save** to create the external domain
-2. The system will validate Cloudflare API access
-3. Certificates will be requested automatically when services are exposed
-
-## How Certificate Management Works
-
-When a container exposes an HTTP service using the external domain:
-
-1. The service is configured (e.g., `app.example.com`)
-2. The system initiates an ACME certificate request
-3. A DNS-01 challenge is created via Cloudflare API
-4. The certificate authority validates ownership via DNS
-5. Certificate is issued and automatically installed
-6. Certificate auto-renews before expiration (typically every 60 days)
-
-:::tip DNS-01 vs HTTP-01
-DNS-01 challenges work even when the service isn't publicly accessible yet, making them ideal for clustered environments. They also support wildcard certificates.
-:::
-
-## Using External Domains with Services
-
-When creating a service in a container, users can:
-
-1. Select the external domain from a dropdown
-2. Specify a subdomain (e.g., `app` for `app.example.com`)
-3. The system automatically:
-   - Creates DNS records in Cloudflare
-   - Requests SSL certificate via ACME
-   - Configures reverse proxy routing
-
-See the [User Documentation](/docs/users/creating-containers/web-gui) for details on exposing services.
-
-## Multiple External Domains
-
-You can configure multiple external domains per site:
-
-- Different top-level domains (e.g., `example.com` and `example.org`)
-- Development vs. production domains
-- Customer-specific domains in multi-tenant setups
-
-Each domain manages its own certificates and DNS configuration.
-
-## Supported ACME Directories
-
-Common ACME certificate authorities:
-
-| Provider | Directory URL | Rate Limits | Notes |
-|----------|--------------|-------------|-------|
-| **Let's Encrypt Production** | `https://acme-v02.api.letsencrypt.org/directory` | 50 certs/week per domain | Recommended for production |
-| **Let's Encrypt Staging** | `https://acme-staging-v02.api.letsencrypt.org/directory` | Higher limits | For testing only |
-| **ZeroSSL** | `https://acme.zerossl.com/v2/DV90` | Varies | Alternative CA |
-
-:::warning Rate Limits
-Let's Encrypt production has rate limits. Use staging for testing to avoid hitting limits during setup and debugging.
-:::
-
-## Security Considerations
-
-### API Token Security
-
-- Store Cloudflare API tokens securely
-- Use tokens with minimal required permissions (Zone:DNS:Edit only)
-- Rotate tokens periodically
-- Revoke tokens immediately if compromised
-
-### Certificate Management
-
-- Certificates are stored securely on the management container
-- Private keys never leave the cluster
-- Automatic renewal prevents expiration
-- Expiration notifications sent to ACME email address
-
-### DNS Security
-
-- Enable DNSSEC in Cloudflare for additional security
-- Monitor DNS changes for unauthorized modifications
-- Use Cloudflare's security features (WAF, DDoS protection)
-
-## Troubleshooting
-
-### Certificate Request Fails
-
-**Check Cloudflare API token:**
-```bash
-# Test API token access
-curl -X GET "https://api.cloudflare.com/client/v4/zones" \
-  -H "Authorization: Bearer YOUR_TOKEN"
-```
-
-**Common issues:**
-- Invalid or expired API token
-- Insufficient token permissions
-- Cloudflare nameservers not yet active for domain
-- Domain not added to Cloudflare account
-
-### DNS-01 Challenge Fails
-
-- Verify DNS propagation: `dig TXT _acme-challenge.example.com`
-- Check Cloudflare proxy status (should be DNS only for validation)
-- Ensure no conflicting DNS records exist
-- Wait for DNS propagation (can take minutes to hours)
-
-### Rate Limit Exceeded
-
-If you hit Let's Encrypt rate limits:
-- Switch to staging directory for testing
-- Wait for rate limit window to reset (weekly for most limits)
-- Consider using a different subdomain for testing
-
-### Certificate Not Renewing
-
-- Check ACME email for renewal failure notifications
-- Verify Cloudflare API token is still valid
-- Check system logs for renewal errors
-- Manually trigger renewal if needed
-
-## Next Steps
-
-After configuring external domains:
-
-1. **[Nodes](nodes)**: Import your Proxmox nodes
-2. **[Containers](containers)**: Deploy containers and expose services
-3. Review the [User Documentation](/docs/users/creating-containers/web-gui) for service exposure guides
diff --git a/mie-opensource-landing/docs/admins/index.md b/mie-opensource-landing/docs/admins/index.md
index ceebf7e1..71b8f5fb 100644
--- a/mie-opensource-landing/docs/admins/index.md
+++ b/mie-opensource-landing/docs/admins/index.md
@@ -4,43 +4,6 @@ sidebar_position: 1
 
 # Administrator Documentation
 
-Welcome to the administrator documentation for the MIE Opensource Proxmox Cluster management system.
-
-## Getting Started
-
-New to managing this cluster? Start here:
-
-### [Installation Guide →](installation)
-
-Complete step-by-step instructions for:
-- Setting up Proxmox VE 13+
-- Deploying the management container
-- Configuring network access
-- Creating your first administrator account
-
-### [Core Concepts →](concepts)
-
-Understanding the architecture and key concepts:
-- Cluster organization and nodes
-- User roles and permissions
-- Container lifecycle management
-- Service exposure strategies
-
-## What You'll Find Here
-
-This section provides comprehensive guides for:
-
-- **Installation & Setup**: Deploy and configure the cluster management system
-- **Node Management**: Add, configure, and maintain Proxmox nodes
-- **User Administration**: Manage accounts, permissions, and access control
-- **System Settings**: Configure system-wide features like two-factor authentication
-- **Network Configuration**: Set up networking, ports, and service exposure
-- **Monitoring & Maintenance**: Keep your cluster healthy and performant
-- **Security**: Best practices for securing your infrastructure
-- **Troubleshooting**: Diagnose and resolve common issues
-
----
-
-:::tip First Time Here?
-Follow the [Installation Guide](installation) to get your cluster management system up and running.
-:::
+- **[Installation Guide →](installation)** — Deploy and configure the management system
+- **[Core Concepts →](core-concepts)** — Cluster organization, user roles, container lifecycle
+- **[Deploying LDAP Servers →](ldap-servers)** — Set up ldap1/ldap2 for container authentication
diff --git a/mie-opensource-landing/docs/admins/installation.md b/mie-opensource-landing/docs/admins/installation.md
index c1dfe91f..cfcc24ec 100644
--- a/mie-opensource-landing/docs/admins/installation.md
+++ b/mie-opensource-landing/docs/admins/installation.md
@@ -4,147 +4,53 @@ sidebar_position: 1
 
 # Installation Guide
 
-This guide walks you through installing and configuring the MIE Opensource Proxmox Cluster management system on your Proxmox VE infrastructure.
-
 ## Prerequisites
 
-### System Requirements
-
-- **Proxmox VE 13 or higher**: Required for OCI (Open Container Initiative) image support
-- **Isolated Network**: A network segment dedicated to the Proxmox cluster with no existing DHCP infrastructure
-- **Network Access**: Ability to connect to the Proxmox host via:
-  - SSH (typically port-forwarded)
-  - Web UI on 8006/tcp (typically port-forwarded)
-
-### Before You Begin
-
-Ensure you have:
-- Administrative access to your Proxmox VE cluster
-- Network connectivity to reach the Proxmox management interface
-- A subnet range allocated for the cluster (the management container will need a static IP in this range)
+- **Proxmox VE 13+** (required for OCI image support)
+- **Isolated network** with no existing DHCP infrastructure
+- SSH and web UI access (port 8006) to the Proxmox host
 
 ## Installation Steps
 
 ### 1. Pull the OCI Image
 
-Connect to your Proxmox VE host via SSH and pull the container image from the GitHub Container Registry.
-
-Proxmox uses `skopeo` to pull OCI images. First, ensure skopeo is installed:
-
 ```bash
-# Install skopeo if not already present
 apt update && apt install -y skopeo
-```
-
-Then pull the image to your template storage:
 
-```bash
-# Pull the OCI image to Proxmox template cache
 skopeo copy docker://ghcr.io/mieweb/opensource-server:latest \
   oci-archive:/var/lib/vz/template/cache/opensource-server.tar
 ```
 
-:::tip Using the Web UI
-You can also pull OCI images through the Proxmox web interface:
-1. Navigate to your storage location (e.g., `local`)
-2. Click **CT Templates**
-3. Use the **Download from URL** option with the OCI registry reference
-:::
-
-This downloads the pre-built container image to your Proxmox host's template storage.
-
 ### 2. Create the Management Container
 
-Launch a new container based on the pulled image:
+In the Proxmox web interface (`https://your-proxmox-host:8006`):
 
-1. Navigate to the Proxmox web interface at `https://your-proxmox-host:8006`
-2. Select your node in the left sidebar
-3. Click **Create CT** to open the container creation wizard
-4. Configure the container:
-   - **Template**: Select the `opensource-server:latest` image from OCI registry
-   - **Hostname**: Choose a meaningful hostname (e.g., `cluster-admin`)
-   - **Network**: Configure with a **static IP address** in the same subnet as your Proxmox VE server(s)
-   - **Resources**: Allocate appropriate CPU, memory, and storage based on expected usage
+1. **Create CT** on your node
+2. **Template**: Select `opensource-server:latest`
+3. **Network**: Configure with a **static IP** in the same subnet as your Proxmox server(s)
+4. **Resources**: Allocate CPU, memory, and storage as needed
 
 :::important Static IP Required
-The management container must have a static IP address. The container comes with a DNSMasq instance to manage DHCP within the network.
+The management container must have a static IP. It runs a DNSMasq instance to manage DHCP within the network.
 :::
 
 ### 3. Configure Network Access
 
-Set up port forwarding to make the management interface accessible, exact steps will depend on your firewall platform. The specific port forwarding configuration depends on your network setup. At minimum, forward:
-- **443/tcp**: HTTPS access to the web-based administration GUI
-
-:::tip Additional Ports
-Depending on your deployment needs, you may also want to forward:
-- **22/tcp**: SSH access to the management container
-- **80/tcp**: HTTP access (will redirect to HTTPS)
-:::
+Forward at minimum **443/tcp** (HTTPS) to the management container. Optionally forward **22/tcp** (SSH) and **80/tcp** (HTTP redirect).
 
 ### 4. Start the Container
 
-Once configured, start the management container:
-
 ```bash
 pct start <container-id>
 ```
 
-The container will initialize and start the cluster management services.
-
 ### 5. Initial Account Setup
 
-Navigate to the management GUI via the forwarded HTTPS port:
-
-```
-https://your-external-address:443
-```
+Navigate to `https://your-external-address:443` and register an account.
 
-:::important First Account Registration
-Register a new account through the web interface. The **first account registered** will be:
-- Automatically approved (no manual approval required)
-- Granted full administrative privileges
-- Able to manage all cluster resources and user accounts
+:::important First Account
+The **first account registered** is automatically approved with full admin privileges. Register the intended administrator account first.
 :::
 
-**Important**: Ensure you register the intended administrator account first, as it will receive elevated privileges automatically.
-
-## Next Steps
-
-Once logged in with your administrative account, proceed to the [Concepts](/docs/admins/concepts) guide to understand the architecture and key concepts of the cluster management system.
-
-You'll learn about:
-- Cluster organization and node management
-- User roles and permissions
-- Container lifecycle management
-- Service exposure and networking
-- Monitoring and maintenance
-
-## Troubleshooting
-
-### Cannot Access the Management GUI
-
-- Verify port forwarding is correctly configured
-- Check that the container is running: `pct status <container-id>`
-- Ensure the static IP address is reachable from your location
-- Review container logs: `pct logs <container-id>`
-
-### OCI Image Pull Fails
-
-- Verify internet connectivity from the Proxmox host
-- Ensure Proxmox VE is version 13 or higher: `pveversion`
-- Check that the container registry is accessible
-- Try pulling the image manually with verbose output
-
-### Container Won't Start
-
-- Check container configuration: `pct config <container-id>`
-- Review system logs for errors
-- Verify sufficient resources are available on the host
-- Ensure no IP address conflicts exist on the network
-
-## Getting Help
+Once logged in, proceed to [Core Concepts](core-concepts) to configure your first site.
 
-For installation issues or questions:
-- Review the detailed error messages in Proxmox logs
-- Check the [GitHub repository](https://github.com/mieweb/opensource-server) for known issues
-- Contact the MIE team for assistance
diff --git a/mie-opensource-landing/docs/admins/ldap-servers.md b/mie-opensource-landing/docs/admins/ldap-servers.md
new file mode 100644
index 00000000..160bc31e
--- /dev/null
+++ b/mie-opensource-landing/docs/admins/ldap-servers.md
@@ -0,0 +1,138 @@
+---
+sidebar_position: 3
+---
+
+# Deploying LDAP Servers
+
+The base container images authenticate users via LDAP against two servers named `ldap1` and `ldap2` (configured in SSSD at `ldaps://ldap1:636` and `ldaps://ldap2:636`). This guide covers deploying those servers, keeping them updated, and integrating them with Proxmox.
+
+## Prerequisites
+
+- A running cluster with at least one [site](/docs/admins/core-concepts/sites) configured
+- The management software deployed and accessible
+- Two available container slots for `ldap1` and `ldap2`
+
+## LDAP Gateway Image
+
+The LDAP servers use [`ghcr.io/mieweb/ldap-gateway`](https://github.com/mieweb/LDAPServer), a Node.js LDAP server that reads user and group data directly from the management database via SQL.
+
+## Environment Variables
+
+| Variable | Value |
+|----------|-------|
+| `DIRECTORY_BACKEND` | `sql` |
+| `LDAP_COMMON_NAME` | Hostname of the container (e.g. `ldap1` or `ldap2`) |
+| `LDAP_BASE_DN` | Derived from the site's internal domain (e.g., `example.com` → `dc=example,dc=com`) |
+| `AUTH_BACKENDS` | `sql` or `sql,notification` (if push notifications are enabled) |
+| `NOTIFICATION_URL` | Push notification endpoint (only present if push notifications are enabled) |
+| `SQL_URI` | `postgres://username:password@hostname:port/database` — must point to the same database used by the manager |
+| `SQL_QUERY_ALL_USERS` | See [rendered queries](#sql-queries) below |
+| `SQL_QUERY_ONE_USER` | See [rendered queries](#sql-queries) below |
+| `SQL_QUERY_ALL_GROUPS` | See [rendered queries](#sql-queries) below |
+| `SQL_QUERY_GROUPS_BY_MEMBER` | See [rendered queries](#sql-queries) below |
+| `REQUIRE_AUTH_FOR_SEARCH` | `false` — allows unauthenticated LDAP searches |
+
+### SQL Queries
+
+The queries are generated by the manager using Sequelize's `quoteIdentifier()`. Rendered for PostgreSQL:
+
+**`SQL_QUERY_ALL_USERS`**
+```sql
+SELECT "uid" AS username, "uidNumber" AS uid_number, "gidNumber" AS gid_number,
+       "givenName" AS first_name, "cn" AS full_name, "sn" AS last_name,
+       "mail", "homeDirectory" AS home_directory, "userPassword" AS password
+FROM "Users"
+```
+
+**`SQL_QUERY_ONE_USER`**
+```sql
+SELECT "uid" AS username, "uidNumber" AS uid_number, "gidNumber" AS gid_number,
+       "givenName" AS first_name, "cn" AS full_name, "sn" AS last_name,
+       "mail", "homeDirectory" AS home_directory, "userPassword" AS password
+FROM "Users"
+WHERE "uid" = ?
+```
+
+**`SQL_QUERY_ALL_GROUPS`**
+```sql
+SELECT g."cn" AS name, g."gidNumber" AS gid_number
+FROM "Groups" g
+```
+
+**`SQL_QUERY_GROUPS_BY_MEMBER`**
+```sql
+SELECT g."cn" AS name, g."gidNumber" AS gid_number
+FROM "Groups" g
+INNER JOIN "UserGroups" ug ON g."gidNumber" = ug."gidNumber"
+INNER JOIN "Users" u ON ug."uidNumber" = u."uidNumber"
+WHERE u."uid" = ?
+```
+
+## Deploying ldap1 and ldap2
+
+Create two LXC containers named exactly `ldap1` and `ldap2` using the `ghcr.io/mieweb/ldap-gateway` image. Both use identical configuration — the pair provides redundancy.
+
+For each server:
+
+1. Create a container with hostname `ldap1` (or `ldap2`) using the `ghcr.io/mieweb/ldap-gateway` image
+2. Set the environment variables from above
+3. Start the container
+
+Both servers will register in DNSMasq automatically, making them resolvable by name from all containers in the site.
+
+## Rolling Updates
+
+To update the LDAP servers without downtime, replace them one at a time:
+
+1. **Delete `ldap1`** — all containers fail over to `ldap2` via SSSD
+2. **Recreate `ldap1`** with the latest `ghcr.io/mieweb/ldap-gateway` image and the same environment variables
+3. **Verify `ldap1`** is running and responding on port 636
+4. **Delete `ldap2`** — traffic shifts to the updated `ldap1`
+5. **Recreate `ldap2`** with the latest image and same environment variables
+6. **Verify `ldap2`** is running
+
+SSSD on the base images is configured with both servers (`ldaps://ldap1:636, ldaps://ldap2:636`) and will automatically fail over when one is unavailable.
+
+## Proxmox LDAP Realm
+
+Configure Proxmox to authenticate users against the same LDAP servers. This allows container ACLs to reference cluster users as `username@ldap`.
+
+### DNS Configuration
+
+First, configure Proxmox to use the same DNS server as the containers (the DNSMasq instance managed by the management software). This ensures Proxmox can resolve `ldap1` and `ldap2` by name.
+
+In the Proxmox web UI: **Node** → **System** → **DNS** → set the DNS server to the DNSMasq IP address.
+
+### Add the LDAP Realm
+
+In the Proxmox web UI: **Datacenter** → **Permissions** → **Realms** → **Add** → **LDAP Server**.
+
+| Setting | Value |
+|---------|-------|
+| Realm | `ldap` |
+| Base Domain Name | Derived from internal domain (e.g., `example.com` → `dc=example,dc=com`) |
+| User Attribute Name | `uid` |
+| Default | ✅ (checked) |
+| Server | `ldap1` |
+| Fallback Server | `ldap2` |
+| Port | *(leave default)* |
+| Mode | LDAPS |
+| Verify Certificate | ❌ (unchecked) |
+| Require TFA | none |
+
+Under **Sync Options**:
+
+| Setting | Value |
+|---------|-------|
+| Email Attribute | `mail` |
+| Scope | Users and Groups |
+
+All other settings remain at defaults.
+
+### Sync Users
+
+After adding the realm, sync it to import users and groups:
+
+**Datacenter** → **Permissions** → **Realms** → select `ldap` → **Sync**.
+
+The management software also triggers a sync automatically when creating containers (via `syncLdapRealm('ldap')`) to ensure new users are available for ACL assignment.
diff --git a/mie-opensource-landing/docs/admins/nodes.md b/mie-opensource-landing/docs/admins/nodes.md
deleted file mode 100644
index 98d56733..00000000
--- a/mie-opensource-landing/docs/admins/nodes.md
+++ /dev/null
@@ -1,260 +0,0 @@
----
-sidebar_position: 6
----
-
-# Nodes
-
-Nodes represent individual Proxmox VE servers within a site. Each node can host multiple containers and must be registered with the cluster management system before use.
-
-## What is a Node?
-
-A node is a physical or virtual server running Proxmox VE that:
-- Hosts Linux containers (LXC)
-- Provides compute, memory, and storage resources
-- Connects to the cluster management system via the Proxmox API
-- Participates in the site's network infrastructure
-
-Multiple nodes within a site form a Proxmox cluster, enabling high availability and resource distribution.
-
-## Node Properties
-
-Each node requires the following configuration:
-
-- **Name**: The node name as it appears in the Proxmox cluster (must match exactly)
-- **IP Address**: Used for internal DNS resolution
-- **API URL**: The Proxmox API endpoint (e.g., `https://192.168.1.10:8006/api2/json`)
-- **Authentication**: Either username/password or API token
-  - **Username**: Typically `root@pam` for full access
-  - **Password**: The user's password
-  - **Token ID**: Alternative to username (e.g., `root@pam!mytoken`)
-  - **Token Secret**: The token's secret value
-- **TLS Verification**: Enable or disable certificate validation (optional)
-
-## Adding Nodes
-
-There are two methods for adding nodes to a site:
-
-### Method 1: Import Nodes (Recommended)
-
-The Import Nodes function automatically discovers all nodes in a Proxmox cluster:
-
-1. Navigate to **Nodes** in the administration interface
-2. Select your site
-3. Click **Import Nodes**
-4. Enter the connection details:
-   - **API URL**: Any node in the cluster (e.g., `https://192.168.1.10:8006/api2/json`)
-   - **Username**: `root@pam` (recommended)
-   - **Password**: The root password
-   - **Disable TLS Verification**: Check if using self-signed certificates
-
-5. Click **Import**
-
-The system will:
-- Connect to the Proxmox cluster
-- Discover all nodes automatically
-- Import each node with correct names and IP addresses
-- Verify API connectivity
-
-:::tip Cluster Discovery
-Import Nodes only needs credentials for one node. It will automatically discover and import all other nodes in the same Proxmox cluster.
-:::
-
-### Method 2: Manual Node Creation
-
-For individual nodes or custom configurations:
-
-1. Navigate to **Nodes** in the administration interface
-2. Select your site
-3. Click **Create New Node**
-4. Fill in all required fields:
-   - **Name**: Must exactly match the node name in Proxmox
-   - **IP Address**: The node's network IP
-   - **API URL**: `https://NODE_IP:8006/api2/json`
-   - **Username**: `root@pam`
-   - **Password**: The root password
-
-5. Click **Save**
-
-:::important Name Matching
-The node name must **exactly match** the hostname shown in the Proxmox web interface. Mismatches will cause API communication failures.
-:::
-
-## Authentication Methods
-
-### Username & Password
-
-The traditional authentication method:
-
-- **Pros**: Simple to configure, no token management
-- **Cons**: Less secure, password changes require updating configuration
-- **Recommended for**: Initial setup, testing
-
-**Example:**
-```
-Username: root@pam
-Password: your-root-password
-```
-
-### API Token (Recommended for Production)
-
-A more secure alternative using Proxmox API tokens:
-
-- **Pros**: More secure, can be revoked independently, fine-grained permissions
-- **Cons**: Requires creating tokens in Proxmox first
-- **Recommended for**: Production deployments
-
-**Creating an API Token in Proxmox:**
-
-1. Log in to Proxmox web interface
-2. Navigate to **Datacenter** → **Permissions** → **API Tokens**
-3. Click **Add** to create a new token
-4. Configure the token:
-   - **User**: `root@pam`
-   - **Token ID**: A descriptive name (e.g., `cluster-mgmt`)
-   - **Privilege Separation**: Uncheck (for full root access)
-5. Save and copy the token secret (shown only once)
-
-**Using the Token:**
-```
-Token ID: root@pam!cluster-mgmt
-Token Secret: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
-```
-
-## TLS Certificate Verification
-
-Proxmox uses self-signed certificates by default, which causes TLS verification to fail.
-
-### Options:
-
-**Disable TLS Verification** (Easiest)
-- Check the "Disable TLS Verification" option when adding nodes
-- ⚠️ Less secure (vulnerable to MITM attacks)
-- ✅ Works immediately with self-signed certificates
-- Recommended for: Isolated networks, internal deployments
-
-**Install Valid Certificates** (Most Secure)
-- Configure Proxmox to use certificates from a trusted CA
-- Leave TLS verification enabled
-- ✅ Maximum security
-- Recommended for: Production, internet-facing deployments
-
-:::tip Development vs Production
-For isolated development clusters, disabling TLS verification is acceptable. For production environments exposed to untrusted networks, install valid certificates.
-:::
-
-## Verifying Node Configuration
-
-After adding a node, verify it's working correctly:
-
-1. Check the node status in the **Nodes** list
-2. Verify the green checkmark or "Online" indicator appears
-3. Test creating a container on the node
-
-If the node shows as offline or unreachable:
-- Verify the API URL is correct
-- Check network connectivity from the management container
-- Verify authentication credentials
-- Review system logs for detailed error messages
-
-## Node Management
-
-### Updating Node Configuration
-
-To modify a node's settings:
-
-1. Navigate to the node's detail page
-2. Update the necessary fields
-3. Save changes
-4. The system will test connectivity with the new configuration
-
-### Removing Nodes
-
-To remove a node from management:
-
-1. Ensure no active containers are running on the node
-2. Navigate to the node's detail page
-3. Click **Delete** or **Remove**
-4. Confirm the action
-
-:::warning Container Dependencies
-You cannot remove a node that has active containers. Migrate or delete containers first.
-:::
-
-## Multi-Node Considerations
-
-### Load Distribution
-
-The cluster management system can distribute containers across nodes based on:
-- Available resources (CPU, memory, storage)
-- Node health and availability
-- Administrator preferences
-
-### High Availability
-
-Proxmox supports HA clustering features:
-- Live migration of containers between nodes
-- Automatic failover if a node fails
-- Shared storage for container data
-
-:::note HA Configuration
-High availability features are configured in Proxmox itself, not in the cluster management system. Refer to Proxmox documentation for HA setup.
-:::
-
-## Troubleshooting
-
-### Node Shows as Offline
-
-**Check network connectivity:**
-```bash
-# From the management container
-ping NODE_IP
-curl -k https://NODE_IP:8006/api2/json
-```
-
-**Verify Proxmox API is running:**
-```bash
-# On the Proxmox node
-systemctl status pveproxy
-```
-
-**Common issues:**
-- Firewall blocking port 8006
-- Proxmox API service not running
-- Incorrect IP address or API URL
-- Network routing issues
-
-### Authentication Failures
-
-**Check credentials:**
-- Verify username/password or token/secret are correct
-- Ensure the user has sufficient permissions
-- Check if the API token hasn't been deleted or revoked
-
-**Test authentication manually:**
-```bash
-curl -k -u "root@pam:PASSWORD" \
-  https://NODE_IP:8006/api2/json/nodes
-```
-
-### Name Mismatch Errors
-
-If you see "node name doesn't match" errors:
-
-1. Check the node name in Proxmox: `hostname`
-2. Update the node name in cluster management to match exactly
-3. Node names are case-sensitive
-
-### TLS Verification Errors
-
-If seeing SSL certificate errors:
-- Enable "Disable TLS Verification" option
-- Or install valid certificates on Proxmox nodes
-- Ensure the certificate hostname matches the API URL
-
-## Next Steps
-
-After adding nodes to your site:
-
-1. **[Containers](containers)**: Learn about container deployment
-2. Review the [User Documentation](/docs/users/creating-containers/web-gui) for creating containers
-3. Set up monitoring and maintenance procedures
diff --git a/mie-opensource-landing/docs/admins/settings.md b/mie-opensource-landing/docs/admins/settings.md
index 6fa9928a..7b51da07 100644
--- a/mie-opensource-landing/docs/admins/settings.md
+++ b/mie-opensource-landing/docs/admins/settings.md
@@ -4,126 +4,57 @@ sidebar_position: 7
 
 # System Settings
 
-The Settings page provides system-wide configuration options for the cluster management system. This page is only accessible to administrators.
+Admin-only system-wide configuration. Access via **Settings** in the admin sidebar.
 
 ![Settings Page](/img/screenshots/settings-page.png)
 
-## Email Configuration
+## Email (SMTP)
 
-The system uses SMTP to send emails for password reset requests and other system notifications.
+Configure SMTP for password resets and system notifications.
 
-### SMTP Settings
+- **SMTP URL**: `smtp[s]://[[user][:pass]@]<host>[:port]`
+- **No-Reply Email**: "From" address for system emails (e.g., `noreply@example.com`)
 
-Configure the following email settings:
+When configured, users can reset passwords via "Forgot your password?" on the login page (reset link valid for 1 hour).
 
-1. **SMTP URL**: The connection string for your SMTP server in the format:
-   ```
-   smtp[s]://[[username][:password]@]<host>[:port]
-   ```
-   Examples:
-   - `smtp://smtp.example.com:587` (no authentication)
-   - `smtp://user:pass@smtp.example.com:587` (with authentication)
-   - `smtps://user:pass@smtp.example.com:465` (secure SMTP)
-
-2. **No-Reply Email Address**: The "from" address used for system emails like password reset notifications.
-   - Example: `noreply@example.com`
-
-:::tip Testing SMTP Configuration
-After configuring SMTP settings, you can test the configuration by using the "Forgot your password?" link on the login page. The system will attempt to send a password reset email.
-:::
-
-### Password Reset Flow
-
-When SMTP is properly configured, users can reset their passwords through the following workflow:
-
-1. User clicks "Forgot your password?" on the login page
-2. User enters their username or email address
-3. System sends an email with a secure reset link (token valid for 1 hour)
-4. User clicks the link in the email
-5. User enters and confirms their new password
-6. User is redirected to login with their new credentials
-
-:::warning SMTP Required
-Password reset functionality requires valid SMTP configuration. If SMTP is not configured, password reset emails will fail to send, and users will need to contact administrators to reset their passwords manually.
+:::warning
+Without SMTP, password resets require manual admin intervention.
 :::
 
 ## Push Notification 2FA
 
-The cluster supports two-factor authentication (2FA) using push notifications via the [MieWeb Auth App](https://github.com/mieweb/mieweb_auth_app).
-
-### Configuration
-
-To enable push notification 2FA:
+Two-factor authentication via push notifications using the [MieWeb Auth App](https://github.com/mieweb/mieweb_auth_app).
 
-1. Navigate to **Settings** in the admin sidebar
-2. Enter the **Push Notification URL** - the endpoint of your notification service
-3. Check **Enable Push Notification 2FA** to activate the feature
-4. Click **Save Settings**
-
-:::warning URL Required
-When push notification 2FA is enabled, you must provide a valid notification service URL. The system will validate this requirement before saving.
-:::
+### Setup
 
-### How It Works
+1. Enter the **Push Notification URL** (your notification service endpoint)
+2. Check **Enable Push Notification 2FA**
+3. Save
 
-When push notification 2FA is enabled:
+### Flow
 
-1. Users enter their username and password on the login page
-2. After successful password validation, the system sends a push notification to the user's registered device
-3. Users must approve the login attempt on their mobile device
-4. Once approved, access is granted and the user is redirected to their dashboard
+1. User enters username/password
+2. Push notification sent to registered device
+3. User approves/rejects on mobile
+4. Access granted or denied
 
-### User Registration
+Users without a registered device see an error with a link to register.
 
-Users must register their devices with the notification service before they can authenticate:
-
-- If a user attempts to log in without a registered device, they will see an error message
-- The error message includes a link to register their device with the [MieWeb Auth App](https://github.com/mieweb/mieweb_auth_app)
-- After registration, users can log in using push notification 2FA
-
-### Notification Service
-
-The push notification feature requires a separate notification service. MIE provides:
-
-- **[MieWeb Auth App](https://github.com/mieweb/mieweb_auth_app)**: Mobile application for receiving and approving login notifications
-- **Notification Service API**: Backend service that handles push notification delivery
-
-The notification service must implement the following endpoint:
+### Notification Service API
 
 ```
 POST {notification_url}/send-notification
-{
-  "username": "user123"
-}
+{ "username": "user123" }
 ```
 
-Expected responses:
-- `{"success": true, "action": "approve"}` - User approved the login
-- `{"success": true, "action": "reject"}` - User rejected the login
-- `{"success": true, "action": "timeout"}` - Notification timed out
-- `{"success": false, "message": "..."}` - Error occurred (e.g., no device registered)
+Responses:
+- `{"success": true, "action": "approve|reject|timeout"}`
+- `{"success": false, "message": "..."}`
 
 ### LDAP Integration
 
-When push notification 2FA is enabled, the system automatically updates the `ldap.conf` configuration for all sites:
-
-- `AUTH_BACKENDS` is set to `sql,notification` (adds notification authentication)
-- `NOTIFICATION_URL` is set to the configured notification service URL
-
-These settings are applied when:
-- Creating a new site
-- Updating an existing site's configuration
-- Deploying containers that use LDAP authentication
+When enabled, `AUTH_BACKENDS` is set to `sql,notification` and `NOTIFICATION_URL` is propagated to all sites' `ldap.conf` automatically.
 
 ## Access Control
 
-:::info Administrator Only
-The Settings page requires administrator privileges. Non-admin users will receive a "Forbidden" error if they attempt to access this page.
-:::
-
-To grant administrator access to a user:
-1. Navigate to **Users** in the admin sidebar
-2. Find the user account
-3. Add them to a group with admin privileges (typically the `admins` group)
-
-See [User Administration](users-and-groups) for more details on managing users and groups.
+Requires membership in a group with admin privileges (typically `sysadmins`). See [Users & Groups](core-concepts/users-and-groups).
diff --git a/mie-opensource-landing/docs/admins/sites.md b/mie-opensource-landing/docs/admins/sites.md
deleted file mode 100644
index 485ea597..00000000
--- a/mie-opensource-landing/docs/admins/sites.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-sidebar_position: 4
----
-
-# Sites
-
-A site is the top-level organizational unit that groups Proxmox nodes, defines network configuration, and manages container networking. You must create at least one site before adding nodes or deploying containers.
-
-## What is a Site?
-
-A site represents a physical or logical cluster location with its own:
-- Network subnet and DHCP configuration
-- Proxmox node(s)
-- Container deployments
-- External domain mappings
-
-Sites enable you to manage multiple independent Proxmox clusters from a single management interface.
-
-## Site Properties
-
-When creating a site, you must configure:
-
-### Basic Information
-
-- **Display Name**: A human-readable name for the site (e.g., "Production Cluster", "Development Lab")
-
-### Network Configuration
-
-- **Internal Domain Name**: The DNS domain for the cluster's internal network
-  - Recommended: `cluster.yourdomain.tld`
-  - If you don't own a domain, use IANA-defined local domains like `.internal`, `.local`, or `.home.arpa`
-
-- **DHCP Range**: The IP address range for automatic container assignment
-  - Must be within the site's subnet
-  - Format: `192.168.1.100-192.168.1.200`
-
-- **Subnet Mask**: The network subnet mask (e.g., `255.255.255.0` or `/24`)
-
-- **Gateway IP**: The default gateway for the network (typically your router)
-
-- **DNS Forwarders**: Upstream DNS servers for resolving external domains
-  - Can specify multiple servers separated by commas
-  - Example: `8.8.8.8,1.1.1.1`
-
-## Creating a Site
-
-Follow these steps to create your first site:
-
-### 1. Access Site Management
-
-1. Log in to the administration interface
-2. Navigate to **Sites** in the main menu
-3. Click **Create New Site**
-
-### 2. Configure Basic Settings
-
-1. Enter a descriptive **Display Name**
-2. Set your **Internal Domain Name** (e.g., `cluster.example.internal`)
-
-:::tip Domain Selection
-If you own a domain, using a subdomain like `cluster.yourdomain.tld` allows you to create valid SSL certificates. For purely internal deployments, `.internal` is recommended per RFC 8375.
-:::
-
-### 3. Configure Networking
-
-Configure the network settings based on your infrastructure:
-
-**Example Configuration:**
-```
-DHCP Range: 192.168.100.100-192.168.100.200
-Subnet Mask: 255.255.255.0 (or /24)
-Gateway IP: 192.168.100.1
-DNS Forwarders: 8.8.8.8,1.1.1.1
-```
-
-:::important Network Isolation
-Ensure the DHCP range does not conflict with:
-- Static IPs assigned to Proxmox nodes
-- The management container's IP address
-- Any other static infrastructure devices
-:::
-
-### 4. Save and Verify
-
-1. Click **Save** to create the site
-2. Verify the site appears in the sites list
-3. Check that network settings are correct
-
-## DHCP and IP Management
-
-The cluster management system handles DHCP for containers automatically:
-
-- When a user creates a container, an IP is automatically assigned from the DHCP range
-- IP assignments are tracked to prevent conflicts
-- Containers receive DNS configuration pointing to the internal DNS server
-- The gateway and subnet mask are automatically applied
-
-### Static IP Addresses
-
-While containers typically use DHCP, you can configure static IPs outside the DHCP range for:
-- Load balancers
-- Database servers
-- Other infrastructure components requiring fixed addresses
-
-## DNS Configuration
-
-The internal DNS server provides:
-
-- Name resolution for containers within the site: `container-name.cluster.example.internal`
-- Forwarding for external domains to the configured DNS forwarders
-- Automatic DNS record creation when containers are deployed
-
-## Multiple Sites
-
-You can create multiple sites to manage separate clusters:
-
-- **Geographical separation**: Different physical locations
-- **Environment separation**: Production vs. Development vs. Testing
-- **Network isolation**: Different security zones or network segments
-
-Each site operates independently with its own:
-- Network configuration
-- Nodes and containers
-- External domain mappings
-
-## Next Steps
-
-After creating a site:
-
-1. **[External Domains](external-domains)**: Configure domains for exposing HTTP services (optional)
-2. **[Nodes](nodes)**: Import your Proxmox nodes into the site
-3. **[Containers](containers)**: Begin deploying containers on your nodes
-
-## Troubleshooting
-
-### DHCP Range Exhausted
-
-If you run out of DHCP addresses:
-1. Edit the site configuration
-2. Expand the DHCP range (ensure no conflicts)
-3. Save changes
-
-### DNS Resolution Issues
-
-If containers can't resolve external domains:
-- Verify DNS forwarders are reachable from the Proxmox nodes
-- Test DNS resolution: `dig @8.8.8.8 google.com`
-- Check that the internal DNS server is running
-
-### Gateway Unreachable
-
-If containers can't reach the internet:
-- Verify the gateway IP is correct
-- Ensure Proxmox nodes can reach the gateway
-- Check firewall rules on the gateway device
diff --git a/mie-opensource-landing/docs/admins/users-and-groups.md b/mie-opensource-landing/docs/admins/users-and-groups.md
deleted file mode 100644
index 597284e3..00000000
--- a/mie-opensource-landing/docs/admins/users-and-groups.md
+++ /dev/null
@@ -1,171 +0,0 @@
----
-sidebar_position: 3
----
-
-# Users & Groups
-
-User accounts and groups form the foundation of access control in the cluster management system. Groups determine permissions and provide LDAP authentication for container access.
-
-## Groups
-
-Groups organize users and define their permissions within the cluster.
-
-### Default Groups
-
-The system includes two built-in groups:
-
-- **ldapusers**: Members can authenticate via LDAP to all containers in the cluster
-- **sysadmins**: Members receive full administrative access to both Proxmox nodes and the cluster management software
-
-### Group Properties
-
-When creating a new group, you must configure:
-
-- **Name**: The LDAP common name (CN) used for authentication
-- **GID**: A unique numeric Group ID used by the LDAP server
-- **Administrator**: Toggle to grant members full Proxmox and software administration privileges
-
-:::important GID Uniqueness
-Each group must have a unique numeric GID. The LDAP server uses this identifier, so conflicts will cause authentication issues.
-:::
-
-### Creating a Group
-
-1. Navigate to **Groups** in the administration interface
-2. Click **Create New Group**
-3. Enter a descriptive name (will be used as LDAP CN)
-4. Assign a unique numeric GID
-5. Enable **Administrator** if members should have full cluster access
-6. Save the group
-
-## Users
-
-User accounts allow individuals to authenticate and access cluster resources.
-
-### User Registration
-
-Users typically register themselves through the web interface by providing:
-
-- Username
-- First name
-- Last name
-- Email address
-- Password
-
-Newly registered users are automatically:
-- Set to **Pending** status
-- Added to the **ldapusers** group
-
-:::tip Manual User Creation
-Administrators can also create user accounts manually through the admin interface, skipping the registration process.
-:::
-
-### Inviting Users
-
-Administrators can invite new users via email, which streamlines onboarding by automatically activating accounts upon registration.
-
-**To invite a user:**
-
-1. Navigate to **Users** in the administration interface
-2. Click **Invite User** (next to the "New User" button)
-3. Enter the email address of the person you want to invite
-4. Click **Send Invitation**
-
-**How it works:**
-
-- The system sends an email with a secure registration link
-- The link expires after **24 hours**
-- When the recipient registers using the link, their email is pre-filled and locked
-- Their account is **automatically activated** (no admin approval needed)
-- Each invitation link can only be used once
-
-:::important SMTP Configuration Required
-You must configure SMTP settings before sending invitations. If SMTP is not configured, you'll receive an error message prompting you to set it up in **Settings**.
-:::
-
-:::note Duplicate Emails
-You cannot invite an email address that is already registered to an existing user.
-:::
-
-### User Statuses
-
-Users can have one of three statuses:
-
-- **Pending**: Newly registered, awaiting administrator approval
-- **Active**: Approved and able to authenticate to all cluster services
-- **Suspended**: Access revoked, cannot authenticate anywhere
-
-:::important Authentication Requirement
-Only users with **Active** status can log in to the management interface, Proxmox, or any containers.
-:::
-
-### Approving Users
-
-To approve a pending user:
-
-1. Navigate to **Users** in the administration interface
-2. Find the pending user
-3. Change their status to **Active**
-4. Optionally add them to additional groups beyond **ldapusers**
-5. Save the changes
-
-### Managing Group Membership
-
-To modify a user's group memberships:
-
-1. Navigate to the user's detail page
-2. In the **Groups** section, add or remove group assignments
-3. Save changes
-
-Group membership changes take effect immediately for new authentication attempts.
-
-## LDAP Integration
-
-The built-in LDAP server uses group and user information to provide authentication services to all containers in the cluster.
-
-### How It Works
-
-- Users in the **ldapusers** group can SSH into any container using their cluster credentials
-- Group IDs (GIDs) and user IDs (UIDs) are synchronized across all containers
-- Password changes in the management interface propagate to LDAP immediately
-
-### Best Practices
-
-- Keep the **ldapusers** group for general container access
-- Create additional groups for team-based or project-based access control
-- Use the **Administrator** flag sparingly - only for trusted cluster administrators
-- Regularly review and approve pending user registrations
-- Suspend rather than delete users who leave the organization (preserves audit trails)
-
-## Security Considerations
-
-### Password Management
-
-- Enforce strong password policies during registration
-- Passwords are hashed and never stored in plaintext
-- Users can reset their own passwords through the web interface
-
-### Administrator Access
-
-Users in administrator groups have extensive privileges:
-- Full Proxmox API access on all nodes
-- Ability to create, modify, and delete any resource
-- Access to all user data and configurations
-
-Only grant administrator status to trusted individuals.
-
-### Audit Trail
-
-All user actions are logged, including:
-- Login attempts (successful and failed)
-- Status changes (pending → active, active → suspended)
-- Group membership modifications
-- Resource creation and deletion
-
-Review logs regularly to detect unauthorized access attempts.
-
-## Next Steps
-
-Once you've configured users and groups, proceed to:
-- [**Sites**](sites): Set up your network infrastructure
-- [**Nodes**](nodes): Connect your Proxmox servers
diff --git a/mie-opensource-landing/docs/developers/contributing.md b/mie-opensource-landing/docs/developers/contributing.md
index 7bc7df78..9a823a2e 100644
--- a/mie-opensource-landing/docs/developers/contributing.md
+++ b/mie-opensource-landing/docs/developers/contributing.md
@@ -4,165 +4,40 @@ sidebar_position: 4
 
 # Contributing
 
-We welcome contributions to the MIE Opensource Proxmox Cluster project! This guide will help you get started.
-
-## Areas for Contribution
-
-- **Frontend Development**: Improve the web UI, add new features
-- **API Development**: Extend REST endpoints, optimize queries
-- **Database Optimization**: Improve schema design, add indexes
-- **DNS/NGINX Integration**: Enhance service exposure capabilities
-- **LDAP Gateway**: Improve authentication mechanisms
-- **Documentation**: Expand guides, add examples
-
 ## Getting Started
 
-1. Review the [GitHub repository](https://github.com/mieweb/opensource-server)
-2. Check open issues for contribution opportunities
-3. Set up a local development environment using the [Development Workflow](development-workflow) guide
-4. Fork the repository and create a feature branch
-5. Make your changes and test thoroughly
-6. Submit a pull request with a clear description
-
-## Pull Request Guidelines
-
-### Before Submitting
-
-- Ensure all tests pass: `npm test`
-- Check for linting errors: `npm run lint`
-- Test your changes in a local environment
-- Update documentation if needed
-- Add tests for new features
-
-### PR Description
-
-Include in your pull request:
-
-- **Summary**: Brief description of what changed and why
-- **Related Issues**: Link to any related GitHub issues
-- **Testing**: How you tested the changes
-- **Screenshots**: If UI changes are involved
-- **Breaking Changes**: Note any breaking changes
-
-### Code Review Process
+1. Review the [GitHub repository](https://github.com/mieweb/opensource-server) and open issues
+2. Set up a local dev environment using the [Development Workflow](development-workflow) guide
+3. Fork the repository and create a feature branch
+4. Make changes, test thoroughly, submit a pull request
 
-1. Submit your pull request
-2. Automated tests will run
-3. Maintainers will review your code
-4. Address any feedback or requested changes
-5. Once approved, your PR will be merged
+## Pull Requests
 
-## Coding Standards
+Before submitting: `npm test`, `npm run lint`, update docs if needed.
 
-### General Guidelines
+Include in your PR: summary of changes, related issues, how you tested, screenshots for UI changes, and any breaking changes.
 
-- Follow existing code style and conventions
-- Write clear, descriptive commit messages
-- Keep commits focused on a single change
-- Add comments for complex logic
+## Commit Messages
 
-### Commit Messages
-
-Follow the conventional commits format:
+Follow [conventional commits](https://www.conventionalcommits.org/):
 
 ```
 type(scope): subject
-
-body (optional)
-
-footer (optional)
 ```
 
-**Types:**
-- `feat`: New feature
-- `fix`: Bug fix
-- `docs`: Documentation changes
-- `refactor`: Code refactoring
-- `test`: Test additions or modifications
-- `chore`: Maintenance tasks
+Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
 
-**Examples:**
 ```
 feat(containers): add support for custom CPU limits
-
 fix(auth): resolve LDAP authentication timeout issue
-
-docs(admin): add troubleshooting section for node setup
 ```
 
-## Testing Requirements
-
-### Unit Tests
-
-- Write tests for new functions and modules
-- Maintain or improve code coverage
-- Use descriptive test names
-
-### Integration Tests
+## Testing
 
+- Write unit tests for new functions
 - Test API endpoints end-to-end
-- Verify database operations
-- Test container creation workflows
-
-### Manual Testing
-
-Before submitting:
-- Test container creation and deletion
-- Verify DNS resolution works correctly
-- Check NGINX routing for services
-- Ensure LDAP authentication functions
-- Test with different database backends (if applicable)
-
-## Documentation
-
-### Code Documentation
-
-- Add JSDoc comments for functions and classes
-- Document function parameters and return values
-- Explain non-obvious code behavior
-
-### User Documentation
-
-If your changes affect users:
-- Update relevant documentation pages
-- Add examples and screenshots
-- Update the changelog
-
-## Community Guidelines
-
-### Communication
-
-- Be respectful and professional
-- Ask questions if you're unsure
-- Provide constructive feedback
-- Help others when you can
-
-### Issue Reporting
-
-When reporting issues:
-- Use a clear, descriptive title
-- Provide steps to reproduce
-- Include error messages and logs
-- Specify your environment (OS, Node version, etc.)
+- Manually verify container creation/deletion, DNS resolution, NGINX routing, and LDAP auth
 
 ## License
 
 By contributing, you agree that your contributions will be licensed under the same license as the project.
-
-## Getting Help
-
-- Check existing documentation and issues first
-- Ask questions in GitHub issues or discussions
-- Reach out to maintainers for guidance
-
-## Resources
-
-- [Development Workflow](development-workflow): Setup and development guide
-- [System Architecture](system-architecture): Understand the system design
-- [GitHub Repository](https://github.com/mieweb/opensource-server): View code and issues
-- [Administrator Documentation](/docs/admins/): Learn about cluster management
-- [User Documentation](/docs/users/creating-containers/web-gui): Understand user workflows
-
----
-
-Thank you for contributing to the MIE Opensource Proxmox Cluster project!
diff --git a/mie-opensource-landing/docs/developers/core-technologies.md b/mie-opensource-landing/docs/developers/core-technologies.md
index d9503a6c..e0ca7947 100644
--- a/mie-opensource-landing/docs/developers/core-technologies.md
+++ b/mie-opensource-landing/docs/developers/core-technologies.md
@@ -4,164 +4,25 @@ sidebar_position: 5
 
 # Core Technologies
 
-The MIE Opensource Proxmox Cluster is built on several key open-source technologies. This page provides links to external documentation for the core components.
-
-## Backend Framework
-
-### Express.js
-
-**Express** is a minimal and flexible Node.js web application framework that provides the foundation for our API server.
-
-- **Official Documentation**: [expressjs.com](https://expressjs.com/)
-- **Getting Started**: [Express Guide](https://expressjs.com/en/guide/routing.html)
-- **API Reference**: [Express API](https://expressjs.com/en/4x/api.html)
-
-**Used For:**
-- REST API endpoints
-- Request routing and middleware
-- Session management
-- Server-side rendering
-
-### Sequelize ORM
-
-**Sequelize** is a promise-based Node.js ORM for Postgres, MySQL, MariaDB, SQLite, and more.
-
-- **Official Documentation**: [sequelize.org](https://sequelize.org/)
-- **Models Guide**: [Sequelize Models](https://sequelize.org/docs/v6/core-concepts/model-basics/)
-- **Migrations**: [Sequelize Migrations](https://sequelize.org/docs/v6/other-topics/migrations/)
-- **Querying**: [Sequelize Querying](https://sequelize.org/docs/v6/core-concepts/model-querying-basics/)
-
-**Used For:**
-- Database abstraction layer
-- Schema migrations
-- Model definitions
-- Query building
-
-## Frontend Templating
-
-### EJS (Embedded JavaScript)
-
-**EJS** is a simple templating language that lets you generate HTML markup with plain JavaScript.
-
-- **Official Documentation**: [ejs.co](https://ejs.co/)
-- **Syntax Reference**: [EJS Tags](https://ejs.co/#docs)
-- **GitHub Repository**: [github.com/mde/ejs](https://github.com/mde/ejs)
-
-**Used For:**
-- Server-side rendering of HTML pages
-- Dynamic content generation
-- User interface templates
-- Admin panel views
-
-## Infrastructure
-
-### Proxmox VE API
-
-**Proxmox Virtual Environment** provides a RESTful API for managing virtual machines and containers.
-
-- **API Documentation**: [pve.proxmox.com/pve-docs/api-viewer](https://pve.proxmox.com/pve-docs/api-viewer/)
-- **API Guide**: [Proxmox VE API](https://pve.proxmox.com/wiki/Proxmox_VE_API)
-- **Authentication**: [API Tokens](https://pve.proxmox.com/wiki/User_Management#pveum_tokens)
-
-**Used For:**
-- Container (LXC) creation and management
-- Node information retrieval
-- Resource allocation
-- Cluster status monitoring
-
-### LDAP Gateway
-
-**LDAPServer** is a custom Node.js-based LDAP server that integrates with our database for authentication.
-
-- **GitHub Repository**: [github.com/mieweb/LDAPServer](https://github.com/mieweb/LDAPServer)
-- **SSSD Documentation**: [sssd.io/docs](https://sssd.io/docs/)
-
-**Used For:**
-- Centralized authentication for all containers
-- User credential management
-- Group membership resolution
-- PAM/NSS integration via SSSD
-
-## Supporting Libraries
-
-### DNSMasq
-
-**DNSMasq** provides network infrastructure services including DHCP and DNS.
-
-- **Official Documentation**: [thekelleys.org.uk/dnsmasq/doc.html](http://www.thekelleys.org.uk/dnsmasq/doc.html)
-- **Man Page**: [dnsmasq(8)](https://linux.die.net/man/8/dnsmasq)
-
-**Used For:**
-- DHCP server for container IP assignment
-- DNS resolution for internal domain names
-- DNS forwarding for external queries
-
-### NGINX
-
-**NGINX** is a high-performance HTTP server and reverse proxy.
-
-- **Official Documentation**: [nginx.org/en/docs](https://nginx.org/en/docs/)
-- **Reverse Proxy Guide**: [NGINX Reverse Proxy](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/)
-- **SSL/TLS**: [NGINX SSL Configuration](https://nginx.org/en/docs/http/configuring_https_servers.html)
-
-**Used For:**
-- HTTP/HTTPS reverse proxy
-- TLS termination
-- Layer 4 TCP proxying
-- Load balancing
-
-## Development Tools
-
-### Node.js
-
-**Node.js** is the JavaScript runtime that powers the entire application stack.
-
-- **Official Documentation**: [nodejs.org/docs](https://nodejs.org/docs/)
-- **API Reference**: [Node.js API](https://nodejs.org/api/)
-- **Recommended Version**: 18+ LTS
-
-### npm
-
-**npm** is the package manager for Node.js.
-
-- **Official Documentation**: [docs.npmjs.com](https://docs.npmjs.com/)
-- **CLI Commands**: [npm CLI](https://docs.npmjs.com/cli/v10/commands)
-
-### Docker & Docker Compose
-
-**Docker** provides containerization for development and deployment, while **Docker Compose** orchestrates multi-container applications.
-
-- **Docker Documentation**: [docs.docker.com](https://docs.docker.com/)
-- **Docker Compose Documentation**: [docs.docker.com/compose](https://docs.docker.com/compose/)
-- **Dockerfile Reference**: [Dockerfile Reference](https://docs.docker.com/reference/dockerfile/)
-
-**Used For:**
-- Building container images for deployment
-- Local development environment (PostgreSQL via compose.yml)
-- CI/CD pipeline image building
-- Testing in isolated environments
-
-## Related Resources
-
-- [System Architecture](system-architecture): Understand how these technologies work together
-- [Development Workflow](development-workflow): Set up your development environment
-- [Contributing](contributing): Contribute to the project
-- [GitHub Repository](https://github.com/mieweb/opensource-server): View the source code
+External documentation for core components.
+
+| Component | Links |
+|-----------|-------|
+| **Express.js** | [Docs](https://expressjs.com/) · [API](https://expressjs.com/en/4x/api.html) |
+| **Sequelize ORM** | [Docs](https://sequelize.org/) · [Models](https://sequelize.org/docs/v6/core-concepts/model-basics/) · [Migrations](https://sequelize.org/docs/v6/other-topics/migrations/) |
+| **EJS** | [Docs](https://ejs.co/) · [Syntax](https://ejs.co/#docs) |
+| **Proxmox VE API** | [API Viewer](https://pve.proxmox.com/pve-docs/api-viewer/) · [Guide](https://pve.proxmox.com/wiki/Proxmox_VE_API) · [Tokens](https://pve.proxmox.com/wiki/User_Management#pveum_tokens) |
+| **LDAP Gateway** | [GitHub](https://github.com/mieweb/LDAPServer) · [SSSD Docs](https://sssd.io/docs/) |
+| **DNSMasq** | [Docs](http://www.thekelleys.org.uk/dnsmasq/doc.html) · [Man Page](https://linux.die.net/man/8/dnsmasq) |
+| **NGINX** | [Docs](https://nginx.org/en/docs/) · [Reverse Proxy](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/) |
+| **Node.js** | [Docs](https://nodejs.org/docs/) — 18+ LTS recommended |
+| **Docker** | [Docs](https://docs.docker.com/) · [Compose](https://docs.docker.com/compose/) |
 
 ## Version Requirements
 
-| Technology | Minimum Version | Recommended |
-|------------|----------------|-------------|
-| Node.js | 18.x | 20.x LTS |
-| Proxmox VE | 13.0 | Latest stable |
-| PostgreSQL | 12.x | 15.x+ |
-| MySQL | 8.0 | 8.0+ |
-| NGINX | 1.18 | Latest stable |
-
-## Additional Documentation
-
-For implementation-specific details, refer to:
-- Code comments in the repository
-- README files in individual directories
-- Migration files for database schema changes
-- Environment variable documentation in `.env.example`
+| Technology | Recommended   |
+|------------|---------------|
+| Node.js    | 24.x LTS      |
+| Proxmox VE | 13.0+         |
+| PostgreSQL | 18.0+         |
+| NGINX      | Latest stable |
diff --git a/mie-opensource-landing/docs/developers/database-schema.md b/mie-opensource-landing/docs/developers/database-schema.md
index 45931f8b..cf50775a 100644
--- a/mie-opensource-landing/docs/developers/database-schema.md
+++ b/mie-opensource-landing/docs/developers/database-schema.md
@@ -4,7 +4,7 @@ sidebar_position: 6
 
 # Database Schema
 
-The cluster management system uses a relational database to store all configuration, state, and user information. This document describes the database schema and relationships between tables.
+The cluster management system uses Sequelize ORM for database abstraction, supporting SQLite (default), PostgreSQL, and MySQL.
 
 ## Entity Relationship Diagram
 
@@ -167,338 +167,60 @@ erDiagram
 ## Core Models
 
 ### Site
-
-The **Site** model represents a top-level organizational unit, typically corresponding to a physical or logical Proxmox cluster location.
-
-**Key Fields:**
-- `name`: Display name for the site
-- `internalDomain`: Internal DNS domain (e.g., `cluster.internal`)
-- `dhcpRange`: IP range for container assignment (e.g., `192.168.1.100-192.168.1.200`)
-- `subnetMask`: Network subnet mask
-- `gateway`: Default gateway IP
-- `dnsForwarders`: Upstream DNS servers (comma-separated)
-
-**Relationships:**
-- Has many Nodes
-- Has many ExternalDomains
+Top-level organizational unit. Has many Nodes and ExternalDomains.
 
 ### Node
-
-The **Node** model represents a Proxmox VE server within a site.
-
-**Key Fields:**
-- `name`: Node name (must match Proxmox hostname)
-- `ipv4Address`: Node's IP address for DNS
-- `apiUrl`: Proxmox API endpoint
-- `apiTokenIdOrUsername`: Authentication credential (username or token ID)
-- `apiTokenSecretOrPassword`: Authentication secret
-- `disableTlsVerification`: Skip TLS certificate validation
-- `imageStorage`: Proxmox storage name for pulled Docker/OCI images (default: 'local')
-
-**Relationships:**
-- Belongs to Site
-- Has many Containers
-
-**Constraints:**
-- `name` is unique across all nodes
+Proxmox VE server within a site. `name` must match Proxmox hostname (unique). `imageStorage` defaults to `'local'`. Belongs to Site, has many Containers.
 
 ### Container
+LXC container on a Proxmox node. Unique composite index on `(nodeId, containerId)`. `hostname`, `macAddress`, `ipv4Address` globally unique. Belongs to Node and optionally to a Job.
 
-The **Container** model represents an LXC container running on a Proxmox node.
-
-**Key Fields:**
-- `hostname`: Container hostname (unique)
-- `username`: Owner of the container (who created it)
-- `status`: Container creation state ('pending', 'creating', 'running', 'failed')
-- `template`: Name of the Proxmox template or Docker image reference (e.g., `docker.io/library/nginx:latest`)
-- `creationJobId`: Foreign key to the Job that created this container (nullable)
-- `containerId`: Proxmox container ID (CTID)
-- `macAddress`: Unique MAC address (nullable for pending containers)
-- `ipv4Address`: Assigned IP address (nullable for pending containers)
-- `aiContainer`: AI container flag (default: 'N')
-
-**Relationships:**
-- Belongs to Node
-- Has many Services
-- Belongs to Job (optional, via creationJobId)
-
-**Constraints:**
-- Unique composite index on `(nodeId, containerId)`
-- `hostname`, `macAddress`, and `ipv4Address` are globally unique
-
-### Service (Base Model)
-
-The **Service** model uses Single Table Inheritance (STI) to represent different types of services exposed by containers.
-
-**Key Fields:**
-- `containerId`: Container exposing this service
-- `type`: Service type ('http', 'transport', or 'dns')
-- `containerPort`: Port number inside the container
-
-**Relationships:**
-- Belongs to Container
-- Has one HTTPService, TransportService, or DnsService (based on type)
-
-### HTTPService
-
-Represents HTTP/HTTPS services with automatic SSL certificate management.
-
-**Key Fields:**
-- `externalHostname`: Subdomain for the service (e.g., 'app' for 'app.example.com')
-- `externalDomainId`: External domain to use
-
-**Relationships:**
-- Belongs to Service (one-to-one)
-- Belongs to ExternalDomain
-
-**Constraints:**
-- Unique composite index on `(externalHostname, externalDomainId)`
-
-### TransportService
-
-Represents TCP/UDP services exposed via port mapping.
+### Service (STI)
+Base model with `type` discriminator (`http`, `transport`, `dns`). Belongs to Container.
 
-**Key Fields:**
-- `protocol`: 'tcp' or 'udp'
-- `externalPort`: Public port number
-- `useTls`: Whether to use TLS for TCP connections
-
-**Relationships:**
-- Belongs to Service (one-to-one)
-
-**Constraints:**
-- Unique composite index on `(protocol, externalPort)`
-
-**Static Methods:**
-- `findNextAvailablePort()`: Finds the next available external port
-
-### DnsService
-
-Represents services registered in DNS (typically SRV records).
-
-**Key Fields:**
-- `recordType`: DNS record type (currently only 'SRV' supported)
-- `serviceName`: Service name for DNS record
-
-**Relationships:**
-- Belongs to Service (one-to-one)
+- **HTTPService**: `(externalHostname, externalDomainId)` unique. Belongs to ExternalDomain.
+- **TransportService**: `(protocol, externalPort)` unique. `findNextAvailablePort()` static method.
+- **DnsService**: SRV records with `serviceName`.
 
 ### ExternalDomain
-
-The **ExternalDomain** model manages public domains for HTTP service exposure.
-
-**Key Fields:**
-- `domain`: Domain name (e.g., 'example.com')
-- `acmeEmail`: Email for certificate notifications
-- `acmeDirectory`: ACME CA endpoint URL
-- `cloudflareApiEmail`: Cloudflare account email
-- `cloudflareApiKey`: Cloudflare API key for DNS challenges
-
-**Relationships:**
-- Belongs to Site
-- Has many HTTPServices
+Manages public domains for HTTP service exposure. Belongs to Site, has many HTTPServices.
 
 ## User Management Models
 
 ### User
-
-The **User** model stores user accounts with LDAP-compatible attributes.
-
-**Key Fields:**
-- `uidNumber`: Unique user ID (starting at 2000)
-- `username`: Login username
-- `cn`: Common name (full name)
-- `sn`: Surname (last name)
-- `givenName`: First name
-- `mail`: Email address
-- `sshPublicKey`: SSH public key for container access
-- `userPassword`: Hashed password (argon2)
-- `status`: Account status ('pending', 'active', 'suspended')
-
-**Relationships:**
-- Belongs to many Groups (through UserGroups)
-
-**Security:**
-- Passwords are hashed with argon2 before storage
-- Only 'active' users can authenticate
-- First registered user is automatically added to 'sysadmins' group
-
-**Static Methods:**
-- `getNextUid()`: Returns next available UID starting at 2000
-
-**Instance Methods:**
-- `validatePassword(password)`: Verifies password against hash
+LDAP-compatible user accounts. Passwords hashed with argon2. UIDs start at 2000 (`getNextUid()`). Only `active` users can authenticate. First registered user auto-added to `sysadmins`.
 
 ### Group
-
-The **Group** model represents user groups with LDAP-compatible attributes.
-
-**Key Fields:**
-- `gidNumber`: Unique group ID
-- `cn`: Group name (common name)
-- `isAdministrator`: Whether group members have admin privileges
-
-**Relationships:**
-- Has many Users (through UserGroups)
-
-**Default Groups:**
-- `ldapusers` (gid: 2000): Standard container access
-- `sysadmins` (gid: 2001): Full cluster administration
+LDAP-compatible groups. Default groups: `ldapusers` (gid: 2000), `sysadmins` (gid: 2001).
 
 ### UserGroup
-
-The **UserGroup** model is a join table for the many-to-many User-Group relationship.
-
-**Key Fields:**
-- `uidNumber`: Foreign key to Users
-- `gidNumber`: Foreign key to Groups
-
-**Constraints:**
-- Composite primary key on `(uidNumber, gidNumber)`
+Join table. Composite primary key on `(uidNumber, gidNumber)`.
 
 ### PasswordResetToken
-
-The **PasswordResetToken** model stores password reset tokens for users.
-
-**Key Fields:**
-- `id`: UUID primary key
-- `uidNumber`: Foreign key to Users
-- `token`: Unique 64-character hex token
-- `expiresAt`: Token expiration timestamp
-- `used`: Whether the token has been used
-
-**Relationships:**
-- Belongs to User
-
-**Static Methods:**
-- `generateToken(uidNumber, expirationHours)`: Creates a new token (default 1 hour expiry)
-- `validateToken(token)`: Validates and returns token if valid and unused
-- `cleanup()`: Removes expired and used tokens
-
-**Instance Methods:**
-- `markAsUsed()`: Marks the token as used
+UUID-based tokens with 1-hour default expiry. Methods: `generateToken()`, `validateToken()`, `cleanup()`.
 
 ### InviteToken
+UUID-based invite tokens with 24-hour default expiry. Email tied to token and locked during registration. Methods: `generateToken()`, `validateToken()`, `cleanup()`.
 
-The **InviteToken** model stores user invitation tokens sent by administrators.
-
-**Key Fields:**
-- `id`: UUID primary key
-- `email`: Email address the invitation was sent to
-- `token`: Unique 64-character hex token
-- `expiresAt`: Token expiration timestamp (default 24 hours)
-- `used`: Whether the token has been used
-
-**Static Methods:**
-- `generateToken(email, expirationHours)`: Creates a new invite token (default 24 hour expiry)
-- `validateToken(token)`: Validates and returns token if valid, unused, and not expired
-- `cleanup()`: Removes expired and used tokens
-
-**Instance Methods:**
-- `markAsUsed()`: Marks the token as used after successful registration
-
-**Usage:**
-- Created when an admin invites a user via email
-- Validated during registration to auto-activate the user's account
-- Email is tied to the token and cannot be changed during registration
-
-## Job Management Models
+## Job Management
 
 ### Job
-
-The **Job** model tracks asynchronous operations.
-
-**Key Fields:**
-- `name`: Job description
-- `associatedResource`: Reference to related resource
-- `status`: Job state ('pending', 'running', 'success', 'failure', 'cancelled')
-
-**Relationships:**
-- Has many JobStatuses
+Tracks async operations (container creation, etc.). Statuses: `pending`, `running`, `success`, `failure`, `cancelled`.
 
 ### JobStatus
+Progress messages for a Job.
 
-The **JobStatus** model stores job execution history and progress messages.
-
-**Key Fields:**
-- `jobId`: Foreign key to Jobs
-- `message`: Status update message
-
-**Relationships:**
-- Belongs to Job
-
-## Session Management
-
-### SessionSecret
+## System
 
-The **SessionSecret** model stores express-session secrets.
-
-**Key Fields:**
-- `secret`: 32-64 character secret string
-
-**Constraints:**
-- `secret` is unique
-
-## System Settings
-
-### Setting
-
-The **Setting** model stores system-wide configuration key-value pairs.
-
-**Key Fields:**
-- `key`: Setting identifier (primary key)
-- `value`: Setting value (string)
-
-**Constraints:**
-- `key` is unique and serves as primary key
-
-**Current Settings:**
-- `push_notification_url`: URL for push notification service (empty by default)
-- `push_notification_enabled`: Whether push notification 2FA is enabled ('true' or 'false')
-
-**Static Methods:**
-- `get(key)`: Retrieve a setting value by key
-- `set(key, value)`: Create or update a setting
-- `getMultiple(keys)`: Retrieve multiple settings as an object
+- **SessionSecret**: Stores express-session secrets
+- **Setting**: Key-value pairs for system config. Methods: `get()`, `set()`, `getMultiple()`
 
 ## Database Abstraction
 
-The schema is implemented using **Sequelize ORM**, providing:
-
-- **Database Portability**: Supports SQLite (default), PostgreSQL, and MySQL
-- **Migrations**: Schema versioning and updates via `sequelize-cli`
-- **Validation**: Field-level validation rules
-- **Hooks**: Automatic password hashing, UID/GID assignment
-- **Associations**: Declarative relationship definitions
+Implemented with **Sequelize ORM**: supports SQLite (default), PostgreSQL, MySQL. Includes migrations, field validation, hooks (password hashing, UID assignment), and declarative associations.
 
 ## Key Design Patterns
 
-### Single Table Inheritance (STI)
-
-The Service model uses STI to handle different service types:
-- Base `Services` table with `type` discriminator
-- Child tables (`HTTPServices`, `TransportServices`, `DnsServices`) extend via one-to-one relationships
-- Allows polymorphic service handling while maintaining type-specific fields
-
-### LDAP Schema Compatibility
-
-User and Group models follow LDAP naming conventions:
-- `uidNumber` / `gidNumber` for numeric IDs
-- `cn` (common name) for names
-- `sn` (surname), `givenName` for user names
-- Enables seamless integration with LDAP authentication
-
-### Hierarchical Organization
-
-Resources are organized hierarchically:
-```
-Site → Nodes → Containers → Services
-```
-
-This mirrors the physical infrastructure topology and simplifies queries.
-
-## Next Steps
-
-- [System Architecture](system-architecture): Understand how the database integrates with other components
-- [Development Workflow](development-workflow): Learn how to create migrations
-- [Core Technologies](core-technologies): Sequelize ORM documentation
+- **Service STI**: Base `Services` table with `type` discriminator; child tables (`HTTPServices`, `TransportServices`, `DnsServices`) extend via one-to-one relationships
+- **LDAP compatibility**: User/Group models use LDAP naming (`uidNumber`, `gidNumber`, `cn`, `sn`, `givenName`)
+- **Hierarchy**: Site → Nodes → Containers → Services (mirrors physical topology)
diff --git a/mie-opensource-landing/docs/developers/development-workflow.md b/mie-opensource-landing/docs/developers/development-workflow.md
index cd5c6528..a2440a60 100644
--- a/mie-opensource-landing/docs/developers/development-workflow.md
+++ b/mie-opensource-landing/docs/developers/development-workflow.md
@@ -4,92 +4,37 @@ sidebar_position: 3
 
 # Development Workflow
 
-This guide covers setting up a local development environment and contributing to the cluster management software.
-
 ## Prerequisites
 
-To contribute to the cluster management software:
-
-1. **Node.js**: Version 18+ for the API server and LDAP gateway
-2. **Database**: SQLite (included), PostgreSQL, or MySQL
-3. **Proxmox Access**: A Proxmox VE 13+ instance for testing
-4. **Git**: For version control and contributions
-
-## Local Development Setup
+- **Node.js 18+**, **Git**, and optionally **Docker** for PostgreSQL
+- **Proxmox VE 13+** instance for testing
+- SQLite works out of the box; PostgreSQL/MySQL optional
 
-### Option 1: Using Docker Compose (Recommended)
+## Local Setup
 
-The simplest way to develop is using the included Docker Compose setup which provides a PostgreSQL database:
+### With Docker Compose (Recommended)
 
 ```bash
-# Clone the repository
 git clone https://github.com/mieweb/opensource-server
 cd opensource-server/create-a-container
-
-# Configure environment
-cp example.env .env
-# Edit .env with your Proxmox settings and database configuration:
-#   DATABASE_DIALECT=postgres
-#   POSTGRES_HOST=localhost
-#   POSTGRES_PORT=5432
-#   POSTGRES_USER=your_user
-#   POSTGRES_PASSWORD=your_password
-#   POSTGRES_DATABASE=your_db
-
-# Start PostgreSQL
-docker compose up -d
-
-# Install dependencies
+cp example.env .env   # Edit with your Proxmox/DB settings
+docker compose up -d   # Start PostgreSQL
 npm install
-
-# Run database migrations
 npm run db:migrate
-
-# Start the development server
 npm run dev
 ```
 
-### Option 2: Manual Setup
-
-For development without Docker:
+### Without Docker
 
 ```bash
-# Clone the repository
 git clone https://github.com/mieweb/opensource-server
 cd opensource-server/create-a-container
-
-# Install dependencies
+cp example.env .env   # Edit settings (SQLite: no DB setup needed)
 npm install
-
-# Configure environment
-cp example.env .env
-# Edit .env with your Proxmox and database settings
-# For SQLite (default): no additional database setup required
-# For PostgreSQL/MySQL: ensure database server is running
-
-# Run database migrations
 npm run db:migrate
-
-# Start the development server
 npm run dev
 ```
 
-## Architecture Overview
-
-**Frontend:**
-- EJS-based server-rendered UI for user and admin interfaces
-- Rendered by the Express API server
-
-**Backend API:**
-- Express.js REST API server
-- Sequelize ORM for database abstraction
-- Routes for user, admin, and container management
-
-**LDAP Server:**
-- Standalone Node.js process
-- Reads from the shared database
-- Handles LDAP bind and search operations
-
 ## Key Directories
 
 ```
@@ -98,127 +43,33 @@ create-a-container/
 ├── routers/         # Express API route handlers
 ├── middlewares/     # Authentication & authorization
 ├── migrations/      # Database schema migrations
-├── views/           # Server-rendered templates
+├── views/           # Server-rendered EJS templates
 └── public/          # Static assets
 ```
 
-## Development Best Practices
-
-### Code Style
-
-- Follow the existing code style and conventions
-- Use meaningful variable and function names
-- Add comments for complex logic
-- Keep functions small and focused
-
-### Database Changes
-
-- Always create migrations for schema changes
-- Test migrations with both up and down
-- Use transactions for multi-step migrations
-- Document breaking changes
-
-### API Development
-
-- Follow RESTful conventions
-- Validate input data before processing
-- Return appropriate HTTP status codes
-- Document new endpoints
-
-### Testing
+## Database Changes
 
-Before submitting changes:
+Always create migrations for schema changes. Test both up and down. Use transactions for multi-step migrations.
 
-- Test container creation and deletion
-- Verify DNS resolution and NGINX routing
-- Ensure LDAP authentication works correctly
-- Run the test suite: `npm test`
-- Check for linting errors: `npm run lint`
-
-## Debugging
-
-### Local Docker Image Build
-
-You can build and test the Docker image locally before deploying:
+## Local Docker Image Build
 
 ```bash
-# Build the Docker image from the repository root
 docker build -t opensource-server:dev .
-
-# Run the container (requires systemd support)
-docker run -d --privileged \
-  --name opensource-test \
-  -p 80:80 -p 443:443 -p 53:53/udp \
-  opensource-server:dev
-
-# View container logs
-docker logs -f opensource-test
-
-# Access a shell in the container
-docker exec -it opensource-test bash
-
-# Stop and remove the test container
-docker stop opensource-test && docker rm opensource-test
+docker run -d --privileged --name opensource-test \
+  -p 80:80 -p 443:443 -p 53:53/udp opensource-server:dev
 ```
 
-**Note:** The Dockerfile copies your local repository code (including uncommitted changes), making it ideal for testing changes before pushing to GitHub.
-
-### CI/CD Pipeline
+Copies your local code (including uncommitted changes) — ideal for testing before pushing.
 
-The project uses GitHub Actions to automatically build and push Docker images:
+## CI/CD
 
-- **Trigger**: On every push to any branch
-- **Registry**: GitHub Container Registry (ghcr.io)
-- **Tags**: 
-  - Branch name (e.g., `sprint`, `main`)
-  - `latest` tag for main branch only
-- **Build optimization**: Uses GitHub Actions cache for faster builds
+GitHub Actions builds and pushes Docker images on every push. Tags: branch name, `latest` (main only). Workflow: `.github/workflows/docker-build-push.yml`.
 
-The workflow file is located at `.github/workflows/docker-build-push.yml`.
-
-### API Server
+## Debugging
 
 ```bash
-# Run with debugging output
-DEBUG=* npm run dev
-
-# Or use Node inspector
-node --inspect index.js
+DEBUG=* npm run dev          # Verbose output
+node --inspect index.js      # Node inspector
+DB_LOGGING=true npm run dev  # Sequelize query logging
 ```
 
-### Database Queries
-
-Enable Sequelize query logging in your environment:
-
-```
-DB_LOGGING=true
-```
-
-### Common Issues
-
-**Port Already in Use:**
-- Check for existing processes: `lsof -i :3000`
-- Kill the process or use a different port
-
-**Database Connection Errors:**
-- Verify database credentials in `.env`
-- Ensure database service is running (for Docker: `docker compose ps`)
-- Check network connectivity
-- For PostgreSQL via Docker Compose: ensure ports are not in use
-
-**Docker Compose Issues:**
-- Check container status: `docker compose ps`
-- View logs: `docker compose logs postgres`
-- Restart services: `docker compose restart`
-- Clean start: `docker compose down -v && docker compose up -d`
-
-**Proxmox API Errors:**
-- Verify API credentials are correct
-- Check TLS certificate settings
-- Ensure Proxmox node is reachable
-
-## Next Steps
-
-- Review the [Contributing Guide](contributing) for submission guidelines
-- Check the [System Architecture](system-architecture) to understand component interactions
-- Visit the [GitHub repository](https://github.com/mieweb/opensource-server) for open issues
diff --git a/mie-opensource-landing/docs/developers/docker-images.md b/mie-opensource-landing/docs/developers/docker-images.md
new file mode 100644
index 00000000..0ebd6115
--- /dev/null
+++ b/mie-opensource-landing/docs/developers/docker-images.md
@@ -0,0 +1,175 @@
+---
+sidebar_position: 5
+---
+
+# Docker Images
+
+OCI container images automatically built and published to GitHub Container Registry (GHCR). Used as base templates for Proxmox containers.
+
+## Available Images
+
+:::note
+For custom *application* images (not new base images), see [Building Custom Images](/docs/users/creating-containers/using-environment-variables).
+:::
+
+### Debian 13 (`base`)
+
+Debian 13 with systemd (PID 1), SSSD for LDAP authentication, and PAM auto-homedir. Environment variables stored in `/etc/environment`.
+
+**Registry:** `ghcr.io/mieweb/opensource-server/base` · **Source:** [`images/base/`](https://github.com/mieweb/opensource-server/tree/main/images/base)
+
+### NodeJS 24 (`nodejs`)
+
+Extends base with Node.js 24 from NodeSource. Inherits LDAP authentication.
+
+**Registry:** `ghcr.io/mieweb/opensource-server/nodejs` · **Source:** [`images/nodejs/`](https://github.com/mieweb/opensource-server/tree/main/images/nodejs)
+
+## Build System
+
+Images use **Docker Bake** (`docker buildx bake`) with [`images/docker-bake.hcl`](https://github.com/mieweb/opensource-server/blob/main/images/docker-bake.hcl) defining build order and dependencies. The `contexts` attribute ensures proper ordering (e.g., nodejs depends on base).
+
+```
+images/
+├── docker-bake.hcl          # Build config with dependency ordering
+├── base/
+│   ├── Dockerfile
+│   ├── sssd.conf
+│   └── ldapusers
+└── nodejs/
+    └── Dockerfile           # Extends base image
+```
+
+## CI Workflow
+
+[`build-images.yml`](https://github.com/mieweb/opensource-server/blob/main/.github/workflows/build-images.yml) builds and pushes all images via Docker Bake.
+
+### Triggers
+
+| Trigger | Condition |
+|---------|-----------|
+| Push | Any branch, when files in `images/` change |
+| Tag | Any tag push |
+| Schedule | Weekly — Sunday 11PM UTC |
+| Manual | `workflow_dispatch` from Actions tab |
+
+### How it works
+
+1. Checks out the repo and sets up Docker Buildx
+2. Logs into GHCR using `GITHUB_TOKEN`
+3. Runs a **Docker Meta** step per image to generate tags
+4. Runs `docker buildx bake` with the HCL file + all meta bake files, pushing in dependency order
+5. Uses per-image GitHub Actions cache (`scope=<image>-<branch>`)
+
+### Tags
+
+Each Docker Meta step produces these tags:
+
+| `type=` | Result | When |
+|---------|--------|------|
+| `sha` | `base:sha-d00911c` | Always |
+| `ref,event=branch` | `base:main` | Branch pushes |
+| `ref,event=tag` | `base:v1.0.0` | Tag pushes |
+| `raw,value=latest,enable=...` | `base:latest` | Main branch only |
+
+### Adding your image to the workflow
+
+Add a new **Docker Meta** step and wire it into the **Build and push** step:
+
+```yaml
+      # 1. Add a metadata step (copy an existing one, change image name and bake-target)
+      - name: Docker Meta (Your Image)
+        id: meta-your-image
+        uses: docker/metadata-action@v5
+        with:
+          images: ${{ env.REGISTRY }}/${{ github.repository }}/your-image
+          bake-target: your-image
+          tags: |
+            type=sha
+            type=ref,event=branch
+            type=ref,event=tag
+            type=raw,value=latest,enable=${{ github.ref == 'refs/heads/main' }}
+
+      # 2. In the "Build and push" step, append to `files:` and `set:`
+      - name: Build and push
+        uses: docker/bake-action@v5
+        with:
+          workdir: ./images
+          push: true
+          files: |
+            ./docker-bake.hcl
+            ${{ steps.meta-base.outputs.bake-file }}
+            ${{ steps.meta-nodejs.outputs.bake-file }}
+            ${{ steps.meta-your-image.outputs.bake-file }}    # add this
+          set: |
+            # ... existing cache lines ...
+            your-image.cache-from=type=gha,scope=your-image-${{ github.ref_name }}
+            your-image.cache-to=type=gha,mode=max,scope=your-image-${{ github.ref_name }}
+```
+
+The `bake-target` must match the target name in `docker-bake.hcl`. The metadata action generates a bake file that overrides that target's `tags` array.
+
+## Adding a New Base Image
+
+Add a base image when a runtime is commonly needed by multiple users and requires system-level configuration. Don't add images for single-use or org-specific software.
+
+### 1. Create the Dockerfile
+
+Create a new directory under `images/` with a Dockerfile:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM base
+
+# Install your runtime
+RUN apt-get update && \
+    apt-get install -y your-packages && \
+    apt-get clean && rm -rf /var/lib/apt/lists/*
+```
+
+**Rules:**
+- `FROM base` — Docker Bake resolves this to the freshly built base image via `contexts`
+- Use `EXPOSE` to declare ports that should become container Services automatically
+- Use `LABEL org.mieweb.opensource-server.services.http.default-port=<port>` to set a default HTTP port (associated with `<hostname>.<externalDomainName>`)
+- **Never** set `CMD`, `ENTRYPOINT`, `WORKDIR`, or `USER` — base images run systemd as PID 1
+
+### 2. Update docker-bake.hcl
+
+Add a target and include it in the default group:
+
+```hcl
+group "default" {
+    targets = ["base", "nodejs", "your-image"]
+}
+
+target "your-image" {
+    context = "./your-image"
+    contexts = {
+        base = "target:base"
+    }
+}
+```
+
+### 3. Update the CI workflow
+
+Add a Docker Meta step and wire it into the build step as described in [Adding your image to the workflow](#adding-your-image-to-the-workflow) above.
+
+### 4. Test locally
+
+```bash
+cd images && docker buildx bake your-image
+```
+
+Verify: runtime installed, systemd running, `/etc/environment` exists.
+
+### 5. Update docs and frontend
+
+- Add the image to the [Available Images](#available-images) section above
+- Update `docs/users/creating-containers/web-gui.mdx` template list
+- Update `create-a-container/views/containers/form.ejs` dropdown
+
+### 6. Submit PR
+
+```bash
+git add images/your-image/ images/docker-bake.hcl .github/workflows/build-images.yml
+git commit -m "Add your-image base image"
+```
diff --git a/mie-opensource-landing/docs/developers/system-architecture.md b/mie-opensource-landing/docs/developers/system-architecture.md
index 1ae27373..da30ef37 100644
--- a/mie-opensource-landing/docs/developers/system-architecture.md
+++ b/mie-opensource-landing/docs/developers/system-architecture.md
@@ -4,9 +4,7 @@ sidebar_position: 2
 
 # System Architecture
 
-The MIE Opensource Proxmox Cluster is built on a carefully integrated stack of open-source technologies that work together to provide automated container hosting and management.
-
-## System Architecture
+## Overview
 
 ```mermaid
 graph TB
@@ -53,136 +51,16 @@ graph TB
     class PushNotif external
 ```
 
-## Core Components
-
-### Proxmox VE 13+
-
-**Proxmox Virtual Environment** serves as the hypervisor layer, providing virtualization capabilities through KVM and LXC. Version 13 or higher is required for OCI image support.
-
-**Key Features:**
-- LXC (Linux Containers) management for lightweight compute nodes
-- API-driven automation for container lifecycle management
-- Web interface for manual container administration
-- Clustering support for high availability
-
-**Integration:**
-- The management API communicates with Proxmox via REST API
-- [Nodes](/docs/admins/nodes) are registered Proxmox servers in the cluster
-- [Containers](/docs/admins/containers) are LXC instances managed by Proxmox
-
-### DNSMasq
-
-**DNSMasq** provides both DHCP and DNS services for the cluster network.
-
-**DHCP Functionality:**
-- Automatically assigns IP addresses to new containers from the configured range
-- Containers and [nodes](/docs/admins/nodes) reserve their assigned IPs for stability
-- IP reservations persist across container restarts and lifecycle events
-
-**DNS Functionality:**
-- Provides name resolution for containers within the cluster
-- Internal domain structure: `container-name.cluster.internal`
-- Forwards external DNS queries to configured upstream servers
-
-**Integration:**
-- Management API updates DNSMasq configuration when containers are created/destroyed
-- IP assignments are tracked in the backend database
-- DNS records are automatically created for all cluster resources
-
-### NGINX
-
-**NGINX** handles all ingress traffic to containers, supporting both HTTP/HTTPS and TCP protocols.
-
-**Layer 7 HTTP Proxying:**
-- Terminates TLS for HTTPS traffic
-- Routes requests based on hostname/subdomain
-- Automatically obtains and renews SSL certificates for [external domains](/docs/admins/external-domains)
-- Supports multiple domains and subdomains per container
-
-**Layer 4 TCP Proxying:**
-- Proxies non-HTTP protocols (SSH, databases, custom services)
-- Port mapping from external ports to container services
-- Transparent connection handling
-
-**Integration:**
-- Configuration is automatically generated based on container services
-- Certificate management integrated with ACME providers (Let's Encrypt)
-- Dynamic backend resolution using DNSMasq for container IPs
-
-### LDAP Gateway
-
-The **LDAP Gateway** is a Node.js-based LDAP server that provides centralized authentication for all cluster services.
-
-**Repository:** [github.com/mieweb/LDAPServer](https://github.com/mieweb/LDAPServer)
+## Components
 
-**Functionality:**
-- Serves LDAP authentication requests from containers
-- Retrieves user and group data from the backend database
-- Provides unified login credentials across all cluster resources
-- Integrates with standard PAM/NSS on Linux containers
-
-**User Management:**
-- Users authenticate with cluster-wide credentials
-- Group memberships determine access permissions
-- Password changes propagate immediately to all services
-
-**Integration:**
-- Containers configure PAM to authenticate against the LDAP server
-- All users in the `ldapusers` group can SSH into containers
-- User data synchronized from the backend database
-
-### Push Notification Service
-
-The **Push Notification Service** provides two-factor authentication (2FA) via push notifications to users' mobile devices.
-
-**Repository:** [github.com/mieweb/mieweb_auth_app](https://github.com/mieweb/mieweb_auth_app)
-
-**Functionality:**
-- Sends push notifications to users' registered devices during login
-- Allows users to approve or reject login attempts
-- Handles device registration and management
-- Provides timeout mechanism for unanswered notifications
-
-**Authentication Flow:**
-- API server sends notification request with username
-- Service delivers push notification to user's device
-- User approves/rejects the login attempt on their device
-- Service returns the user's decision to the API server
-- API server grants or denies access based on the response
-
-**Integration:**
-- Configurable via the [Settings page](/docs/admins/settings) (admin only)
-- LDAP gateway uses the notification service when `AUTH_BACKENDS` includes `notification`
-- API server validates credentials before sending push notifications
-- Notification URL configured in database settings and propagated to `ldap.conf`
-
-**Configuration:**
-- Push notification URL stored in `Settings` table
-- Feature enabled/disabled via admin interface
-- LDAP containers automatically updated with notification URL
-- No additional container configuration required
-
-### Backend Database
-
-The **backend database** stores all cluster state and configuration.
-
-**Supported Databases:**
-- **SQLite** (default): Simple file-based database, no additional setup required
-- **PostgreSQL**: Production-grade relational database for larger deployments
-- **MySQL**: Alternative production database option
-
-**ORM Abstraction:**
-- Uses Sequelize ORM for database abstraction
-- Allows switching between database backends without code changes
-- Handles migrations for schema updates
-
-**Stored Data:**
-- User accounts and authentication credentials
-- Group definitions and memberships
-- Site configurations (network settings, domains)
-- Node registrations (Proxmox API endpoints)
-- Container metadata (IPs, ports, services)
-- Service exposure rules and SSL certificate info
+| Component | Role |
+|-----------|------|
+| **Proxmox VE 13+** | Hypervisor — manages LXC containers via REST API. [Nodes](/docs/admins/core-concepts/nodes) are registered Proxmox servers. |
+| **DNSMasq** | DHCP + DNS. Auto-assigns IPs to containers, provides internal name resolution (`container.cluster.internal`). |
+| **NGINX** | Reverse proxy — L7 (HTTP/HTTPS with auto TLS via ACME) and L4 (TCP port mapping). Config auto-generated from container services. |
+| **LDAP Gateway** | Node.js LDAP server ([source](https://github.com/mieweb/LDAPServer)). Reads users/groups from the DB; containers authenticate via PAM/SSSD. |
+| **Push Notification Service** | 2FA via push notifications ([source](https://github.com/mieweb/mieweb_auth_app)). Configured in [Settings](/docs/admins/settings). Used by LDAP gateway when `AUTH_BACKENDS` includes `notification`. |
+| **Database** | SQLite (default), PostgreSQL, or MySQL via Sequelize ORM. Stores users, groups, sites, nodes, containers, and service config. |
 
 ## Data Flow
 
@@ -267,14 +145,3 @@ sequenceDiagram
     NGINX-->>Client: HTTPS response
 ```
 
-## Next Steps
-
-For more information:
-
-- [Development Workflow](development-workflow): Set up your development environment
-- [Contributing](contributing): Learn how to contribute to the project
-- [Administrator Documentation](/docs/admins/): Configure and manage the cluster
-- [User Documentation](/docs/users/creating-containers/web-gui): Create and deploy containers
-- [GitHub Repository](https://github.com/mieweb/opensource-server): Source code and issues
-- [GitHub Repository](https://github.com/mieweb/opensource-server): Source code and issues
-
diff --git a/mie-opensource-landing/docs/img/container-charts.png b/mie-opensource-landing/docs/img/container-charts.png
deleted file mode 100644
index fc58aa4e..00000000
Binary files a/mie-opensource-landing/docs/img/container-charts.png and /dev/null differ
diff --git a/mie-opensource-landing/docs/img/container-metrics.png b/mie-opensource-landing/docs/img/container-metrics.png
deleted file mode 100644
index 22b6d6e2..00000000
Binary files a/mie-opensource-landing/docs/img/container-metrics.png and /dev/null differ
diff --git a/mie-opensource-landing/docs/img/fingerprint.jpg b/mie-opensource-landing/docs/img/fingerprint.jpg
deleted file mode 100644
index e0b71473..00000000
Binary files a/mie-opensource-landing/docs/img/fingerprint.jpg and /dev/null differ
diff --git a/mie-opensource-landing/docs/img/image.png b/mie-opensource-landing/docs/img/image.png
deleted file mode 100644
index 6452739b..00000000
Binary files a/mie-opensource-landing/docs/img/image.png and /dev/null differ
diff --git a/mie-opensource-landing/docs/img/proxmox-container-dashboard.png b/mie-opensource-landing/docs/img/proxmox-container-dashboard.png
deleted file mode 100644
index 4fca8709..00000000
Binary files a/mie-opensource-landing/docs/img/proxmox-container-dashboard.png and /dev/null differ
diff --git a/mie-opensource-landing/docs/img/proxmox_shell.png b/mie-opensource-landing/docs/img/proxmox_shell.png
deleted file mode 100644
index bebb11c4..00000000
Binary files a/mie-opensource-landing/docs/img/proxmox_shell.png and /dev/null differ
diff --git a/mie-opensource-landing/docs/intro.mdx b/mie-opensource-landing/docs/intro.mdx
index 2c2eb11a..055d742b 100644
--- a/mie-opensource-landing/docs/intro.mdx
+++ b/mie-opensource-landing/docs/intro.mdx
@@ -2,58 +2,12 @@
 sidebar_position: 1
 ---
 
-import { ProxmoxUrl } from '@site/src/components/InstanceUrl';
-
 # Introduction
 
-Welcome to the documentation for the **Opensource Proxmox Cluster** at MIE (Medical Informatics Engineering). This platform provides access to virtualized infrastructure for building, testing, and deploying applications in a collaborative opensource environment.
-
-## Key Features
-
-- **Free Opensource Infrastructure**: Access to enterprise-grade virtualization at no cost
-- **Flexible Container Support**: Run both lightweight and resource-intensive containers (LXC)
-- **Automated Deployments**: Integrate with GitHub Actions for seamless CI/CD
-- **Collaborative Environment**: Share resources and collaborate with others
-- **Scalable Resources**: CPU, memory, and storage allocated based on project needs
-
-## 🎯 Find Your Path
-
-This documentation is organized to help you quickly find what you need:
-
-### I want to deploy a new service to the cluster
-
-Start here: **[Using the Web GUI →](/docs/users/creating-containers/web-gui)**
-
-You'll learn how to:
-- Create and manage Linux containers (LXC)
-- Expose services through our network
-- Deploy applications automatically with GitHub integration
-- Develop remotely using VSCode
-
-**Prerequisites:**
-- Valid Proxmox account with PVE Realm access at <ProxmoxUrl><ProxmoxUrl /></ProxmoxUrl>
-- Basic understanding of virtualization concepts
-
-### I'm managing or installing a cluster
-
-Start here: **[Admin Documentation →](/docs/admins/)**
-
-You'll find information about:
-- Cluster installation and configuration
-- User management and access control
-- Infrastructure maintenance
-- System monitoring and troubleshooting
-
-:::note Coming Soon
-Admin documentation is currently being developed. Check back soon for comprehensive guides on cluster management.
-:::
-
-### I'm interested in contributing to the project
+The **Opensource Proxmox Cluster** provides free, shared virtualization infrastructure for building, testing, and deploying applications using LXC containers and GitHub Actions CI/CD.
 
-Start here: **[System Architecture →](/docs/developers/system-architecture)**
+## Find Your Path
 
-You'll learn about:
-- Cluster architecture and infrastructure
-- How the automation systems work
-- Contributing to the codebase
-- Development workflows and best practices
+- **[Deploy a service →](/docs/users/creating-containers/web-gui)** — Create and manage containers, expose services, set up CI/CD
+- **[Manage a cluster →](/docs/admins/)** — Installation, configuration, user management
+- **[Contribute →](/docs/developers/system-architecture)** — Architecture, automation internals, development workflows
diff --git a/mie-opensource-landing/docs/users/creating-containers/api-keys.mdx b/mie-opensource-landing/docs/users/creating-containers/api-keys.mdx
index 7aab62d6..0617afa6 100644
--- a/mie-opensource-landing/docs/users/creating-containers/api-keys.mdx
+++ b/mie-opensource-landing/docs/users/creating-containers/api-keys.mdx
@@ -4,174 +4,32 @@ sidebar_position: 3
 
 # API Keys
 
-API keys provide a secure way to authenticate API requests without using your password. They are ideal for automation, CI/CD pipelines, and third-party integrations.
+API keys authenticate API requests without using your password.
 
-## Benefits of API Keys
+## Managing API Keys
 
-- **Passwordless authentication**: Access the API without exposing your password
-- **Selective access**: Create multiple keys for different purposes
-- **Easy revocation**: Revoke individual keys without changing your password
-- **Usage tracking**: Monitor when each key was last used
-
-## Managing Your API Keys
-
-### Viewing Your API Keys
-
-Navigate to the API Keys page from the main navigation menu to view all your active keys.
+Navigate to **API Keys** from the main navigation.
 
 ![API Keys List](/img/apikeys-list-with-key.png)
 
-When you first visit this page with no keys created, you'll see an empty list:
-
-![Empty API Keys List](/img/apikeys-list-empty.png)
-
-### Creating a New API Key
-
-1. Click the **"+ New API Key"** button at the top of the API Keys page
-
-![Create API Key Form](/img/apikeys-create-form.png)
-
-2. (Optional) Enter a description to help identify the key's purpose, such as:
-   - "Production API access"
-   - "Mobile app"
-   - "CI/CD pipeline"
-   - "Development testing"
+### Creating a Key
 
+1. Click **"+ New API Key"**
+2. (Optional) Enter a description (e.g., "CI/CD pipeline")
 3. Click **"Generate API Key"**
 
-4. **Important**: The full API key will be displayed only once. Copy it immediately and store it securely.
-
 ![API Key Created Success](/img/apikeys-created-success.png)
 
 :::danger Critical
-This is the only time you will see the complete API key. The server does not store the full key - only a secure hash. If you lose the key, you will need to create a new one.
+The full key is shown only once. Copy it immediately. The server stores only a hash — lost keys cannot be recovered.
 :::
 
-5. Use the **Copy** button to copy the key to your clipboard
+### Viewing Key Details
 
-### Viewing API Key Details
-
-Click the **View** button next to any API key to see its details:
+Click **View** on any key to see its prefix, description, creation date, and last-used timestamp.
 
 ![API Key Details](/img/apikeys-details.png)
 
-The details page shows:
-- **Key Prefix**: First 8 characters followed by asterisks (for identification)
-- **Description**: The description you provided when creating the key
-- **Key ID**: Unique identifier (UUID) for the key
-- **Created**: When the key was created
-- **Last Updated**: When the key was last modified
-- **Last Used**: When the key was last used to authenticate a request (or "Never used")
-
-### Deleting an API Key
-
-To revoke an API key:
-
-1. Navigate to the API Keys list page
-2. Click the **Delete** button next to the key you want to remove
-3. Confirm the deletion
-
-Or from the key details page, click the **Delete Key** button.
-
-:::tip Tip
-If an API key is compromised, delete it immediately and create a new one. This won't affect your other keys or your password.
-:::
-
-## Using Your API Key
-
-### Authentication Header
-
-Include your API key in the `Authorization` header of your API requests using the Bearer scheme:
-
-```bash
-Authorization: Bearer YOUR_API_KEY
-```
-
-### Example with curl
-
-Replace `YOUR_API_KEY` with your actual API key:
-
-```bash
-curl -H "Authorization: Bearer YOUR_API_KEY" \
-  https://create-a-container.opensource.mieweb.org/api/containers
-```
-
-### Complete Example: Creating a Container
-
-Here's a complete example of creating a container using an API key:
-
-```bash
-# Set your API key
-API_KEY="your_api_key_here"
-
-# Create a container
-curl -X POST 'https://create-a-container.opensource.mieweb.org/api/containers' \
-  -H "Authorization: Bearer $API_KEY" \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "hostname": "mycontainer",
-    "siteId": 1,
-    "memory": 2048,
-    "swap": 512,
-    "disk": 8,
-    "cores": 2,
-    "ostemplate": "debian-12-standard_12.7-1_amd64.tar.zst",
-    "password": "securepassword"
-  }'
-```
-
-## Security Best Practices
-
-1. **Store keys securely**: 
-   - Never commit API keys to version control
-   - Use environment variables or secure secret management systems
-   - Encrypt keys when storing them
-
-2. **Use descriptive names**: 
-   - Give each key a clear description of its purpose
-   - This makes it easier to identify and revoke keys when needed
-
-3. **Rotate keys regularly**: 
-   - Periodically create new keys and delete old ones
-   - This limits the exposure window if a key is compromised
-
-4. **Use separate keys**: 
-   - Create different keys for different applications or environments
-   - This allows you to revoke access to specific applications without affecting others
-
-5. **Monitor usage**: 
-   - Regularly check the "Last Used" timestamp on the API Keys page
-   - Delete keys that haven't been used in a long time
-
-6. **Revoke immediately if compromised**: 
-   - If you suspect a key has been exposed, delete it immediately
-   - Create a new key for legitimate use
-
-## Troubleshooting
-
-### "Invalid or missing API key" error
-
-- Verify you're including the `Authorization` header with the correct format
-- Ensure the key hasn't been deleted from your account
-- Check that you copied the entire key (they are 43 characters long)
-
-### "Unauthorized" error
-
-- Verify your account has the necessary permissions for the action
-- Check that you're accessing endpoints that support API key authentication
-
-### Key not working after creation
-
-- Ensure you copied the key from the success page (it's only shown once)
-- Verify there are no extra spaces or line breaks in the key
-- Check that the key wasn't accidentally deleted
-
-## API Endpoints Supporting API Keys
-
-API keys work with all API endpoints that require authentication. For a complete list of available API endpoints, see the [API Documentation using curl](./command-line.mdx).
+### Deleting a Key
 
-Common endpoints include:
-- `/api/containers` - List and create containers
-- `/api/containers/:id` - Get, update, or delete a specific container
-- `/api/jobs` - List and manage jobs
-- `/api/sites` - View site information
+Click **Delete** from the list or details page. Other keys and your password are unaffected.
diff --git a/mie-opensource-landing/docs/users/creating-containers/command-line.mdx b/mie-opensource-landing/docs/users/creating-containers/command-line.mdx
index 8389505a..b3c029f9 100644
--- a/mie-opensource-landing/docs/users/creating-containers/command-line.mdx
+++ b/mie-opensource-landing/docs/users/creating-containers/command-line.mdx
@@ -6,58 +6,32 @@ import { ProxmoxUrl, ContainerCreationUrl } from '@site/src/components/InstanceU
 
 # Using the API with curl
 
-:::note Note
-This walkthrough assumes that you already have a registered account in the cluster. If not, see [Introduction](/docs/intro).
+:::caution Outdated Documentation
+This page predates the last major rewrite and may not be accurate. Check back weekly for updates.
 :::
 
-This guide shows you how to create a basic LXC container on the MIE Opensource Proxmox Cluster using the REST API with curl commands.
+API endpoint: <ContainerCreationUrl />
 
-The API endpoint is: <ContainerCreationUrl />
+**Prerequisites:**
 
-## Prerequisites
-
-- Active user account with appropriate permissions
-- An API key (see [API Keys](./api-keys.mdx) for how to create one)
-- Access to a terminal with `curl` installed
-- Knowledge of your site ID (available from the web interface)
-
-## Authentication
-
-The API uses API key authentication. Include your API key in the `Authorization` header for all requests:
-
-```bash
-curl -H "Authorization: Bearer YOUR_API_KEY" \
-  https://create-a-container.opensource.mieweb.org/api/containers
-```
-
-For details on creating and managing API keys, see the [API Keys documentation](./api-keys.mdx).
+* Active account, an [API key](./api-keys.mdx), `curl`, and your site ID (from the web interface).
 
 ## 1. List Available Templates
 
-Before creating a container, you need to know what templates are available:
-
 ```bash
 curl -X GET 'https://create-a-container.opensource.mieweb.org/api/templates' \
   -H "Authorization: Bearer YOUR_API_KEY"
 ```
 
-This returns a JSON array of available templates with their node and VMID information.
-
 ## 2. Get External Domain IDs
 
-To configure HTTP services, you need the external domain ID:
-
 ```bash
 curl -X GET 'https://create-a-container.opensource.mieweb.org/api/external-domains' \
   -H "Authorization: Bearer YOUR_API_KEY"
 ```
 
-This returns a JSON array of available external domains with their IDs.
-
 ## 3. Create a Container
 
-Create a new container by POSTing to the containers endpoint:
-
 ```bash
 curl -X POST 'https://create-a-container.opensource.mieweb.org/sites/1/containers' \
   -H "Authorization: Bearer YOUR_API_KEY" \
@@ -72,63 +46,24 @@ curl -X POST 'https://create-a-container.opensource.mieweb.org/sites/1/container
   --data-urlencode 'services[1][externalDomainId]=1'
 ```
 
-**Required Parameters:**
-- `hostname` - Container hostname (letters, numbers, hyphens only)
-- `template` - Template to clone, format: `nodeName,templateVmid`
+**Required:** `hostname` (letters/numbers/hyphens), `template` (`nodeName,templateVmid`).
 
-**Service Configuration:**
+### Service Types
 
-Services are configured using a zero-indexed array. Each service needs an index starting from 0:
+Services use a zero-indexed array (`services[0]`, `services[1]`, etc.):
 
-**SSH Service (TCP) - Index 0:**
-```bash
---data-urlencode 'services[0][type]=tcp' \
---data-urlencode 'services[0][internalPort]=22'
-```
-- `type` - Must be `tcp` for SSH
-- `internalPort` - Internal SSH port (typically 22)
-- External port is automatically assigned
-
-**HTTP Service - Index 1:**
-```bash
---data-urlencode 'services[1][type]=http' \
---data-urlencode 'services[1][internalPort]=3000' \
---data-urlencode 'services[1][externalHostname]=my-app' \
---data-urlencode 'services[1][externalDomainId]=1'
-```
-- `type` - Must be `http`
-- `internalPort` - Port your app listens on (80, 3000, 8080, etc.)
-- `externalHostname` - Subdomain for your service
-- `externalDomainId` - ID of the external domain to use
-
-**Additional TCP/UDP Services - Index 2, 3, etc.:**
-```bash
---data-urlencode 'services[2][type]=tcp' \
---data-urlencode 'services[2][internalPort]=5432'
-```
-- `type` - Either `tcp` or `udp`
-- `internalPort` - Internal port number
-- External port is automatically assigned in range 2000-65565
-
-**DNS (SRV) Services:**
-```bash
---data-urlencode 'services[3][type]=srv' \
---data-urlencode 'services[3][internalPort]=389' \
---data-urlencode 'services[3][dnsName]=_ldap._tcp'
-```
-- `type` - Must be `srv`
-- `internalPort` - Service port
-- `dnsName` - SRV record name (e.g., `_ldap._tcp`)
+| Type | Required Fields | Notes |
+|------|----------------|-------|
+| `tcp` | `internalPort` | External port auto-assigned |
+| `udp` | `internalPort` | External port auto-assigned (range 2000–65565) |
+| `http` | `internalPort`, `externalHostname`, `externalDomainId` | Subdomain + domain |
+| `srv` | `internalPort`, `dnsName` | e.g., `_ldap._tcp` |
 
 ## 4. Complete Example
 
-Here's a complete example creating a container with SSH, HTTP, and a custom TCP service:
-
 ```bash
-# Set your API key
 API_KEY="your_api_key_here"
 
-# Create container with multiple services
 curl -X POST 'https://create-a-container.opensource.mieweb.org/sites/1/containers' \
   -H "Authorization: Bearer $API_KEY" \
   -H 'Content-Type: application/x-www-form-urlencoded' \
@@ -144,83 +79,26 @@ curl -X POST 'https://create-a-container.opensource.mieweb.org/sites/1/container
   --data-urlencode 'services[2][internalPort]=5432'
 ```
 
-**Response:**
-- On success: Redirects to the containers list page (302)
-- On failure: Returns error message with details
-
-## 5. Understanding Container Creation
-
-The API performs these steps automatically:
-
-1. **Clone Template** - Clones the specified LXC template
-2. **Configure Resources** - Sets CPU (4 cores), memory (4GB), networking
-3. **Start Container** - Boots the container and waits for it to start
-4. **DNS Registration** - Waits for DHCP lease and DNS propagation
-5. **Service Registration** - Creates service records and configures reverse proxy
-6. **Network Configuration** - Sets up port forwarding and firewall rules
-
-This process typically takes 2-5 minutes. The container will be accessible once DNS propagates and services are configured.
-
-## 6. Listing Your Containers
+Returns 302 redirect on success, error message on failure.
 
-To view your containers:
+## 5. List Your Containers
 
 ```bash
 curl -X GET 'https://create-a-container.opensource.mieweb.org/api/containers' \
   -H "Authorization: Bearer YOUR_API_KEY"
 ```
 
-This returns a JSON array of all your containers with their details, including hostnames, IP addresses, and port assignments.
-
-## 7. Accessing Your Container
-
-Once created, you can access your container via SSH:
-
-```bash
-ssh -p <assigned-ssh-port> <username>@<hostname>.<internal-domain>
-```
-
-The SSH port is automatically assigned and displayed in the containers list. HTTP services are accessible via:
+## 6. Access Your Container
 
-```
-https://<externalHostname>.<externalDomain>
-```
+**SSH:** `ssh -p <assigned-port> <username>@<hostname>.<domain>`
 
-## 8. Viewing on Proxmox
+**HTTP:** `https://<externalHostname>.<externalDomain>`
 
-To see your container in the Proxmox GUI, navigate to <ProxmoxUrl><ProxmoxUrl /></ProxmoxUrl>. Your container will be listed with your username in the tags field.
+**Proxmox:** Navigate to <ProxmoxUrl><ProxmoxUrl /></ProxmoxUrl> — your container is listed with your username in the tags field.
 
 ![Hostname](img/proxmox-lxc.jpg)
 
-:::note Note
-You can start, stop, and reboot your container through the Proxmox interface. To delete a container, contact a cluster administrator.
+:::note
+You can start, stop, and reboot through Proxmox. To delete, contact an administrator.
 :::
 
-## Troubleshooting
-
-**Invalid or missing API key:**
-- Verify you're including the `Authorization` header with the correct format
-- Ensure your API key hasn't been deleted
-- Check that you copied the entire key
-
-**Unauthorized error:**
-- Verify your account has the necessary permissions
-- Ensure your account status is active
-
-**Template Not Found:**
-- Verify the template exists on the specified node
-- Check that your site ID is correct
-- Ensure the node has templates configured
-
-**Hostname Already Exists:**
-- Choose a different hostname
-- Check the containers list for existing containers
-
-**Service Configuration Errors:**
-- HTTP services require both externalHostname and externalDomainId
-- DNS services require a dnsName
-- Port numbers must be valid integers
-
----
-
-**Need Help?**: For questions about API usage or automation, contact the MIE team.
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/distro.jpg b/mie-opensource-landing/docs/users/creating-containers/img/distro.jpg
deleted file mode 100644
index f7014875..00000000
Binary files a/mie-opensource-landing/docs/users/creating-containers/img/distro.jpg and /dev/null differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/entrypoint-section.png b/mie-opensource-landing/docs/users/creating-containers/img/entrypoint-section.png
new file mode 100644
index 00000000..3055f2e4
Binary files /dev/null and b/mie-opensource-landing/docs/users/creating-containers/img/entrypoint-section.png differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/env-vars-section.png b/mie-opensource-landing/docs/users/creating-containers/img/env-vars-section.png
new file mode 100644
index 00000000..9fbcf040
Binary files /dev/null and b/mie-opensource-landing/docs/users/creating-containers/img/env-vars-section.png differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/hostname.jpg b/mie-opensource-landing/docs/users/creating-containers/img/hostname.jpg
deleted file mode 100644
index ebd31a81..00000000
Binary files a/mie-opensource-landing/docs/users/creating-containers/img/hostname.jpg and /dev/null differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/login-page.png b/mie-opensource-landing/docs/users/creating-containers/img/login-page.png
new file mode 100644
index 00000000..c3a4e166
Binary files /dev/null and b/mie-opensource-landing/docs/users/creating-containers/img/login-page.png differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/login.jpg b/mie-opensource-landing/docs/users/creating-containers/img/login.jpg
deleted file mode 100644
index 795cd3e2..00000000
Binary files a/mie-opensource-landing/docs/users/creating-containers/img/login.jpg and /dev/null differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/new-container-form.png b/mie-opensource-landing/docs/users/creating-containers/img/new-container-form.png
new file mode 100644
index 00000000..6cefb04a
Binary files /dev/null and b/mie-opensource-landing/docs/users/creating-containers/img/new-container-form.png differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/port.jpg b/mie-opensource-landing/docs/users/creating-containers/img/port.jpg
deleted file mode 100644
index 51cfc520..00000000
Binary files a/mie-opensource-landing/docs/users/creating-containers/img/port.jpg and /dev/null differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/services-section.png b/mie-opensource-landing/docs/users/creating-containers/img/services-section.png
new file mode 100644
index 00000000..52c006e2
Binary files /dev/null and b/mie-opensource-landing/docs/users/creating-containers/img/services-section.png differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/sites-list.png b/mie-opensource-landing/docs/users/creating-containers/img/sites-list.png
new file mode 100644
index 00000000..b68a52e5
Binary files /dev/null and b/mie-opensource-landing/docs/users/creating-containers/img/sites-list.png differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/ssh.jpg b/mie-opensource-landing/docs/users/creating-containers/img/ssh.jpg
deleted file mode 100644
index 0565933f..00000000
Binary files a/mie-opensource-landing/docs/users/creating-containers/img/ssh.jpg and /dev/null differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/img/template-dropdown.png b/mie-opensource-landing/docs/users/creating-containers/img/template-dropdown.png
new file mode 100644
index 00000000..e5291145
Binary files /dev/null and b/mie-opensource-landing/docs/users/creating-containers/img/template-dropdown.png differ
diff --git a/mie-opensource-landing/docs/users/creating-containers/using-environment-variables.mdx b/mie-opensource-landing/docs/users/creating-containers/using-environment-variables.mdx
new file mode 100644
index 00000000..04fecbde
--- /dev/null
+++ b/mie-opensource-landing/docs/users/creating-containers/using-environment-variables.mdx
@@ -0,0 +1,107 @@
+---
+sidebar_position: 3
+---
+
+# Building Custom Templates
+
+Create custom Docker images based on the standard images (Debian 13 or NodeJS 24) that use environment variables set at container creation time.
+
+## How It Works
+
+The standard images run **systemd as PID 1** (system containers). This means is you need a [systemd service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) to run your application. A custom oneshot service is present in the provided base images that writes container environment variables to `/etc/environment` and your service will need to explicitly read variables from that file. Below is a complete example on how to use this.
+
+## Example: Python Flask App
+
+**Directory structure:**
+```
+my-flask-app/
+├── Dockerfile
+├── app.py
+└── myapp.service
+```
+
+**app.py:**
+```python
+#!/usr/bin/env python3
+import os
+from flask import Flask
+
+app = Flask(__name__)
+PORT = int(os.getenv('PORT', '8080'))
+DATABASE_URL = os.getenv('DATABASE_URL', 'sqlite:///default.db')
+
+@app.route('/')
+def hello():
+    return f"<h1>Hello from Flask!</h1><p>Port: {PORT}</p>"
+
+if __name__ == '__main__':
+    app.run(host='0.0.0.0', port=PORT)
+```
+
+**myapp.service:**
+```ini
+[Unit]
+Description=My Flask Application
+After=network.target
+
+[Service]
+Type=simple
+User=www-data
+WorkingDirectory=/opt/myapp
+EnvironmentFile=/etc/environment
+ExecStart=/usr/bin/python3 /opt/myapp/app.py
+Restart=always
+
+[Install]
+WantedBy=multi-user.target
+```
+
+**Dockerfile:**
+```dockerfile
+FROM ghcr.io/mieweb/opensource-server/base:latest
+
+RUN apt-get update && \
+    apt-get install -y python3 python3-pip python3-flask && \
+    apt-get clean && rm -rf /var/lib/apt/lists/*
+
+RUN mkdir -p /opt/myapp && chown www-data:www-data /opt/myapp
+COPY app.py /opt/myapp/app.py
+RUN chmod +x /opt/myapp/app.py
+
+COPY myapp.service /etc/systemd/system/myapp.service
+RUN systemctl enable myapp.service
+
+EXPOSE 8080
+LABEL org.mieweb.opensource-server.services.http.default-port="8080"
+```
+
+Build, push, then in the web UI select "Custom Docker Image" and enter your registry path. Add environment variables (`PORT`, `DATABASE_URL`, etc.) — they'll be written to `/etc/environment` and loaded by your service.
+
+The same pattern applies to **Node.js** (use `ghcr.io/mieweb/opensource-server/nodejs:latest` base, `ExecStart=/usr/bin/node`) and **Go** (copy a static binary, use `ghcr.io/mieweb/opensource-server/base:latest`). The key elements are always:
+
+1. `EnvironmentFile=/etc/environment` in your `.service` file
+2. `systemctl enable` in your Dockerfile
+
+:::note
+Adding the label `org.mieweb.opensource-server.services.http.default-port` with a number between 1 and 65535 will automattically create an HTTP service on new containers with the value as the internal port number and an external hostname matching the container name. See ghcr.io/mieweb/opensource-server/nodejs:latest for an example.
+:::
+
+## Testing
+
+```bash
+# Local
+docker run -it -e PORT=8080 -e API_KEY=test ghcr.io/myorg/my-app:latest
+docker exec <id> systemctl status myapp.service
+docker exec <id> journalctl -u myapp.service -f
+
+# In production (SSH into container)
+cat /etc/environment
+systemctl status myapp.service
+journalctl -u myapp.service -n 100
+```
+
+## Updating Variables
+
+**Temporary:** SSH in, edit `/etc/environment`, run `systemctl restart myapp.service`. Lost on recreate.
+
+**Permanent:** Edit container in the web UI and save — container is recreated with new variables.
diff --git a/mie-opensource-landing/docs/users/creating-containers/web-gui.mdx b/mie-opensource-landing/docs/users/creating-containers/web-gui.mdx
index 9aa733e1..e16fc9cd 100644
--- a/mie-opensource-landing/docs/users/creating-containers/web-gui.mdx
+++ b/mie-opensource-landing/docs/users/creating-containers/web-gui.mdx
@@ -5,194 +5,76 @@ sidebar_position: 1
 import { ProxmoxUrl, ContainerCreationUrl } from '@site/src/components/InstanceUrl';
 
 # Using the Web GUI
-:::note Note
-This walkthrough assumes that you already have a registered proxmox account in the cluster. If not, see [Introduction](/docs/intro).
-:::
-
-This guide shows you how to set up a basic LXC container on the MIE Opensource Proxmox Cluster using the a Web GUI. The Web GUI can be accessed at <ContainerCreationUrl><ContainerCreationUrl /></ContainerCreationUrl>.
-
-## 1. Authenticate Your Proxmox Account
- 
-Upon navigating, you will be prompted for your Proxmox Login Credentials, as shown in the image below:
 
-![Login Page](img/login.jpg)
+Create and manage LXC containers through the web interface.
 
-**Options:**
-- Enter your valid Proxmox username and password
-- If authentication fails, you'll see a "Invalid username or password" message and be prompted again.
+**Prerequisites:** A registered account and at least one configured site. See [Getting Started](/docs/users/getting-started) for account setup.
 
-## 2. Choose a Container Hostname
+## Logging In
 
-This will be your container's subdomain:
+Navigate to the web interface and enter your credentials.
 
-![Hostname](img/hostname.jpg)
+![Login Page](img/login-page.png)
 
-**Options:**
-- Use a single word containing only letters, numbers, and hyphens (e.g., `myapp`, `test-api`)
-- The hostname will be available at `your-hostname.opensource.mieweb.org`
-- If the name is already taken or contains invalid characters, you'll be asked to choose another
+## Selecting a Site
 
-## 3. Select a Linux Distribution
+Select a site before creating containers — the site determines the Proxmox cluster and network. Click **Containers** to view containers for a site.
 
-This dropdown presents available distributions:
+![Sites List](img/sites-list.png)
 
-![Hostname](img/distro.jpg)
+## Creating a Container
 
-**Options:**
-- Type `debian` for Debian 12 (Bookworm)
-- Type `rocky` for Rocky Linux 9
-- Any invalid input defaults to Debian
+![Entrypoint Section](img/entrypoint-section.png)
 
-## 4. Set the HTTP Port
+Click **New Container** from the containers list.
 
-Specify which port your application will listen on:
+### Hostname
 
-![Hostname](img/port.jpg)
+Unique name (lowercase letters, numbers, hyphens). Containers within the same site can reach each other at `<hostname>.<internal domain>`.
 
-**Options:**
-- Any number between 80 and 60,000
-- Common choices: 80, 3000, 8080, 5000, 8000
-- Invalid entries will prompt you to try again
+### Template
 
-## 5. Configure SSH Access
+Select a standard image or choose "Custom Docker Image..." for any registry image. Temlates auto-populate services, environment variables, and entrypoint.
 
-Enter a public key from your local machine:
+- **Debian 13**: `ghcr.io/mieweb/opensource-server/base:latest`
+- **NodeJS 24**: `ghcr.io/mieweb/opensource-server/nodejs:latest`
+- **Custom**: Full registry path (e.g., `docker.io/library/nginx:latest`)
 
-![Hostname](img/ssh.jpg)
+### Services (Optional)
 
-**Options:**
-- Enter your SSH public key (starts with `ssh-rsa`, `ssh-ed25519`, etc.)
-- Leave blank to skip SSH key configuration
-- Invalid keys will prompt for a valid key or blank entry
+Expose container ports. Click **Add Service**, select type (HTTP/TCP/UDP), enter internal port. HTTP services also allow selecting an external domain name, defaulting to the hostname of the container. TCP and UDP services will be autoassigned an external port.
 
-:::important Important
-Entering a public key is highly recommended. It will allow you to access the create-container command line setup without entering a password. Additionally, it will allow you to SSH to your container without having to input your proxmox password, making the connection process faster and more secure.
-
-To create a private/public key pair on your machine, reference [this guide](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key).
+:::note
+You'll need to add a TCP service with internal port 22 in order to expose the SSH connection to your container.
 :::
 
-## 6. Container Creation Process
-
-After providing all required information, the system will:
-1. Transfer your configuration to the hypervisor
-2. Begin the container creation process
-3. Set up networking, DNS, and reverse proxy
-4. Configure the container with your specified settings
-5. Deploy your application if requested
-
-Once the container creation process is complete, your container will be accessible via an ssh command in the form of:
-
-```
-ssh -p <your-container-port> <proxmox-username>@opensource.mieweb.org
-```
-
-## 7. Understanding the Output
-
-Once your container is created, you will receieve an output that looks somthing like this:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🔔  COPY THESE PORTS DOWN — For External Access
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📌  Note: Your container listens on SSH Port 22 internally,
-    but EXTERNAL traffic must use the SSH port listed below:
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-✅  Hostname Registration: max-demo-container → 10.15.19.181
-🔐  SSH Port               : 2376
-🌐  HTTP Port              : 3000
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📦  Container ID        : 116
-🌐  Internal IP         : 10.15.19.181
-🔗  Domain Name         : https://max-demo-container.opensource.mieweb.org
-🛠️  SSH Access          : ssh -p 2376 demouser@max-demo-container.opensource.mieweb.org
-🔑  Container Password  : Your proxmox account password
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-NOTE: Additional background scripts are being ran in detached terminal sessions.
-Wait up to two minutes for all processes to complete.
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Still not working? Contact Max K. at maxklema@gmail.com
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-:::important Important
-Your container password is the same as your Proxmox Account Password.
-:::
-
-The first block will list all of the ports that your container uses. By default, it will display an SSH Port and an HTTP Port. If you added any other special protocols, they will appear there as well.
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-✅  Hostname Registration: max-demo-container → 10.15.19.181
-🔐  SSH Port               : 2376
-🌐  HTTP Port              : 3000
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-The second block contains network information about your container specifically, including its IP address, public domain name, and ssh command:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-📦  Container ID        : 116
-🌐  Internal IP         : 10.15.19.181
-🔗  Domain Name         : https://max-demo-container.opensource.mieweb.org
-🛠️  SSH Access          : ssh -p 2376 demouser@max-demo-container.opensource.mieweb.org
-🔑  Container Password  : Your proxmox account password
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-:::note Note
-The IP that is given is an **internal IP** allocated by our local DHCP server. It is not public. Additionally, since we are setting up a basic container, nothing will be deployed yet, so navigating to the domain will return a 502 bad gateway error from our nginx server. This is expected.
-:::
-
-:::warning Warning
-Save your SSH port number, as well as any port numbers, because you will not be able to see them again. This will be fixed at a later time.
-:::
+### Environment Variables (Optional)
 
-## 8. Viewing your Container on Proxmox
+Key-value pairs written to `/etc/environment` in system containers. See [Building Custom Images](./using-environment-variables.mdx) for details on systemd integration.
 
-To see your container on the Proxmox GUI, navigate to <ProxmoxUrl><ProxmoxUrl /></ProxmoxUrl>. Once signed in, on the summary view, you should see the name of your container. If you double click on it, you will be able to access details, like the shell, metrics, and other network/filesystem information.
+### Entrypoint Command (Optional)
 
-![Hostname](img/proxmox-lxc.jpg)
+Default: `/sbin/init` for system containers.
 
-:::note Note
-As of writing, you are able to reboot, start, and shutdown your container as you please. However, you must reach out to a cluster admin to delete your container.
+:::warning
+Changing the entrypoint for provided templates or derived images is not supported. This should only be used to add arguments to standard Docker images.
 :::
 
----
-
-## Docker Container Configuration
+### Submit
 
-When creating containers from Docker images, you can configure additional settings that are specific to containerized applications.
+Click **Create Container**. You'll be redirected to a page to watch the creation job progress. After the creation finishes successfully, please allow up to 1 minute to allow the load balancer to reconfigure before your services are accessible.
 
-### Environment Variables
+## Accessing Your Container
 
-Environment variables allow you to pass configuration to your containerized application at runtime. These are commonly used for:
-- Database connection strings
-- API keys and secrets
-- Feature flags
-- Application modes (development, production, etc.)
+**SSH:** `ssh -p <SSH-PORT> <username>@<hostname>.<domain>`
 
-To add environment variables, expand the **Environment Variables** section and click **Add Variable** to create key-value pairs.
+**HTTP:** `https://<hostname>.<domain>`
 
-:::warning System Containers
-Environment variables are intended for **Docker-based containers** only. System containers (created from Proxmox templates like Debian or Rocky Linux) typically expect `init` as PID 1 and may not use environment variables in the same way. If you're using a standard Linux template, you generally don't need to set environment variables here.
-:::
+**Proxmox Console:** <ProxmoxUrl><ProxmoxUrl /></ProxmoxUrl>
 
-### Entrypoint Command
+## Managing Containers
 
-The entrypoint command overrides the default startup command for a Docker container. This is useful when you need to:
-- Run a specific script or binary
-- Pass custom arguments to your application
-- Chain multiple startup commands
-
-:::warning System Containers
-The entrypoint command is intended for **Docker-based containers** only. System containers expect `init` as PID 1 and should not have their entrypoint overridden. Changing the entrypoint on a system container may prevent it from starting correctly.
-:::
-
-### Restarting After Configuration Changes
-
-When you modify environment variables or the entrypoint command on an existing container, the system will automatically restart the container to apply the changes. You can monitor the restart progress from the container list page.
-
----
+- **Start/Stop/Restart/Force Stop** via the Actions column
+- **Edit** to modify environment variables, entrypoint, or services (restart required)
+- **Delete** to permanently remove (irreversible — back up data first)
 
-**Need Help?**: For questions about container configuration or troubleshooting, contact the MIE team.
diff --git a/mie-opensource-landing/docs/users/getting-started.mdx b/mie-opensource-landing/docs/users/getting-started.mdx
new file mode 100644
index 00000000..9b11a5f2
--- /dev/null
+++ b/mie-opensource-landing/docs/users/getting-started.mdx
@@ -0,0 +1,17 @@
+---
+sidebar_position: 0
+---
+
+import { ContainerCreationUrl } from '@site/src/components/InstanceUrl';
+
+# Getting Started
+
+To use the cluster, you need an account on the web interface at <ContainerCreationUrl><ContainerCreationUrl /></ContainerCreationUrl>.
+
+## Registering with an Invite
+
+If an admin sent you an email invite, click the link in the email. Your email will be pre-filled and locked. Fill in your name, username, and password, then submit. Your account is active immediately—you can log in right away.
+
+## Registering without an Invite
+
+Click **Register** on the login page and fill in all fields (first name, last name, username, email, password). Your account will be created with **pending** status. An admin must approve it before you can log in. You'll receive an email once approved.
diff --git a/mie-opensource-landing/docs/users/monitoring-container.mdx b/mie-opensource-landing/docs/users/monitoring-container.mdx
index 160f4a62..03c91690 100644
--- a/mie-opensource-landing/docs/users/monitoring-container.mdx
+++ b/mie-opensource-landing/docs/users/monitoring-container.mdx
@@ -4,42 +4,30 @@ sidebar_position: 5
 
 import { ProxmoxUrl } from '@site/src/components/InstanceUrl';
 
-# Monitoring Container in Proxmox Web GUI
+# Monitoring Containers in Proxmox
 
-Once you have created a container, whether through the Web GUI, command line, or Proxmox Launchpad, you can monitor the container's performance using the Proxmox Web GUI located at <ProxmoxUrl><ProxmoxUrl /></ProxmoxUrl>.
+Monitor container performance in the Proxmox Web GUI at <ProxmoxUrl><ProxmoxUrl /></ProxmoxUrl>.
 
-## Container Dashboard
+## Dashboard
 
-Upon logging in, you can see a dashboard with all of your active containers:
+After logging in, you'll see your active containers. Each has a tag showing the OS and your username.
 
 ![Proxmox Container Dashboard](./img/proxmox-container-dashboard.png)
 
-> In this screenshot, I have one active container called test-project with a CTID of 115.
+## Metrics
 
-Each container ID has a tag of the OS and your username.
-
-## Accessing Container Metrics
-
-Double click on the container that you want to manage.
+Double-click a container to view CPU, memory, swap, and disk usage with progress bars and time-series graphs.
 
 ![Container Metrics](./img/container-metrics.png)
 
-The container dashboard allows you to view the CPU usage, the Memory usage, the SWAP usage, and the SSD of your container. At the top, there are progress bars which show your usage compared to the amount of resource you have allocated.
-
-Proxmox also provides graphs that show your container's usage of a certain metric oer a period of time (usually an hour by default).
-
 ![Container Charts](./img/container-charts.png)
 
-:::important Important
-It is very important to monitor you container metrics at regular intervals, especially if your container is slow (ie, packages not installing quickly/hanging, etc.). If your application is constantly using 80% or more of a metric, reach out to an MIE cluster admin and we can upgrade that resource for your container.
+:::important
+If any metric stays above 80%, contact an MIE cluster admin to upgrade that resource.
 :::
 
-## Accessing Container Shell
-
-You can also access your container's shell right from Proxmox.
+## Shell Access
 
-![Proxmox Container Shell](./img/proxmox_shell.png)
+Access the container shell directly from Proxmox. Prefer using SSH from your local machine for regular work.
 
-:::note Only use Proxmox Shell when Necessary
-It is recommended to modify your container using a terminal on your local machine on a regular basis.
-:::
\ No newline at end of file
+![Proxmox Container Shell](./img/proxmox_shell.png)
\ No newline at end of file
diff --git a/mie-opensource-landing/docs/users/proxmox-launchpad/automatic-runner-provisioning.md b/mie-opensource-landing/docs/users/proxmox-launchpad/automatic-runner-provisioning.md
index 9a6a78aa..30837b84 100644
--- a/mie-opensource-landing/docs/users/proxmox-launchpad/automatic-runner-provisioning.md
+++ b/mie-opensource-landing/docs/users/proxmox-launchpad/automatic-runner-provisioning.md
@@ -4,6 +4,10 @@ sidebar_position: 3
 
 # Automatic Runner Provisioning (Path 2)
 
+:::caution Outdated Documentation
+This page predates the last major rewrite and may not be accurate. Check back weekly for updates.
+:::
+
 This guide covers **Path 2** of Proxmox Launchpad: automatic runner provisioning where our action creates and manages GitHub runners for you. Each branch gets its own dedicated runner and container with complete lifecycle management.
 
 :::warning Security Consideration
@@ -173,16 +177,13 @@ Entering a public key is highly recommended. To create a private/public key pair
 
 ## Automatic Deployment Configuration
 
-Enable automatic deployment to have your application deployed on every push:
-
-:::important Important
-If you want Proxmox Launchpad to automatically deploy your application, consider the options below and add them to your workflow file.
-**If you do not want to deploy your application automatically, you do not need to include any of the options below and can simply disregard them.**
-:::
-
-### Single-Component Applications
+Deployment configuration is identical to Path 1 — see [Automatic Deployment Configuration](/docs/users/proxmox-launchpad/supplied-runners#automatic-deployment-configuration) for full details on:
+- Single and multi-component applications
+- Deployment properties reference table
+- Services configuration
+- Custom services
 
-For applications with a single service (React app, Flask server, etc.):
+The only difference is that deployment properties go in the `manage-container` job:
 
 ```yaml
 manage-container:
@@ -195,127 +196,12 @@ manage-container:
         proxmox_password: ${{ secrets.PROXMOX_PASSWORD }}
         github_pat: ${{ secrets.GH_PAT }}
 
-        # Deployment configuration
-        project_root: ""  # Leave blank for repository root
+        # Add deployment properties here (same as Path 1)
         install_command: "npm install"
         start_command: "npm start"
         runtime_language: "nodejs"
-
-        # Optional: Build command
-        build_command: "npm run build"
-
-        # Optional: Environment variables
-        container_env_vars: '{"API_KEY": "your-api-key", "NODE_ENV": "production"}'
-
-        # Optional: Services
-        services: '["mongodb", "redis"]'
 ```
 
-### Multi-Component Applications
-
-For applications with multiple services (frontend + backend, microservices, etc.):
-
-```yaml
-manage-container:
-  runs-on: self-hosted
-  needs: setup-runner
-  steps:
-    - uses: maxklema/proxmox-launchpad@main
-      with:
-        proxmox_username: ${{ secrets.PROXMOX_USERNAME }}
-        proxmox_password: ${{ secrets.PROXMOX_PASSWORD }}
-        github_pat: ${{ secrets.GH_PAT }}
-
-        # Multi-component configuration
-        install_command: '{"/frontend": "npm install", "/backend": "pip install -r requirements.txt"}'
-        start_command: '{"/frontend": "npm start", "/backend": "flask run --host=0.0.0.0"}'
-        runtime_language: '{"/frontend": "nodejs", "/backend": "python"}'
-
-        # Optional: Build commands per component
-        build_command: '{"/frontend": "npm run build", "/backend": "python setup.py build"}'
-
-        # Optional: Environment variables per component
-        container_env_vars: '{"/frontend": {"REACT_APP_API_URL": "http://localhost:5000"}, "/backend": {"FLASK_ENV": "production"}}'
-
-        # Optional: Root directory command (e.g., Docker Compose)
-        root_start_command: "docker-compose up -d"
-```
-
-#### Multi-Component Structure
-
-Each component path is relative to your project root:
-
-```
-your-repo/
-├── frontend/          # Component path: "/frontend"
-│   ├── package.json
-│   └── src/
-├── backend/           # Component path: "/backend"
-│   ├── requirements.txt
-│   └── app.py
-└── docker-compose.yml # Root commands run here
-```
-
-### Automatic Deployment Properties
-
-| Propety | Required? | Description | Single Component | Multi-Component |
-| --------- | ----- |  ------------------------------------ | ---- | --- |
-|  `multi_component` | Conditional | A `y` flag that specifies if your application is multi-component. This only needs to be set if your application is multi-component. | N/A | A string of `y`.
-|  `container_env_vars` | No. | Key-Value Environment variable pairs. | Dictionary in the form of: `{ "api_key": "123", "password": "abc"}` | Dictionary in the form of: `'{"/frontend": { "api_key": "123"}, "/backend": { "password": "abc123" }}'`.
-|  `install_command` | Yes* | Commands to install all project dependencies | String of the installation command, i.e. `npm install`. | Dictionary in the form of: `'{"/frontend": "npm install", "/backend": "pip install -r ../requirements.txt"}'`.
-|  `build_command` | No | Commands to build project components | String of the build command, i.e. `npm build`. | Dictionary in the form of: `'{"/frontend": "npm build", "/backend": "python3 build.py"}'`.
-|  `start_command` | Yes* | Commands to start project components. | String of the start command, i.e. `npm run`. | Dictionary in the form of: `'{"/frontend": "npm run", "/backend": "flask run"}'`.
-|  `runtime_language` | Yes* | Runtime language of each project component, which can either be `nodejs` or `python`. | String of runtime environment, i.e. `nodejs` | Dictionary in the form of: `'{"/frontend": "nodejs", "/backend": "python"}'`.
-|  `root_start_command` | No | Command to run at the project directory root for **multi-component applications**. | N/A | String of the command, i.e. `Docker-compose up ...`
-
-> * (*) These options are only required if `root_start_command` is not provided, as that command may be a docker build and/or a docker compose command that builds the entire application.
-
-### Services Configuration
-
-Add pre-configured services to your container:
-
-```yaml
-# Available services
-services: '["mongodb", "postgresql", "redis", "docker", "nginx", "apache"]'
-```
-
-#### Available Services
-
-| Service | Description | Use Case |
-|---------|-------------|----------|
-| `mongodb` | MongoDB database | Document storage, NoSQL applications |
-| `postgresql` | PostgreSQL database | Relational database, SQL applications |
-| `redis` | Redis cache | Caching, session storage |
-| `docker` | Docker runtime | Containerized applications |
-| `nginx` | NGINX web server | Reverse proxy, static file serving |
-| `apache` | Apache web server | Web hosting, PHP applications |
-| `rabbitmq` | RabbitMQ message broker | Message queuing, microservices |
-| `memcached` | Memcached caching | Distributed caching |
-| `mariadb` | MariaDB database | MySQL-compatible database |
-| `meteor` | Meteor framework | Full-stack JavaScript applications |
-
-:::note Service Dependencies
-Some services like `meteor` include other services (MongoDB). You don't need to install dependencies separately.
-:::
-
-### Custom Services
-
-Install services not in the standard list:
-
-```yaml
-custom_services: |
-  [
-    ["sudo apt-get update", "sudo apt-get install -y nginx", "sudo systemctl enable nginx", "sudo systemctl start nginx"],
-    ["curl -fsSL https://get.docker.com | sh", "sudo systemctl enable docker", "sudo systemctl start docker"]
-  ]
-```
-
-Each array represents the installation commands for one custom service.
-
-:::important Important
-Make sure you enable and start your service using the systemctl service manager CLI.
-:::
-
 ## Pull Request Integration
 
 ### Automatic PR Comments
@@ -468,61 +354,7 @@ jobs:
 
 ## Important Deployment Notes
 
-### Application Binding
-
-:::warning Critical for Multi-Component Apps
-Ensure your backend services bind to `0.0.0.0` (all interfaces) instead of `127.0.0.1` (localhost only) for proper communication between components.
-:::
-
-**Examples:**
-```python
-# Flask - Correct
-app.run(host='0.0.0.0', port=5000)
-
-# Flask - Incorrect
-app.run(host='127.0.0.1', port=5000)
-```
-
-```javascript
-// Express - Correct
-app.listen(5000, '0.0.0.0');
-
-// Express - Incorrect
-app.listen(5000, 'localhost');
-```
-
-### Special Framework Notes
-
-#### Meteor Applications
-```yaml
-start_command: "meteor --allow-superuser --port 0.0.0.0:3000"
-```
-
-:::note Meteor Installation
-Meteor is a large package and may take additional time to install and deploy.
-:::
-
-#### Vite.js Applications
-
-If you are using vite.js as a frontend service, you need to add the domain name of your container in the allowHosts array in your `vite.config.js` file.
-
-```yml
-server: {
-    host: '0.0.0.0',
-    port: 32000,
-    proxy: {
-      '/api': 'http://localhost:5000',
-    },
-    allowedHosts: ['maxklema-polyglot-test-main.opensource.mieweb.org']
-  },
-```
-
-### Environment Variables
-
-Environment variables are automatically written to `.env` files in the appropriate component directories:
-
-- **Single-component**: `.env` in project root
-- **Multi-component**: `.env` in each component directory
+See [Deployment Notes in Path 1](/docs/users/proxmox-launchpad/supplied-runners#important-deployment-notes) for application binding requirements, framework-specific notes (Meteor, Vite.js), and environment variable details.
 
 ## Runner Lifecycle Management
 
@@ -588,55 +420,20 @@ Even after the GitHub Action completes, background scripts may still be running.
 
 ## Troubleshooting
 
-### Common Issues
+### Path 2-Specific Issues
 
 **Setup-runner job fails:**
 - Check that `GH_PAT` secret is set correctly
 - Verify PAT has `manage_runners:org` permission
 - Ensure PAT hasn't expired
 
-**Container not accessible:**
-- Wait 2-5 minutes for background scripts to complete
-- Check that your start commands are correct
-- Verify your application binds to `0.0.0.0` not `localhost`
-
-**Dependencies fail to install:**
-- Ensure dependency files (`package.json`, `requirements.txt`) are in the correct directories
-- Check that files are committed to your repository
-- Verify paths are relative to component directories
-
-**Services not communicating:**
-- Ensure backend services bind to `0.0.0.0`
-- Check frontend API URLs point to correct backend ports
-- Verify environment variables are set correctly
-
-**GitHub Action fails:**
-- Check repository secrets are set correctly
-- Ensure PAT has proper permissions
-- Verify all required properties are provided
-
-### Debug Container Issues
-
-SSH into your container and check:
-
+**Runner status check:**
 ```bash
-# Check running processes
-ps aux | grep node
-ps aux | grep python
-
-# Check listening ports
-ss -tlnp | grep LISTEN
-
-# Check environment variables
-cat /path/to/component/.env
-
-# Check application logs (if using tmux)
-tmux attach -t 0
-
-# Check runner status
 sudo systemctl status actions.runner.*
 ```
 
+For general container issues (not accessible, dependencies failing, services not communicating), see [Troubleshooting in Path 1](/docs/users/proxmox-launchpad/supplied-runners#troubleshooting).
+
 ## Security Considerations
 
 ### PAT Security Best Practices
diff --git a/mie-opensource-landing/docs/users/proxmox-launchpad/supplied-runners.md b/mie-opensource-landing/docs/users/proxmox-launchpad/supplied-runners.md
index 6d1511c8..1ff52c8b 100644
--- a/mie-opensource-landing/docs/users/proxmox-launchpad/supplied-runners.md
+++ b/mie-opensource-landing/docs/users/proxmox-launchpad/supplied-runners.md
@@ -4,6 +4,10 @@ sidebar_position: 2
 
 # Using a Supplied Runner (Path 1)
 
+:::caution Outdated Documentation
+This page predates the last major rewrite and may not be accurate. Check back weekly for updates.
+:::
+
 This guide covers **Path 1** of Proxmox Launchpad: using your own GitHub self-hosted runners or external runners to manage containers. This is the **recommended approach** for most users.
 
 :::tip Why Path 1 is Recommended
@@ -179,62 +183,40 @@ For applications with multiple services (frontend + backend, microservices, etc.
     root_start_command: "docker-compose up -d"
 ```
 
-#### Multi-Component Structure
-
-Each component path is relative to your project root:
-
-```
-your-repo/
-├── frontend/          # Component path: "frontend/"
-│   ├── package.json
-│   └── src/
-├── backend/           # Component path: "backend/"
-│   ├── requirements.txt
-│   └── app.py
-└── docker-compose.yml # Root commands run here
-```
-
 ### Automatic Deployment Properties
 
-| Propety | Required? | Description | Single Component | Multi-Component |
+| Property | Required? | Description | Single Component | Multi-Component |
 | --------- | ----- |  ------------------------------------ | ---- | --- |
-|  `multi_component` | Conditional | A `y` flag that specifies if your application is multi-component. This only needs to be set if your application is multi-component. | N/A | A string of `y`.
-|  `container_env_vars` | No. | Key-Value Environment variable pairs. | Dictionary in the form of: `{ "api_key": "123", "password": "abc"}` | Dictionary in the form of: `'{"/frontend": { "api_key": "123"}, "/backend": { "password": "abc123" }}'`.
-|  `install_command` | Yes* | Commands to install all project dependencies | String of the installation command, i.e. `npm install`. | Dictionary in the form of: `'{"/frontend": "npm install", "/backend": "pip install -r ../requirements.txt"}'`.
-|  `build_command` | No | Commands to build project components | String of the build command, i.e. `npm build`. | Dictionary in the form of: `'{"/frontend": "npm build", "/backend": "python3 build.py"}'`.
-|  `start_command` | Yes* | Commands to start project components. | String of the start command, i.e. `npm run`. | Dictionary in the form of: `'{"/frontend": "npm run", "/backend": "flask run"}'`.
-|  `runtime_language` | Yes* | Runtime language of each project component, which can either be `nodejs` or `python`. | String of runtime environment, i.e. `nodejs` | Dictionary in the form of: `'{"/frontend": "nodejs", "/backend": "python"}'`.
-|  `root_start_command` | No | Command to run at the project directory root for **multi-component applications**. | N/A | String of the command, i.e. `Docker-compose up ...`
+|  `multi_component` | Conditional | Set to `y` for multi-component apps. | N/A | `y` |
+|  `container_env_vars` | No | Key-Value environment variable pairs. | `{ "api_key": "123", "password": "abc"}` | `'{"/frontend": { "api_key": "123"}, "/backend": { "password": "abc123" }}'` |
+|  `install_command` | Yes* | Dependency install commands. | `npm install` | `'{"/frontend": "npm install", "/backend": "pip install -r ../requirements.txt"}'` |
+|  `build_command` | No | Build commands. | `npm build` | `'{"/frontend": "npm build", "/backend": "python3 build.py"}'` |
+|  `start_command` | Yes* | Start commands. | `npm run` | `'{"/frontend": "npm run", "/backend": "flask run"}'` |
+|  `runtime_language` | Yes* | Runtime: `nodejs` or `python`. | `nodejs` | `'{"/frontend": "nodejs", "/backend": "python"}'` |
+|  `root_start_command` | No | Root directory command for multi-component apps. | N/A | `Docker-compose up ...` |
 
-> * (*) These options are only required if `root_start_command` is not provided, as that command may be a docker build and/or a docker compose command that builds the entire application.
+> \* Only required if `root_start_command` is not provided.
 
 ### Services Configuration
 
 Add pre-configured services to your container:
 
 ```yaml
-# Available services
 services: '["mongodb", "postgresql", "redis", "docker", "nginx", "apache"]'
 ```
 
-#### Available Services
-
-| Service | Description | Use Case |
-|---------|-------------|----------|
-| `mongodb` | MongoDB database | Document storage, NoSQL applications |
-| `postgresql` | PostgreSQL database | Relational database, SQL applications |
-| `redis` | Redis cache | Caching, session storage |
-| `docker` | Docker runtime | Containerized applications |
-| `nginx` | NGINX web server | Reverse proxy, static file serving |
-| `apache` | Apache web server | Web hosting, PHP applications |
-| `rabbitmq` | RabbitMQ message broker | Message queuing, microservices |
-| `memcached` | Memcached caching | Distributed caching |
-| `mariadb` | MariaDB database | MySQL-compatible database |
-| `meteor` | Meteor framework | Full-stack JavaScript applications |
-
-:::note Service Dependencies
-Some services like `meteor` include other services (MongoDB). You don't need to install dependencies separately.
-:::
+| Service | Description |
+|---------|-------------|
+| `mongodb` | MongoDB database |
+| `postgresql` | PostgreSQL database |
+| `redis` | Redis cache |
+| `docker` | Docker runtime |
+| `nginx` | NGINX web server |
+| `apache` | Apache web server |
+| `rabbitmq` | RabbitMQ message broker |
+| `memcached` | Memcached caching |
+| `mariadb` | MariaDB database |
+| `meteor` | Meteor framework (includes MongoDB) |
 
 ### Custom Services
 
@@ -248,11 +230,7 @@ custom_services: |
   ]
 ```
 
-Each array represents the installation commands for one custom service.
-
-:::important Important
-Make sure you enable and start your service using the systemctl service manager CLI.
-:::
+Each array represents the installation commands for one custom service. Make sure you enable and start your service using `systemctl`.
 
 ## Complete Workflow Examples
 
diff --git a/mie-opensource-landing/docs/users/proxmox-launchpad/what-is-proxmox-launchpad.md b/mie-opensource-landing/docs/users/proxmox-launchpad/what-is-proxmox-launchpad.md
index 02756042..2f02e95e 100644
--- a/mie-opensource-landing/docs/users/proxmox-launchpad/what-is-proxmox-launchpad.md
+++ b/mie-opensource-landing/docs/users/proxmox-launchpad/what-is-proxmox-launchpad.md
@@ -4,6 +4,10 @@ sidebar_position: 1
 
 # What is Proxmox Launchpad?
 
+:::caution Outdated Documentation
+This section predates the last major rewrite and may not be accurate. Check back weekly for updates.
+:::
+
 Proxmox Launchpad is a powerful GitHub Action that automatically provisions and manages LXC containers on MIE's open source Proxmox cluster. It streamlines the development workflow by creating dedicated containers for each branch of your repository and keeping them synchronized with your code changes.
 
 ![Proxmox Launchpad Marketplace Image](./img/proxmox-launchpad-page.png)
diff --git a/mie-opensource-landing/docs/users/vscode-setup.md b/mie-opensource-landing/docs/users/vscode-setup.md
index d4c6cc9e..eeef49a4 100644
--- a/mie-opensource-landing/docs/users/vscode-setup.md
+++ b/mie-opensource-landing/docs/users/vscode-setup.md
@@ -2,241 +2,55 @@
 sidebar_position: 5
 ---
 
-# Accessing your Container from VSCode
+# VSCode Remote SSH Setup
 
-When managing an entire repository, many developers prefer to work in an IDE, such as VSCode, rather than a terminal/shell. This guide walks you through setting up VSCode Remote SSH to connect directly to your Proxmox container for seamless development.
+Connect VSCode directly to your Proxmox container for remote development.
 
-## Prerequisites
+**Prerequisites:** VSCode installed, a running container with SSH access.
 
-Before getting started, ensure you have:
+## 1. Install Remote SSH Extension
 
-- **VSCode installed** on your local machine
-- **Container created** with Proxmox Launchpad (either [Path 1](/docs/users/proxmox-launchpad/supplied-runners) or [Path 2](/docs/users/proxmox-launchpad/automatic-runner-provisioning))
-- **Container access details** from your deployment output (SSH port, hostname, etc.)
-
-## 1: Install Remote SSH Extension
-
-### Install the Extension
-
-1. **Open VSCode** on your local machine
-2. **Access Extensions**: Click the Extensions icon in the sidebar (or press `Ctrl+Shift+X`)
-3. **Search for Remote SSH**: Type "Remote - SSH" in the search box
-4. **Install**: Click "Install" on the "Remote - SSH" extension by Microsoft
+In VSCode, open Extensions (`Ctrl+Shift+X`), search "Remote - SSH" by Microsoft, and install it.
 
 ![alt text](./img/image.png)
 
-:::note Extension Details
-The full extension name is **"Remote - SSH"** published by **Microsoft**. This is the official extension for SSH connections.
-:::
-
-## 2: Configure SSH Connection
+## 2. Configure SSH
 
-### Access SSH Configuration
-
-1. **Open Command Palette**: Press `Ctrl+Shift+P` (Windows/Linux) or `Cmd+Shift+P` (Mac)
-2. **Search for SSH Config**: Type "Remote-SSH: Open SSH Configuration File"
-3. **Select Configuration File**: Choose your SSH config file (usually the first option)
-
-:::tip SSH Config Location
-- **Windows**: `C:\Users\{username}\.ssh\config`
-- **macOS/Linux**: `~/.ssh/config`
-
-If the file doesn't exist, VSCode will create it for you.
-:::
-
-### Add Your Container Host
-
-Add the following configuration to your SSH config file, replacing the values with your container details:
+Open Command Palette (`Ctrl+Shift+P`) → "Remote-SSH: Open SSH Configuration File". Add:
 
 ```ssh-config
 Host my-container
-    HostName opensource.mieweb.org
+    HostName <external-domain-name>
     User <your-proxmox-username>
-    Port <your-proxmox-port>
+    Port <your-ssh-port>
 ```
 
-#### Configuration Details
-
-| Field | Description | Example |
-|-------|-------------|---------|
-| `Host` | Name for your container connection | `my-container`, `my-app-dev` |
-| `HostName` | Server address (always use `opensource.mieweb.org`) | `opensource.mieweb.org` |
-| `User` | Your Proxmox username | `john.doe`, `jane.smith` |
-| `Port` | SSH port from your container output | `2344`, `2387` |
-
-### Example Configuration
+| Field | Description |
+|-------|-------------|
+| `Host` | Display name for this connection |
+| `HostName` | The same domain name used to access the web UI |
+| `User` | Your Proxmox username |
+| `Port` | SSH port from container output |
 
-Based on typical container output, your config might look like:
+For multiple containers, add separate `Host` entries with different names and ports.
 
-```ssh-config
-Host my-fullstack-app
-    HostName opensource.mieweb.org
-    User demouser
-    Port 2348
-```
-
-:::important Important
-- Replace `your-proxmox-username` with your actual Proxmox account username
-- Replace `2344` with the SSH port from your container deployment output
-- Choose a descriptive `Host` name that helps you identify the container
-:::
+## 3. Connect
 
-## 3: Connect to Your Container
-
-### Establish SSH Connection
-
-1. **Open Command Palette**: Press `Ctrl+Shift+P` (Windows/Linux) or `Cmd+Shift+P` (Mac)
-2. **Connect to Host**: Type "Remote-SSH: Connect to Host..."
-3. **Select Your Host**: Choose the host you just configured (e.g., `my-container`)
-4. **Select Platform**: Choose "Linux" when prompted for the platform
-
-### Accept Host Key
-
-When connecting for the first time:
-
-1. **Host Key Warning**: You'll see a security warning about the host's authenticity
-2. **Accept Key**: Click "Continue" or type "yes" to accept the host key
-3. **Trust Permanently**: This adds the host to your known hosts file
+Command Palette → "Remote-SSH: Connect to Host..." → select your host → choose "Linux" → accept the host key on first connection.
 
 ![authentication token](./img/fingerprint.jpg)
 
-:::note Security Note
-This warning appears only on the first connection. The host key fingerprint is stored to verify future connections.
-:::
-
-### Authentication
-
-Depending on your container setup:
+**Authentication:** If you provided a public key during container setup, connection is automatic. Otherwise, enter your Proxmox password when prompted.
 
-#### If You Provided a Public Key
-- **Automatic Login**: VSCode should connect automatically using your SSH key
-- **No Password Required**: The connection will be seamless
+## 4. Open Project
 
-#### If You Did NOT Provide a Public Key
-1. **Password Prompt**: Enter your Proxmox account password when prompted
-2. **Connection Established**: VSCode will connect to your container
+Once connected: **Open Folder** (`Ctrl+K Ctrl+O`) → navigate to your project directory (typically `/root/` or `/home/<username>/`).
 
-:::tip Password Management
-If you're frequently entering passwords, consider setting up SSH key authentication for a better experience. You can add your public key to the container later by appending it to the `~/.ssh/authorized_keys` file. If you do not have
+:::tip
+If you can't access `/root`, run `sudo su` in the VSCode terminal using your Proxmox password.
 :::
 
-## 4: Open Your Project Folder
-
-### Navigate to Your Project
-
-1. **Open Folder**: Once connected, click "Open Folder" or press `Ctrl+K Ctrl+O`
-2. **Navigate to Home**: Go to `/root/`
-3. **Select Project**: Choose your project directory (usually matches your repository name)
-4. **Confirm**: Click "OK" to open the folder
-
-:::tip Tip
-If you can't access `/root`, run `sudo su` in your VSCode terminal. It may prompt you for your password. This will be your proxmox password.
-:::
-
-:::note Note
-If you did not choose to automtically deploy your application during container setup, the `/root` directory is likely empty. In that case, it is recommended to create all project files inside your `/home/proxmox-username/` directory.
-:::
-
-### Example Directory Structure
-
-Your container typically contains:
+## 5. Develop
 
-```
-/root
-├── your-repository-name/     # Your project files
-│   ├── src/
-│   ├── package.json
-│   └── README.md
-├── .bashrc
-└── other-files
-```
-
-:::note Project Location
-If you used automatic deployment, your repository is cloned to `/home/your-proxmox-username/repository-name/`.
-:::
-
-## 5: Working in VSCode
-
-### Integrated Terminal
-
-1. **Open Terminal**: Press `Ctrl+`` (backtick) or go to Terminal > New Terminal
-2. **Container Terminal**: You now have a terminal running inside your container
-3. **Full Access**: Run commands, install packages, start services directly
-
-### Using Sudo
-
-When you need administrator privileges:
-
-```bash
-sudo command-here
-```
-
-**Password**: Use your **Proxmox account password** (same as your SSH password)
-
-:::important Sudo Password
-The sudo password is always your Proxmox account password, not a separate root password.
-:::
-
-### Development Workflow
-
-You can now:
-
-- **Edit Files**: Directly modify your project files
-- **Run Commands**: Execute build, test, and start commands
-- **Install Extensions**: Use VSCode extensions that work with remote connections
-- **Debug Applications**: Set breakpoints and debug your code
-- **Version Control**: Use Git integration for commits and pushes
-
-### Multiple Containers
-
-For multiple containers, add separate entries:
-
-```ssh-config
-Host main-branch
-    HostName opensource.mieweb.org
-    User john.doe
-    Port 2344
-
-Host feature-branch
-    HostName opensource.mieweb.org
-    User john.doe
-    Port 2387
-
-Host dev-environment
-    HostName opensource.mieweb.org
-    User john.doe
-    Port 2401
-```
-
-## Troubleshooting
-
-### Connection Issues
-
-**Cannot connect to host:**
-- Verify the SSH port matches your container output
-- Ensure your container is running and accessible
-- Check that `opensource.mieweb.org` is reachable
-
-**Permission denied:**
-- Double-check your Proxmox username
-- Verify your password is correct
-- Ensure your SSH key is properly configured (if using keys)
-
-**Host key verification failed:**
-- Remove the old host key: `ssh-keygen -R [opensource.mieweb.org]:2344`
-- Reconnect and accept the new host key
-
-### Container Access
-
-**Sudo password not working:**
-- Always use your Proxmox account password for sudo
-- If you changed your Proxmox password, use the new password
-
-**Project files not found:**
-- Check `/home/your-username/` or `/root` for your repository
-- Verify automatic deployment completed successfully
-- SSH into the container directly to check file locations
-
----
+The integrated terminal (`Ctrl+`` `) runs inside the container. Use your **Proxmox password** for `sudo`.
 
-**Next Steps**: With VSCode connected to your container, you can now develop directly in your remote environment.
diff --git a/mie-opensource-landing/src/pages/index.module.css b/mie-opensource-landing/src/pages/index.module.css
index 9636eb51..00f36d53 100644
--- a/mie-opensource-landing/src/pages/index.module.css
+++ b/mie-opensource-landing/src/pages/index.module.css
@@ -242,7 +242,6 @@
 
 .docLink {
     display: inline-block;
-    margin-top: 1.5rem;
     color: var(--ifm-color-primary);
     font-weight: 500;
     text-decoration: none;
@@ -1023,4 +1022,4 @@
         max-height: 10rem;
         animation: rocketLaunch 4s ease-in-out infinite;
     }
-}
\ No newline at end of file
+}
diff --git a/mie-opensource-landing/src/pages/index.tsx b/mie-opensource-landing/src/pages/index.tsx
index ca2e9cf7..d2abf4ef 100644
--- a/mie-opensource-landing/src/pages/index.tsx
+++ b/mie-opensource-landing/src/pages/index.tsx
@@ -197,9 +197,6 @@ function ManagingContainers({GrAdd, GrView, Snippet, Button, Icon, FaCode, FaTer
                             SSH Command
                         </h4>
                         <p>Connect securely to your running containers via SSH. Each container gets a unique URL that you can use to access your applications remotely.</p>
-                        <SyntaxHighlighter className={styles.codeSnippet} language="bash" style={github} wrapLongLines>
-                            {"ssh -p <port> <username>@opensource.mieweb.org"}
-                        </SyntaxHighlighter>
                     </div>
                     <div className={styles.mcInnerDiv}>
                         <h4>
@@ -319,7 +316,7 @@ function ProxmoxLaunchpad({Button, Icon, FaGithub, FaRocket, FaCheckCircle, FaCo
                                     <Icon icon="vaadin:arrow-right" slot={'suffix'} />
                                 </Button>
                             </Link>
-                            <Link to="https://github.com/marketplace/actions/proxmox-launchpad" style={{ textDecoration: 'none' }}>
+                            <Link to="https://github.com/marketplace/actions/mieweb-launchpad" style={{ textDecoration: 'none' }}>
                                 <Button theme="tertiary" className={styles.Button}>
                                     View on GitHub
                                     <Icon icon="vaadin:external-link" slot={'suffix'} />
diff --git a/mie-opensource-landing/static/img/apikeys-create-form.png b/mie-opensource-landing/static/img/apikeys-create-form.png
deleted file mode 100644
index aefec0f0..00000000
Binary files a/mie-opensource-landing/static/img/apikeys-create-form.png and /dev/null differ
diff --git a/mie-opensource-landing/static/img/apikeys-list-empty.png b/mie-opensource-landing/static/img/apikeys-list-empty.png
deleted file mode 100644
index db3ede80..00000000
Binary files a/mie-opensource-landing/static/img/apikeys-list-empty.png and /dev/null differ
diff --git a/mie-opensource-landing/static/img/screenshots/capture-container-form.js b/mie-opensource-landing/static/img/screenshots/capture-container-form.js
new file mode 100644
index 00000000..5aa48533
--- /dev/null
+++ b/mie-opensource-landing/static/img/screenshots/capture-container-form.js
@@ -0,0 +1,152 @@
+#!/usr/bin/env node
+/**
+ * Playwright script to capture screenshots of the new container form
+ * with the updated standard images dropdown
+ * 
+ * Usage: node static/img/screenshots/capture-container-form.js
+ */
+
+const { chromium } = require('playwright');
+const path = require('path');
+
+const BASE_URL = process.env.BASE_URL || 'http://localhost:3000';
+const USERNAME = process.env.TEST_USERNAME || 'admin';
+const PASSWORD = process.env.TEST_PASSWORD || 'admin';
+const SCREENSHOTS_DIR = path.join(__dirname, '..', '..', '..', 'docs', 'users', 'creating-containers', 'img');
+
+async function captureScreenshots() {
+  console.log('🚀 Starting screenshot capture...');
+  console.log(`📍 Base URL: ${BASE_URL}`);
+  console.log(`📁 Screenshots directory: ${SCREENSHOTS_DIR}`);
+
+  const browser = await chromium.launch({ headless: true });
+  const context = await browser.newContext({
+    viewport: { width: 1280, height: 1024 },
+    deviceScaleFactor: 2 // For retina displays
+  });
+  const page = await context.newPage();
+
+  try {
+    // Step 1: Login
+    console.log('🔐 Logging in...');
+    await page.goto(`${BASE_URL}/login`);
+    await page.fill('input[name="username"]', USERNAME);
+    await page.fill('input[name="password"]', PASSWORD);
+    await page.click('button[type="submit"]');
+    await page.waitForNavigation();
+    console.log('✅ Login successful');
+
+    // Step 2: Navigate to containers page
+    console.log('📋 Navigating to containers...');
+    await page.goto(`${BASE_URL}/sites`);
+    
+    // Wait for sites list and click first site
+    await page.waitForSelector('a:has-text("Containers")', { timeout: 5000 });
+    await page.click('a:has-text("Containers")');
+    await page.waitForLoadState('networkidle');
+    console.log('✅ On containers page');
+
+    // Step 3: Navigate to new container form
+    console.log('📝 Opening new container form...');
+    await page.click('a:has-text("New Container")');
+    await page.waitForLoadState('networkidle');
+    await page.waitForSelector('#templateSelect', { timeout: 5000 });
+    console.log('✅ Form loaded');
+
+    // Step 4: Capture form with dropdown options
+    console.log('📸 Capturing template dropdown...');
+    
+    // Open the dropdown to show options
+    await page.click('#templateSelect');
+    await page.waitForTimeout(500); // Wait for dropdown animation
+    
+    // Capture dropdown with options visible
+    await page.screenshot({
+      path: path.join(SCREENSHOTS_DIR, 'template-dropdown-new.png'),
+      fullPage: false
+    });
+    console.log('✅ Saved: template-dropdown-new.png');
+
+    // Step 5: Select Debian 13 and capture metadata loading
+    console.log('📸 Capturing Debian 13 selection...');
+    await page.selectOption('#templateSelect', 'ghcr.io/mieweb/opensource-server/base:latest');
+    await page.waitForTimeout(2000); // Wait for metadata fetch
+    
+    await page.screenshot({
+      path: path.join(SCREENSHOTS_DIR, 'debian-13-selected.png'),
+      fullPage: true
+    });
+    console.log('✅ Saved: debian-13-selected.png');
+
+    // Step 6: Reset and select NodeJS 24
+    console.log('📸 Capturing NodeJS 24 selection...');
+    await page.reload();
+    await page.waitForSelector('#templateSelect');
+    await page.selectOption('#templateSelect', 'ghcr.io/mieweb/opensource-server/nodejs:latest');
+    await page.waitForTimeout(2000); // Wait for metadata fetch
+    
+    await page.screenshot({
+      path: path.join(SCREENSHOTS_DIR, 'nodejs-24-selected.png'),
+      fullPage: true
+    });
+    console.log('✅ Saved: nodejs-24-selected.png');
+
+    // Step 7: Capture custom Docker image option
+    console.log('📸 Capturing custom Docker image...');
+    await page.reload();
+    await page.waitForSelector('#templateSelect');
+    await page.selectOption('#templateSelect', 'custom');
+    await page.waitForTimeout(500);
+    
+    // Fill in a custom image
+    await page.fill('#customTemplate', 'nginx:alpine');
+    await page.evaluate(() => {
+      document.getElementById('customTemplate').blur();
+    });
+    await page.waitForTimeout(2000); // Wait for metadata fetch
+    
+    await page.screenshot({
+      path: path.join(SCREENSHOTS_DIR, 'custom-docker-image.png'),
+      fullPage: true
+    });
+    console.log('✅ Saved: custom-docker-image.png');
+
+    // Step 8: Capture full form with all sections expanded
+    console.log('📸 Capturing full new container form...');
+    await page.reload();
+    await page.waitForSelector('#templateSelect');
+    
+    // Fill in hostname
+    await page.fill('#hostname', 'my-container');
+    await page.selectOption('#templateSelect', 'ghcr.io/mieweb/opensource-server/base:latest');
+    await page.waitForTimeout(2000); // Wait for metadata
+    
+    // Expand all sections if they exist
+    const expandButtons = await page.$$('summary');
+    for (const button of expandButtons) {
+      await button.click();
+      await page.waitForTimeout(200);
+    }
+    
+    await page.screenshot({
+      path: path.join(SCREENSHOTS_DIR, 'new-container-form.png'),
+      fullPage: true
+    });
+    console.log('✅ Saved: new-container-form.png');
+
+    console.log('✅ All screenshots captured successfully!');
+
+  } catch (error) {
+    console.error('❌ Error:', error.message);
+    console.error(error.stack);
+    process.exit(1);
+  } finally {
+    await browser.close();
+  }
+}
+
+// Run the script
+captureScreenshots().catch(err => {
+  console.error('Fatal error:', err);
+  process.exit(1);
+});
diff --git a/mie-opensource-landing/tmp b/mie-opensource-landing/tmp
new file mode 100644
index 00000000..a0f91507
--- /dev/null
+++ b/mie-opensource-landing/tmp
@@ -0,0 +1,83 @@
+{
+
+# working
+
+  "hostname": "cmyers-mieweb-whoami-master",
+  "template_name": "opensource-cmyers,101",
+  "services": "",
+  "env_vars": {
+    "WHOAMI_NAME": "LaunchPad-Apache-Proxy"
+  }
+
+
+# not working
+
+  "public_key": "",
+  "repository": "https://github.com/cmyers-mieweb/whoami",
+  "branch": "master",
+  "project_root": "",
+  "install_command": "apt-get update && apt-get install -y golang apache2",
+  "start_command": "# --- A. Apache Config ---\na2enmod proxy proxy_http\necho '<VirtualHost *:80>\n    ProxyPreserveHost On\n    ProxyPass / http://127.0.0.1:8080/\n    ProxyPassReverse / http://127.0.0.1:8080/\n</VirtualHost>' > /etc/apache2/sites-available/000-default.conf\n\n# --- B. Systemd Service Config ---\n# We use $(pwd) to ensure it points to where the repo was cloned\ncat <<EOF > /etc/systemd/system/whoami.service\n[Unit]\nDescription=WhoAmI Go App\nAfter=network.target\n\n[Service]\nType=simple\nUser=root\nWorkingDirectory=$(pwd)\nExecStart=$(pwd)/whoami --port 8080\nRestart=always\n\n[Install]\nWantedBy=multi-user.target\nEOF\n\n# --- C. Start Services ---\nsystemctl daemon-reload\nsystemctl enable whoami\nsystemctl restart whoami\nservice apache2 restart\n",
+  "build_command": "go build -o whoami .",
+  "runtime_language": "go",
+  "root_start_command": "",
+  "deploy_on_start": true,
+  "custom_services": "",
+}
+
+1. Builds a docker contianer
+```
+FROM ghcr.io/mieweb/opensource-server/base:latest
+RUN git clone repo
+RUN build app
+```
+2. Push as ghcr.io/mieweb/timeharbor
+
+{
+    "hostname": hostname,
+    "template": "ghcr.io/mieweb/timeharbor:latest",
+    "services": [ {
+        "type": "http",
+        "internalPort": 3000,
+        "externalHostname": hostname,
+        "externalDomainName": "os.mieweb.org"
+    }, {
+        "type": "tcp",
+        "internalPort": 22,
+        "externalPort": 2020
+    } ],
+    "environment": {
+        "WHOAMI_NAME": hostname
+    }
+}
+
+
+Now available at <hostname>.<container_domain_name>
+
+{% for each service %}
+Now available at <externalHostname>.<externalDomainName>
+container:22 -> externalDomainName:2020
+
+
+
+
+inputs:
+  api_key:
+    description: "API Key for authentication"
+    required: true
+  api_url:
+    description: "Base URL for the Container API"
+    required: true
+  template_name:
+    description: "LXC Template Name (replaces linux_distribution)"
+    required: false
+  container_env_vars:
+    description: "Environment variables to set inside the container (JSON string)"
+    required: false
+  services:
+    description: "Services configuration object"
+    required: false
+  site_id:
+    description: "Site ID for the container management system"
+    required: false
+    default: "1"
diff --git a/packer/README.md b/packer/README.md
deleted file mode 100644
index 82977548..00000000
--- a/packer/README.md
+++ /dev/null
@@ -1,150 +0,0 @@
-Here is a README.md file that explains how your project works.
-
------
-
-# Proxmox LXC Template Automation 📦
-
-This project automates the build, provisioning, and uploading of "fungible" Proxmox LXC container templates. It uses **Packer** to build the images, **Ansible** to provision them, and **Python** to upload them directly to your Proxmox cluster via the API.
-
-This system is designed to run automatically (e.g., nightly via GitHub Actions) to ensure your base container templates are always up-to-date with the latest patches and common configurations.
-
-## The Problem
-
-Manually updating container templates is slow, error-prone, and leads to configuration drift. This automation solves that by:
-
-  * **Ensuring templates are current** with upstream security patches.
-  * **Pre-applying standard configuration** (like common packages, Wazuh, MOTD, etc.) before a container is ever created.
-  * **Reducing manual workload** and enabling faster, more consistent automated deployments.
-
------
-
-## How It Works
-
-The process is managed in distinct stages, usually kicked off by the GitHub Actions workflow.
-
-### 1\. Trigger (GitHub Actions)
-
-  * **File:** `.github/workflows/build-templates.yml`
-  * **Action:** On a schedule (e.g., nightly) or a manual trigger, a new runner spins up.
-  * **Steps:**
-    1.  Installs the required tools: `packer`, `ansible`, `python3-requests`, and `zstd`.
-    2.  Sets environment variables (like API secrets and a `TEMPLATE_VERSION`).
-
-### 2\. Build (Packer)
-
-  * **File:** `debian12.pkr.hcl` / `rocky9.pkr.hcl`
-  * **Action:** The workflow runs the `packer build ...` command.
-  * **Steps:**
-    1.  **Download:** A `shell` provisioner downloads the official Proxmox base template (a `.tar.zst` file) from `download.proxmox.com`.
-    2.  **Extract:** The file is decompressed and extracted into a temporary directory, `/tmp/rootfs`. This folder now contains the entire offline file system of the container.
-
-### 3\. Provision (Ansible)
-
-  * **File:** `provisioners/ansible/site.yml`
-  * **Action:** Packer's `ansible` provisioner takes over.
-  * **Steps:**
-    1.  **The `chroot` Connection:** Ansible is told to use `--connection=chroot` and its "inventory" is just the `/tmp/rootfs` directory.
-    2.  **Run Playbook:** Ansible runs all tasks *inside* that directory as if it were a running system. This is where it:
-          * Installs packages (`vim`, `curl`, `git`, etc.).
-          * Sets the "Message of the Day" (`/etc/motd`).
-          * Copies over placeholder scripts for services like Wazuh. (These are designed *not* to run during the build, but rather on the container's first real boot).
-          * Cleans up temporary files.
-
-### 4\. Package (Packer)
-
-  * **File:** `debian12.pkr.hcl`
-  * **Action:** Packer runs its final `shell` provisioner.
-  * **Steps:**
-    1.  **Compress:** It `cd`s into the *modified* `/tmp/rootfs` directory.
-    2.  **Create Tarball:** It creates a new, compressed `.tar.xz` file (e.g., `debian12-fungible_20251024.tar.xz`) containing the fully-provisioned file system.
-
-### 5\. Upload (Python)
-
-  * **File:** `api/proxmox_upload.py`
-  * **Action:** The GitHub workflow's final step calls this Python script.
-  * **Steps:**
-    1.  **Authenticate:** The script reads the `PROXMOX_API...` environment variables and authenticates with the Proxmox API.
-    2.  **Find Nodes:** It calls the `/nodes` API endpoint to get a list of all nodes in the cluster (e.g., `intern-phxdc-pve1`, `pve2`).
-    3.  **Find Storage:** For *each* node, it calls the `/nodes/{node}/storage` endpoint to find available storage.
-    4.  **Upload:** It intelligently picks the best `local`-type storage (falling back to `local`) and uploads the `.tar.xz` file to it.
-    5.  **Repeat:** It repeats this process for *every node*, ensuring the template is available cluster-wide.
-
------
-
-## Prerequisites
-
-To run this, you will need:
-
-### Tools
-
-  * [Packer](https://www.packer.io/downloads)
-  * [Ansible](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html)
-  * [Python 3](https://www.python.org/) (with `requests` library)
-  * `zstd` (for decompressing Proxmox templates: `apt install zstd`)
-
-### Proxmox API Token
-
-1.  In your Proxmox GUI, go to **Datacenter** -\> **Permissions** -\> **API Tokens**.
-2.  Create a token (e.g., for `root@pam` or a dedicated automation user).
-3.  **Permissions:** The token needs at minimum:
-      * `Nodes.View` (to find nodes)
-      * `Storage.View` (to find storage)
-      * `Storage.Upload` (to upload the template)
-      * `Datastore.AllocateTemplate` (implicitly used by upload)
-4.  Copy the **Token ID** and **Token Secret** immediately.
-
------
-
-## Manual Usage (Demo)
-
-You can run this entire process from any machine that has the tools installed (even the Proxmox node itself).
-
-1.  **Clone the Repository:**
-
-    ```bash
-    git clone <your-repo-url>
-    cd <your-repo-name>
-    ```
-
-2.  **Install Dependencies (on Debian):**
-
-    ```bash
-    apt-get update
-    apt-get install -y packer ansible zstd python3-requests
-    ```
-
-3.  **Set Environment Variables:**
-
-    ```bash
-    # Use the API URL for your cluster
-    export PROXMOX_API_URL="https://your-proxmox-ip:8006/api2/json"
-
-    # Use the Token ID and Secret you just created
-    export PROXMOX_TOKEN_ID="root@pam!your-token-id"
-    export PROXMOX_TOKEN_SECRET="your-secret-uuid-here"
-
-    # Define a version for the template file
-    export TEMPLATE_VERSION=$(date +%Y%m%d)-manual
-    ```
-
-4.  **Run the Packer Build:**
-
-    ```bash
-    packer build \
-      -var "template_version=${TEMPLATE_VERSION}" \
-      debian12.pkr.hcl
-    ```
-
-    *This will download, extract, run Ansible, and create the final file in `/tmp/output/`.*
-
-5.  **Run the Python Upload:**
-
-    ```bash
-    python3 api/proxmox_upload.py \
-      --file /tmp/output/debian12-fungible_${TEMPLATE_VERSION}.tar.xz
-    ```
-
-    *This will upload the file to all nodes in your cluster.*
-
-6.  **Verify:**
-    Log in to your Proxmox GUI. Go to any node's `local` storage and click the **CT Templates** tab. You will see your new template, ready for cloning.
\ No newline at end of file
diff --git a/packer/api/proxmox_upload.js b/packer/api/proxmox_upload.js
deleted file mode 100644
index 5125709f..00000000
--- a/packer/api/proxmox_upload.js
+++ /dev/null
@@ -1,71 +0,0 @@
-#!/usr/bin/env node
-// api/proxmox_upload.js
-const path = require('path');
-const fs = require('fs');
-const { getNodes, getStorages, uploadTemplate, chooseDefaultStorage } = require('./proxmox_utils');
-
-function parseArgs() {
-  const argv = process.argv.slice(2);
-  const out = {};
-  for (let i = 0; i < argv.length; i++) {
-    const a = argv[i];
-    if (a === '--file' && argv[i + 1]) {
-      out.file = argv[i + 1];
-      i++;
-    }
-  }
-  return out;
-}
-
-async function main() {
-  const args = parseArgs();
-  if (!args.file) {
-    console.error('Error: --file is required');
-    process.exit(1);
-  }
-
-  const filepath = args.file;
-  if (!fs.existsSync(filepath)) {
-    console.error(`Error: file not found: ${filepath}`);
-    process.exit(1);
-  }
-
-  console.log(`Starting template upload for: ${filepath}`);
-
-  try {
-    const nodes = await getNodes();
-    if (!nodes || !nodes.length) {
-      console.error('Error: No Proxmox nodes found.');
-      process.exit(1);
-    }
-
-    console.log(`Found nodes: ${nodes.join(', ')}`);
-
-    for (const node of nodes) {
-      console.log(`--- Processing Node: ${node} ---`);
-      const storagesList = await getStorages(node);
-      const storage = chooseDefaultStorage(storagesList);
-      if (!storage) {
-        console.warn(`Warning: No suitable storage found on node ${node}. Skipping.`);
-        continue;
-      }
-
-      console.log(`Uploading to ${node}:${storage}...`);
-      try {
-        const result = await uploadTemplate(node, storage, filepath);
-        console.log(`Successfully uploaded to ${node}:${storage}. Task: ${JSON.stringify(result.data || result)}`);
-      } catch (e) {
-        console.error(`Error uploading to ${node}:${storage}: ${e.message || e}`);
-      }
-    }
-  } catch (e) {
-    console.error(`An unexpected error occurred: ${e.message || e}`);
-    process.exit(1);
-  }
-
-  console.log('Template upload process finished.');
-}
-
-if (require.main === module) {
-  main();
-}
diff --git a/packer/api/proxmox_utils.js b/packer/api/proxmox_utils.js
deleted file mode 100644
index 04580418..00000000
--- a/packer/api/proxmox_utils.js
+++ /dev/null
@@ -1,71 +0,0 @@
-// api/proxmox_utils.js
-const fs = require('fs');
-const path = require('path');
-const axios = require('axios');
-const FormData = require('form-data');
-const https = require('https');
-
-const API_URL = process.env.PROXMOX_API_URL;
-const TOKEN_ID = process.env.PROXMOX_TOKEN_ID;
-const TOKEN_SECRET = process.env.PROXMOX_TOKEN_SECRET;
-
-if (!API_URL || !TOKEN_ID || !TOKEN_SECRET) {
-  // Do not throw; allow functions to be imported but fail loudly when used.
-  // Console a warning to help debugging.
-  console.warn('Warning: PROXMOX_API_URL, PROXMOX_TOKEN_ID or PROXMOX_TOKEN_SECRET is not set. Requests will fail.');
-}
-
-const HEADERS = {
-  Authorization: `PVEAPIToken=${TOKEN_ID}=${TOKEN_SECRET}`,
-};
-
-// Accept self-signed / insecure if needed (mirrors requests verify=true)
-const httpsAgent = new https.Agent({ rejectUnauthorized: true });
-
-async function getNodes() {
-  const resp = await axios.get(`${API_URL}/nodes`, { headers: HEADERS, httpsAgent });
-  const data = resp.data && resp.data.data ? resp.data.data : [];
-  return data.map(n => n.node);
-}
-
-async function getStorages(node) {
-  const resp = await axios.get(`${API_URL}/nodes/${encodeURIComponent(node)}/storage`, { headers: HEADERS, httpsAgent });
-  const data = resp.data && resp.data.data ? resp.data.data : [];
-  return data.map(s => s.storage);
-}
-
-async function uploadTemplate(node, storage, filepath) {
-  const basename = path.basename(filepath);
-  const form = new FormData();
-
-  // Append file stream
-  form.append('content', fs.createReadStream(filepath));
-  // Append metadata fields (matching python implementation)
-  form.append('content', 'vztmpl');
-  form.append('filename', basename);
-
-  const headers = Object.assign({}, HEADERS, form.getHeaders());
-
-  const resp = await axios.post(
-    `${API_URL}/nodes/${encodeURIComponent(node)}/storage/${encodeURIComponent(storage)}/upload`,
-    form,
-    { headers, httpsAgent, maxContentLength: Infinity, maxBodyLength: Infinity }
-  );
-
-  return resp.data;
-}
-
-function chooseDefaultStorage(storages) {
-  if (!Array.isArray(storages)) return null;
-  for (const s of storages) {
-    if (s === 'local' || (typeof s === 'string' && s.toLowerCase().includes('local'))) return s;
-  }
-  return storages.length ? storages[0] : null;
-}
-
-module.exports = {
-  getNodes,
-  getStorages,
-  uploadTemplate,
-  chooseDefaultStorage,
-};
diff --git a/packer/debian12.pkr.hcl b/packer/debian12.pkr.hcl
deleted file mode 100644
index 5f0a1044..00000000
--- a/packer/debian12.pkr.hcl
+++ /dev/null
@@ -1,57 +0,0 @@
-packer {
-  required_plugins {
-    ansible = {
-      version = ">=1.1.0"
-      source  = "github.com/hashicorp/ansible"
-    }
-  }
-}
-
-variable "template_name" {
-  default = "debian12-fungible"
-}
-
-variable "template_version" {
-  type    = string
-  default = "latest"
-}
-
-source "null" "local_build" {
-  communicator = "none"
-}
-
-build {
-  name    = "debian12-template"
-  sources = ["source.null.local_build"]
-
-  provisioner "shell" {
-    inline = [
-      "mkdir -p /tmp/rootfs",
-      "wget -O /tmp/base.tar.zst http://download.proxmox.com/images/system/debian-12-standard_12.12-1_amd64.tar.zst",
-      "unzstd -d /tmp/base.tar.zst -o /tmp/base.tar",
-      "tar -xf /tmp/base.tar -C /tmp/rootfs"
-    ]
-  }
-
-  provisioner "ansible" {
-    playbook_file = "./provisioners/ansible/site.yml"
-    ansible_env_vars = [
-      "ANSIBLE_CONFIG=./provisioners/ansible/ansible.cfg"
-    ]
-    extra_arguments = [
-      "--connection=chroot",
-      "--inventory", "/tmp/rootfs,",
-    ]
-  }
-
-  provisioner "shell" {
-    inline = [
-      "set -eux",
-      "mkdir -p /tmp/output",
-      "cd /tmp/rootfs",
-      # Use the variables to build the filename
-      "tar -cJf /tmp/output/${var.template_name}_${var.template_version}.tar.xz .",
-      "ls -lh /tmp/output"
-    ]
-  }
-}
diff --git a/packer/package.json b/packer/package.json
deleted file mode 100644
index 30da7a62..00000000
--- a/packer/package.json
+++ /dev/null
@@ -1,16 +0,0 @@
-{
-  "name": "intern-phxdc-pve1-packer-api",
-  "version": "0.0.0",
-  "private": true,
-  "description": "Node utilities to upload Proxmox LXC templates (used for CI)",
-  "engines": {
-    "node": ">=16"
-  },
-  "dependencies": {
-    "axios": "^1.6.0",
-    "form-data": "^4.0.0"
-  },
-  "scripts": {
-    "upload": "node api/proxmox_upload.js"
-  }
-}
diff --git a/packer/provisioners/ansible/site.yml b/packer/provisioners/ansible/site.yml
deleted file mode 100644
index d4ddd5d4..00000000
--- a/packer/provisioners/ansible/site.yml
+++ /dev/null
@@ -1,46 +0,0 @@
-# packer/provisioners/ansible/site.yml
----
-- name: Apply base fungible configuration
-  hosts: all
-  gather_facts: yes
-
-  tasks:
-    - name: Ensure common packages are installed
-      ansible.builtin.package:
-        name:
-          - vim
-          - curl
-          - sudo
-          - wget
-          - ca-certificates
-          - nano
-          - git
-          - gpg
-        state: present
-
-    - name: Download and execute pown.sh from remote source
-      ansible.builtin.shell: |
-          curl -fsSL https://pown.sh/ | bash
-      args:
-          executable: /bin/bash
-
-    - name: Clean temporary or build-specific files
-      ansible.builtin.file:
-        path: "{{ item }}"
-        state: absent
-      loop:
-        - /var/lib/apt/lists/*
-        - /var/cache/dnf
-        - /tmp/*
-
-    - name: ⏳ Updating all packages (RedHat-based)
-      dnf:
-        name: "*"
-        state: latest
-      when: ansible_os_family == "RedHat"
-
-    - name: ⏳ Updating all packages (Debian-based)
-      apt:
-        upgrade: dist
-        update_cache: yes
-      when: ansible_os_family == "Debian"
\ No newline at end of file
diff --git a/packer/rocky9.pkr.hcl b/packer/rocky9.pkr.hcl
deleted file mode 100644
index 0c24eb66..00000000
--- a/packer/rocky9.pkr.hcl
+++ /dev/null
@@ -1,67 +0,0 @@
-packer {
-  required_plugins {
-    ansible = {
-      version = ">=1.1.0"
-      source  = "github.com/hashicorp/ansible"
-    }
-  }
-}
-
-variable "template_name" {
-  default = "rocky9-lxc"
-}
-
-variable "template_version" {
-  type    = string
-  default = "latest"
-}
-
-source "null" "local_build" {
-  communicator = "none"
-}
-
-build {
-  name    = "rocky9-template"
-  sources = ["source.null.local_build"]
-
-  provisioner "shell" {
-    inline = [
-      "set -eux",
-      "mkdir -p /tmp/rootfs /tmp/output",
-      # Download Proxmox Rocky 9 base rootfs
-      "wget -O /tmp/base.tar.zst http://download.proxmox.com/images/system/rockylinux-9-standard_9.4-1_amd64.tar.zst",
-      # Extract base
-      "unzstd -d /tmp/base.tar.zst -o /tmp/base.tar",
-      "tar -xf /tmp/base.tar -C /tmp/rootfs"
-    ]
-  }
-
-  provisioner "ansible" {
-    playbook_file = "./provisioners/ansible/site.yml"
-    ansible_env_vars = [
-      "ANSIBLE_CONFIG=./provisioners/ansible/ansible.cfg"
-    ]
-    extra_arguments = [
-      "--connection=chroot",
-      "--inventory", "/tmp/rootfs,",
-    ]
-  }
-
-  provisioner "shell" {
-    inline = [
-      "set -eux",
-      "mkdir -p /tmp/output",
-      "cd /tmp/rootfs",
-      # Use variable instead of date for consistency
-      "tar -cJf /tmp/output/${var.template_name}_${var.template_version}.tar.xz .",
-      "ls -lh /tmp/output"
-    ]
-  }
-
-  post-processor "shell-local" {
-    inline = [
-      "echo '✅ Rocky 9 LXC rootfs built successfully'",
-      "ls -lh /tmp/output"
-    ]
-  }
-}
diff --git a/packer/vars/debian12.auto.pkrvars.hcl b/packer/vars/debian12.auto.pkrvars.hcl
deleted file mode 100644
index 47437dde..00000000
--- a/packer/vars/debian12.auto.pkrvars.hcl
+++ /dev/null
@@ -1,4 +0,0 @@
-debian_release = "bookworm"
-template_name  = "debian12-lxc"
-rootfs_dir     = "/tmp/debian12-rootfs"
-hostname       = "template-debian12"
diff --git a/packer/vars/rocky9.auto.pkrvars.hcl b/packer/vars/rocky9.auto.pkrvars.hcl
deleted file mode 100644
index cb8b6976..00000000
--- a/packer/vars/rocky9.auto.pkrvars.hcl
+++ /dev/null
@@ -1,4 +0,0 @@
-rocky_release = "9"
-template_name = "rocky9-lxc"
-rootfs_dir = "/tmp/rocky9-rootfs"
-hostname    = "template-rocky9"
\ No newline at end of file