DEV Community: PRATYAY MUSTAFI

Lightcms: A CMS that allows you to rediscover the writer Within You ✍️

PRATYAY MUSTAFI — Tue, 27 Oct 2026 11:38:57 +0000

LightCMS is an easy to use, interactive, Git based CMS built to make the process of writing as enjoyable as possible.

Light cms by default is compatible with any static site generator (SSG) which supports front matter schema, LightCMS makes creating, managing, and publishing content enjoyable.

Whether you’re sharing your experiences, documenting your journey, or putting your thoughts into words, LightCMS makes it easier to turn your ideas into something meaningful.

Give LightCMS a try. You won’t regret the time you spend exploring it!

Live: https://www.lightcms.me/
GitHub: https://github.com/light-cms/lightcms

newsy a free to use zero hastle newsletter platform for your static sites powered by github.

PRATYAY MUSTAFI — Thu, 15 Oct 2026 12:11:40 +0000

PRATYAY MUSTAFI

Oct 15

GitHub: Enable Newsletter Using newsy Widget.

#webdev #productivity #tutorial #javascript

1 min read

[Boost]

PRATYAY MUSTAFI — Thu, 15 Oct 2026 12:08:32 +0000

PRATYAY MUSTAFI

Oct 15

GitHub: Enable Newsletter Using newsy Widget.

#webdev #productivity #tutorial #javascript

1 min read

GitHub: Enable Newsletter Using newsy Widget.

PRATYAY MUSTAFI — Thu, 15 Oct 2026 12:07:50 +0000

Newsy turns your GitHub repo into a newsletter platform.

If you run a Hugo, Astro, Next.js, or Jekyll blog, your posts are already
Markdown files in Git. Your newsletter can live there too — no database,
no SaaS fee.

light-cms / newsy

github backed newsletter platform for your static site

newsy is a newsletter platform for your static site, using GitHub as a backend , inspired by utterances.

✨ Features

📝 Zero-friction publishing — newly added post files trigger an announcement, and so does flipping an existing post from draft to published; other edits and deletes are ignored
💬 Issue as newsletter — upserts one open issue per repo comments thereafter, with lock and unlocking capability
Fully free and opensource — no need to pay for any newsletter service, just use your existing GitHub repo.

🎬 Demo

Video guides:

🚀 Quick start

Install the GitHub App on the repo(s) you publish from:

👉 https://github.com/apps/newsletter-newsy/installations/select_target
Push a new post:
```
git add posts/hello-world.md
git commit -m "hello world"
git push
```
newsy will create (or comment on) an open issue titled announcement with label newsletter containing the commit summary, file list, and…

View on GitHub

How it works

Install the GitHub App on your blog repo.
Publish a new post,
Newsy automatically opens an Announcement with your post content. Readers subscribe to that issue and get notified whenever you publish.

Drafts (draft: true in front matter) are detected and skipped
automatically. Free and open source.

Add a Subscribe button in 10 seconds

Generate one at newsy.lightcms.me and paste it into your static site.

Built in Go, inspired by utterances. and dove letter
Self hostable on Vercel or any server less platform.

Why Your Tauri based appImage not working on Linux (And How to Fix It)

PRATYAY MUSTAFI — Sat, 10 Oct 2026 15:31:00 +0000

Tauri Apps Built as Appimages are not working on modern linux distributions, like fedora, arch

Appimages are one of the nicest ways to distribute an app but not being able to run a format meant to be used on multiple os, is a bad thing. Appimage as a format is crucial for users who want to test a app and use it without the need of installing. Appimages are cool as they comes with all the required dependencies and can be operated on systems such as Windows with WSL2 and FreeBSD with the Linuxulator. Appimages are self contained in nature and requires no root access.

Gtk-Message: 21:07:08.168: Failed to load module "appmenu-gtk-module": 'gtk_module_display_init': /usr/lib64/gtk-3.0/modules/libcolorreload-gtk-module.so: undefined symbol: gtk_module_display_init Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

(apiark:185476): WARNING : 21:07:33.334: atk-bridge: get_device_events_reply: unknown signature

This is a sample app image for a Tauri based rest-api client apiark.

So, I was building Drawx, the offline version of drawy, which provides data sovereignty because nothing ever leaves your machine. However, the Drawx app was not working on my machine because of some odd issues. I wanted to run the AppImage in a portable manner, but using environment variables did not help. Setting WEBKIT_DISABLE_DMABUF_RENDERER=1 or WEBKIT_DISABLE_COMPOSITING_MODE=1 either caused a crash on launch or displayed a blank screen. The issue is that the CI environment adds libraries such as libwayland-client.so inside the AppImage. This creates conflicts between the AppImage’s dependencies and the system’s libraries. The solution is to remove the duplicated dependencies and let the AppImage use the system’s libraries instead of those inside the AppImage.

How to Fix This ?

Remove all dependencies related to wayland from the AppImage. Since XWayland can handle X11 applications, there is no need to bundle these libraries internally. The creator of the AppImage also noted this in his comment.

I have written a shell script to handle this for you. Please create a file at src-tauri/scripts/patch-appimage-wayland.sh and paste the script into it.

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
SRC_TAURI_DIR="$REPO_ROOT/src-tauri"
TAURI_CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}/tauri"

# Clean up temp files on exit
TEMP_BIN=$(mktemp -d)
TEMP_EXTRACT=""
cleanup() {
  rm -rf "$TEMP_BIN"
  if [ -n "$TEMP_EXTRACT" ] && [ -d "$TEMP_EXTRACT" ]; then
    rm -rf "$TEMP_EXTRACT"
  fi
}
trap cleanup EXIT

# 1. Resolve linuxdeploy and appimage tools
LINUXDEPLOY_BIN=""
if [ -d "$TAURI_CACHE_DIR" ]; then
  cached_linuxdeploy=$(find "$TAURI_CACHE_DIR" -maxdepth 1 -name "linuxdeploy-*.AppImage" -print -quit 2>/dev/null || true)
  if [ -n "$cached_linuxdeploy" ] && [ -f "$cached_linuxdeploy" ]; then
    ln -sf "$cached_linuxdeploy" "$TEMP_BIN/linuxdeploy"
    LINUXDEPLOY_BIN="$TEMP_BIN/linuxdeploy"
  fi

  cached_plugin=$(find "$TAURI_CACHE_DIR" -maxdepth 1 -name "linuxdeploy-plugin-appimage.AppImage" -print -quit 2>/dev/null || true)
  if [ -n "$cached_plugin" ] && [ -f "$cached_plugin" ]; then
    ln -sf "$cached_plugin" "$TEMP_BIN/linuxdeploy-plugin-appimage"
  fi
fi

if [ -z "$LINUXDEPLOY_BIN" ] && command -v linuxdeploy >/dev/null 2>&1; then
  LINUXDEPLOY_BIN="$(command -v linuxdeploy)"
fi

export PATH="$TEMP_BIN:$PATH"
export APPIMAGE_EXTRACT_AND_RUN=1

# 2. Patch an AppDir in-place
patch_appdir() {
  local appdir="$1"
  echo "Patching AppDir: $appdir"

  # 1. Write self-contained Wayland compatibility hook
  mkdir -p "$appdir/apprun-hooks"
  cat << 'EOF' > "$appdir/apprun-hooks/wayland-compat.sh"
export DESKTOPINTEGRATION=1

if [ -z "${LD_PRELOAD:-}" ]; then
  for lib in \
    /usr/lib/libwayland-client.so \
    /usr/lib64/libwayland-client.so \
    /usr/lib/x86_64-linux-gnu/libwayland-client.so \
    /usr/lib/aarch64-linux-gnu/libwayland-client.so \
    /usr/lib/arm-linux-gnueabihf/libwayland-client.so; do
    if [ -f "$lib" ]; then
      export LD_PRELOAD="$lib"
      break
    fi
  done
fi
EOF
  chmod +x "$appdir/apprun-hooks/wayland-compat.sh"

  # 2. Patch AppRun so it sources the new hook before executing AppRun.wrapped
  if [ -f "$appdir/AppRun.wrapped" ]; then
    if ! grep -q "wayland-compat.sh" "$appdir/AppRun"; then
      cat << 'EOF' > "$appdir/AppRun"
#!/usr/bin/env bash
HERE="$(dirname "$(readlink -f "${0}")")"
if [ -f "$HERE/apprun-hooks/wayland-compat.sh" ]; then
  . "$HERE/apprun-hooks/wayland-compat.sh"
fi
exec "$HERE/AppRun.wrapped" "$@"
EOF
      chmod +x "$appdir/AppRun"
    fi
  elif [ -f "$appdir/AppRun" ]; then
    mv "$appdir/AppRun" "$appdir/AppRun.wrapped"
    cat << 'EOF' > "$appdir/AppRun"
#!/usr/bin/env bash
HERE="$(dirname "$(readlink -f "${0}")")"
if [ -f "$HERE/apprun-hooks/wayland-compat.sh" ]; then
  . "$HERE/apprun-hooks/wayland-compat.sh"
fi
exec "$HERE/AppRun.wrapped" "$@"
EOF
    chmod +x "$appdir/AppRun"
  fi
}

# 3. Repack AppDir into AppImage
repack_appdir() {
  local appdir="$1"
  local expected_appimage="$2"
  local bundle_dir
  bundle_dir="$(dirname "$expected_appimage")"
  local appimage_base
  appimage_base="$(basename "$expected_appimage")"

  echo "Repacking AppImage into $expected_appimage..."
  (
    cd "$bundle_dir"
    export LDAI_OUTPUT="$appimage_base"

    # Remove existing AppImage before repacking
    [ -f "$expected_appimage" ] && rm -f "$expected_appimage"

    if [ -n "$LINUXDEPLOY_BIN" ]; then
      "$LINUXDEPLOY_BIN" --appdir "$appdir" --output appimage
    elif command -v appimagetool >/dev/null 2>&1; then
      appimagetool "$appdir" "$expected_appimage"
    elif [ -x "$TEMP_BIN/linuxdeploy-plugin-appimage" ]; then
      "$TEMP_BIN/linuxdeploy-plugin-appimage" --appdir "$appdir"
    else
      echo "Error: Could not find linuxdeploy or appimagetool to repack $appdir" >&2
      exit 1
    fi
  )

  echo "Successfully repacked AppImage at $expected_appimage"
}

# 4. Process targets
if [ "${1:-}" != "" ]; then
  TARGET_PATH="$(readlink -f "$1")"
  if [ -d "$TARGET_PATH" ]; then
    patch_appdir "$TARGET_PATH"
    bundle_dir="$(dirname "$TARGET_PATH")"
    appdir_name="$(basename "$TARGET_PATH")"
    expected_appimage="${bundle_dir}/${appdir_name%.AppDir}.AppImage"
    repack_appdir "$TARGET_PATH" "$expected_appimage"
  elif [ -f "$TARGET_PATH" ]; then
    TEMP_EXTRACT=$(mktemp -d)
    echo "Extracting AppImage: $TARGET_PATH"
    (cd "$TEMP_EXTRACT" && "$TARGET_PATH" --appimage-extract >/dev/null)
    EXTRACTED_APPDIR="$TEMP_EXTRACT/squashfs-root"
    patch_appdir "$EXTRACTED_APPDIR"
    repack_appdir "$EXTRACTED_APPDIR" "$TARGET_PATH"
  else
    echo "Error: Target path not found: $TARGET_PATH" >&2
    exit 1
  fi
else
  APPDIRS=()
  while IFS= read -r -d '' dir; do
    APPDIRS+=("$dir")
  done < <(find "$SRC_TAURI_DIR/target" "$REPO_ROOT/target" -type d -name "*.AppDir" -print0 2>/dev/null || true)

  if [ "${#APPDIRS[@]}" -eq 0 ]; then
    echo "No *.AppDir found to patch. (Did you run tauri build?)"
    exit 0
  fi

  for appdir in "${APPDIRS[@]}"; do
    patch_appdir "$appdir"
    bundle_dir="$(dirname "$appdir")"
    appdir_name="$(basename "$appdir")"
    expected_appimage="${bundle_dir}/${appdir_name%.AppDir}.AppImage"
    repack_appdir "$appdir" "$expected_appimage"
  done
fi

echo "Wayland AppImage patching complete."

And Change a Little Thing in the Existing Workflow

Replace All `tauri build` Commands With `tauri build && source src-tauri/scripts/patch-appimage-wayland.sh`

if you are using vite then replace the tauri build command with tauri build && source src-tauri/scripts/patch-appimage-wayland.sh in the scripts section of package.json.

{
 "name": "drawx",
 "version": "0.8.5",
 "type": "module",
 "imports": {
  "#components/*": "./src/components/*.tsx",
  "#lib/*": "./src/lib/*.ts",
  "#hooks/*": "./src/hooks/*.ts"
 },
 "scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  "typecheck": "tsc --noEmit",
  "preview": "vite preview",
  "tauri": "tauri",
  "tauri:build": "tauri build && source src-tauri/scripts/patch-appimage-wayland.sh"
 },
 "dependencies": {
  "@astryxdesign/cli": "^0.5.4",
  "@astryxdesign/core": "^0.5.4",
  "@astryxdesign/theme-matcha": "^0.5.4",
  "@astryxdesign/theme-neutral": "^0.5.4",
  "@astryxdesign/theme-stone": "^0.5.4",
  "@astryxdesign/theme-y2k": "^0.5.4",
  "@excalidraw/excalidraw": "^0.18.1",
  "@fontsource-variable/inter": "^5.3.0",
  "@fontsource-variable/jetbrains-mono": "^5.3.0",
  "@hugeicons/core-free-icons": "^4.3.5",
  "@hugeicons/react": "^1.1.10",
  "@iconify/react": "^6.0.2",
  "@phosphor-icons/react": "^2.1.10",
  "@stylexjs/stylex": "^0.19.1",
  "@tauri-apps/api": "^2.12.1",
  "@tauri-apps/plugin-clipboard-manager": "^2.4.1",
  "@tauri-apps/plugin-dialog": "^2.8.1",
  "@tauri-apps/plugin-fs": "^2.6.0",
  "@tauri-apps/plugin-log": "^2.10.0",
  "@tauri-apps/plugin-opener": "^2.7.0",
  "@tauri-apps/plugin-process": "^2.4.0",
  "@tauri-apps/plugin-updater": "^2.13.2",
  "class-variance-authority": "^0.7.1",
  "clsx": "^2.1.1",
  "lucide-react": "^1.53.0",
  "radix-ui": "^1.7.0",
  "react": "^19.3.0",
  "react-dom": "^19.3.0",
  "react-router-dom": "^7.18.4",
  "tailwind-merge": "^3.7.0",
  "tw-animate-css": "^1.4.0"
 },
 "devDependencies": {
  "@biomejs/biome": "^2.5.15",
  "@oxlint/plugins": "1.81.0",
  "@tailwindcss/vite": "^4.3.3",
  "@tauri-apps/cli": "^2.12.1",
  "@types/node": "^26.6.4",
  "@types/react": "^19.3.0",
  "@types/react-dom": "^19.3.0",
  "@vitejs/plugin-react": "^6.1.2",
  "astryx": "^0.0.0",
  "oxfmt": "^0.72.0",
  "oxlint": "^1.87.0",
  "typescript": "~7.0.2",
  "vite": "^8.3.4",
  "zustand": "^5.0.15"
 },
 "devEngines": {
  "packageManager": {
   "name": "pnpm",
   "version": "^12.10.1",
   "onFail": "warn"
  }
 },
 "packageManager": "pnpm@12.10.1+sha512.ba40a37eb1a370d60fea8c4cf1d364c13bcccef518e98ad2bcee954f539d38da37458e58261a3fa55e06523450ea0ffff9f497b135be41f2c15c1642bacace6c",
 "trustedDependencies": [
  "@astryxdesign/cli",
  "@astryxdesign/core"
 ],
 "allowScripts": {
  "@astryxdesign/cli": true,
  "@astryxdesign/core": true
 }
}

I referred to this blog post for the initial solution to the issue.

Making Tauri Apps Packaged as AppImages Usable Again

PRATYAY MUSTAFI — Sat, 10 Oct 2026 15:31:00 +0000

Tauri Apps Built as Appimages are not working on modern linux distributions, like fedora, arch

(apiark:185476): WARNING : 21:07:33.334: atk-bridge: get_device_events_reply: unknown signature

This is a sample app image for a Tauri based rest-api client apiark.

How to Fix This ?

fixing missing libraries

Have composed a shell script to fix the issue. Create a file src-tauri/scripts/patch-appimage-wayland.sh and paste the script inside

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
SRC_TAURI_DIR="$REPO_ROOT/src-tauri"
TAURI_CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}/tauri"

# Clean up temp files on exit
TEMP_BIN=$(mktemp -d)
TEMP_EXTRACT=""
cleanup() {
  rm -rf "$TEMP_BIN"
  if [ -n "$TEMP_EXTRACT" ] && [ -d "$TEMP_EXTRACT" ]; then
    rm -rf "$TEMP_EXTRACT"
  fi
}
trap cleanup EXIT

# 1. Resolve linuxdeploy and appimage tools
LINUXDEPLOY_BIN=""
if [ -d "$TAURI_CACHE_DIR" ]; then
  cached_linuxdeploy=$(find "$TAURI_CACHE_DIR" -maxdepth 1 -name "linuxdeploy-*.AppImage" -print -quit 2>/dev/null || true)
  if [ -n "$cached_linuxdeploy" ] && [ -f "$cached_linuxdeploy" ]; then
    ln -sf "$cached_linuxdeploy" "$TEMP_BIN/linuxdeploy"
    LINUXDEPLOY_BIN="$TEMP_BIN/linuxdeploy"
  fi

  cached_plugin=$(find "$TAURI_CACHE_DIR" -maxdepth 1 -name "linuxdeploy-plugin-appimage.AppImage" -print -quit 2>/dev/null || true)
  if [ -n "$cached_plugin" ] && [ -f "$cached_plugin" ]; then
    ln -sf "$cached_plugin" "$TEMP_BIN/linuxdeploy-plugin-appimage"
  fi
fi

if [ -z "$LINUXDEPLOY_BIN" ] && command -v linuxdeploy >/dev/null 2>&1; then
  LINUXDEPLOY_BIN="$(command -v linuxdeploy)"
fi

export PATH="$TEMP_BIN:$PATH"
export APPIMAGE_EXTRACT_AND_RUN=1

# 2. Patch an AppDir in-place
patch_appdir() {
  local appdir="$1"
  echo "Patching AppDir: $appdir"

  # 1. Write self-contained Wayland compatibility hook
  mkdir -p "$appdir/apprun-hooks"
  cat << 'EOF' > "$appdir/apprun-hooks/wayland-compat.sh"
export DESKTOPINTEGRATION=1

if [ -z "${LD_PRELOAD:-}" ]; then
  for lib in \
    /usr/lib/libwayland-client.so \
    /usr/lib64/libwayland-client.so \
    /usr/lib/x86_64-linux-gnu/libwayland-client.so \
    /usr/lib/aarch64-linux-gnu/libwayland-client.so \
    /usr/lib/arm-linux-gnueabihf/libwayland-client.so; do
    if [ -f "$lib" ]; then
      export LD_PRELOAD="$lib"
      break
    fi
  done
fi
EOF
  chmod +x "$appdir/apprun-hooks/wayland-compat.sh"

  # 2. Patch AppRun so it sources the new hook before executing AppRun.wrapped
  if [ -f "$appdir/AppRun.wrapped" ]; then
    if ! grep -q "wayland-compat.sh" "$appdir/AppRun"; then
      cat << 'EOF' > "$appdir/AppRun"
#!/usr/bin/env bash
HERE="$(dirname "$(readlink -f "${0}")")"
if [ -f "$HERE/apprun-hooks/wayland-compat.sh" ]; then
  . "$HERE/apprun-hooks/wayland-compat.sh"
fi
exec "$HERE/AppRun.wrapped" "$@"
EOF
      chmod +x "$appdir/AppRun"
    fi
  elif [ -f "$appdir/AppRun" ]; then
    mv "$appdir/AppRun" "$appdir/AppRun.wrapped"
    cat << 'EOF' > "$appdir/AppRun"
#!/usr/bin/env bash
HERE="$(dirname "$(readlink -f "${0}")")"
if [ -f "$HERE/apprun-hooks/wayland-compat.sh" ]; then
  . "$HERE/apprun-hooks/wayland-compat.sh"
fi
exec "$HERE/AppRun.wrapped" "$@"
EOF
    chmod +x "$appdir/AppRun"
  fi
}

# 3. Repack AppDir into AppImage
repack_appdir() {
  local appdir="$1"
  local expected_appimage="$2"
  local bundle_dir
  bundle_dir="$(dirname "$expected_appimage")"
  local appimage_base
  appimage_base="$(basename "$expected_appimage")"

  echo "Repacking AppImage into $expected_appimage..."
  (
    cd "$bundle_dir"
    export LDAI_OUTPUT="$appimage_base"

    # Remove existing AppImage before repacking
    [ -f "$expected_appimage" ] && rm -f "$expected_appimage"

    if [ -n "$LINUXDEPLOY_BIN" ]; then
      "$LINUXDEPLOY_BIN" --appdir "$appdir" --output appimage
    elif command -v appimagetool >/dev/null 2>&1; then
      appimagetool "$appdir" "$expected_appimage"
    elif [ -x "$TEMP_BIN/linuxdeploy-plugin-appimage" ]; then
      "$TEMP_BIN/linuxdeploy-plugin-appimage" --appdir "$appdir"
    else
      echo "Error: Could not find linuxdeploy or appimagetool to repack $appdir" >&2
      exit 1
    fi
  )

  echo "Successfully repacked AppImage at $expected_appimage"
}

# 4. Process targets
if [ "${1:-}" != "" ]; then
  TARGET_PATH="$(readlink -f "$1")"
  if [ -d "$TARGET_PATH" ]; then
    patch_appdir "$TARGET_PATH"
    bundle_dir="$(dirname "$TARGET_PATH")"
    appdir_name="$(basename "$TARGET_PATH")"
    expected_appimage="${bundle_dir}/${appdir_name%.AppDir}.AppImage"
    repack_appdir "$TARGET_PATH" "$expected_appimage"
  elif [ -f "$TARGET_PATH" ]; then
    TEMP_EXTRACT=$(mktemp -d)
    echo "Extracting AppImage: $TARGET_PATH"
    (cd "$TEMP_EXTRACT" && "$TARGET_PATH" --appimage-extract >/dev/null)
    EXTRACTED_APPDIR="$TEMP_EXTRACT/squashfs-root"
    patch_appdir "$EXTRACTED_APPDIR"
    repack_appdir "$EXTRACTED_APPDIR" "$TARGET_PATH"
  else
    echo "Error: Target path not found: $TARGET_PATH" >&2
    exit 1
  fi
else
  APPDIRS=()
  while IFS= read -r -d '' dir; do
    APPDIRS+=("$dir")
  done < <(find "$SRC_TAURI_DIR/target" "$REPO_ROOT/target" -type d -name "*.AppDir" -print0 2>/dev/null || true)

  if [ "${#APPDIRS[@]}" -eq 0 ]; then
    echo "No *.AppDir found to patch. (Did you run tauri build?)"
    exit 0
  fi

  for appdir in "${APPDIRS[@]}"; do
    patch_appdir "$appdir"
    bundle_dir="$(dirname "$appdir")"
    appdir_name="$(basename "$appdir")"
    expected_appimage="${bundle_dir}/${appdir_name%.AppDir}.AppImage"
    repack_appdir "$appdir" "$expected_appimage"
  done
fi

echo "Wayland AppImage patching complete."

And Change a Little Thing in the Existing Workflow

Replace All `tauri build` Commands With `tauri build && source src-tauri/scripts/patch-appimage-wayland.sh`

if you are using vite then replace the tauri build command with tauri build && source src-tauri/scripts/patch-appimage-wayland.sh in the scripts section of package.json.

{
 "name": "drawx",
 "version": "0.8.5",
 "type": "module",
 "imports": {
  "#components/*": "./src/components/*.tsx",
  "#lib/*": "./src/lib/*.ts",
  "#hooks/*": "./src/hooks/*.ts"
 },
 "scripts": {
  "dev": "vite",
  "build": "tsc && vite build",
  "typecheck": "tsc --noEmit",
  "preview": "vite preview",
  "tauri": "tauri",
  "tauri:build": "tauri build && source src-tauri/scripts/patch-appimage-wayland.sh"
 },
 "dependencies": {
  "@astryxdesign/cli": "^0.5.4",
  "@astryxdesign/core": "^0.5.4",
  "@astryxdesign/theme-matcha": "^0.5.4",
  "@astryxdesign/theme-neutral": "^0.5.4",
  "@astryxdesign/theme-stone": "^0.5.4",
  "@astryxdesign/theme-y2k": "^0.5.4",
  "@excalidraw/excalidraw": "^0.18.1",
  "@fontsource-variable/inter": "^5.3.0",
  "@fontsource-variable/jetbrains-mono": "^5.3.0",
  "@hugeicons/core-free-icons": "^4.3.5",
  "@hugeicons/react": "^1.1.10",
  "@iconify/react": "^6.0.2",
  "@phosphor-icons/react": "^2.1.10",
  "@stylexjs/stylex": "^0.19.1",
  "@tauri-apps/api": "^2.12.1",
  "@tauri-apps/plugin-clipboard-manager": "^2.4.1",
  "@tauri-apps/plugin-dialog": "^2.8.1",
  "@tauri-apps/plugin-fs": "^2.6.0",
  "@tauri-apps/plugin-log": "^2.10.0",
  "@tauri-apps/plugin-opener": "^2.7.0",
  "@tauri-apps/plugin-process": "^2.4.0",
  "@tauri-apps/plugin-updater": "^2.13.2",
  "class-variance-authority": "^0.7.1",
  "clsx": "^2.1.1",
  "lucide-react": "^1.53.0",
  "radix-ui": "^1.7.0",
  "react": "^19.3.0",
  "react-dom": "^19.3.0",
  "react-router-dom": "^7.18.4",
  "tailwind-merge": "^3.7.0",
  "tw-animate-css": "^1.4.0"
 },
 "devDependencies": {
  "@biomejs/biome": "^2.5.15",
  "@oxlint/plugins": "1.81.0",
  "@tailwindcss/vite": "^4.3.3",
  "@tauri-apps/cli": "^2.12.1",
  "@types/node": "^26.6.4",
  "@types/react": "^19.3.0",
  "@types/react-dom": "^19.3.0",
  "@vitejs/plugin-react": "^6.1.2",
  "astryx": "^0.0.0",
  "oxfmt": "^0.72.0",
  "oxlint": "^1.87.0",
  "typescript": "~7.0.2",
  "vite": "^8.3.4",
  "zustand": "^5.0.15"
 },
 "devEngines": {
  "packageManager": {
   "name": "pnpm",
   "version": "^12.10.1",
   "onFail": "warn"
  }
 },
 "packageManager": "pnpm@12.10.1+sha512.ba40a37eb1a370d60fea8c4cf1d364c13bcccef518e98ad2bcee954f539d38da37458e58261a3fa55e06523450ea0ffff9f497b135be41f2c15c1642bacace6c",
 "trustedDependencies": [
  "@astryxdesign/cli",
  "@astryxdesign/core"
 ],
 "allowScripts": {
  "@astryxdesign/cli": true,
  "@astryxdesign/core": true
 }
}

Referred blog for initial solution of the issue.

Mastering Toolbx Containers: A Guide to Frictionless Linux Development

PRATYAY MUSTAFI — Fri, 09 Oct 2026 18:35:00 +0000

I recently ran into a problem while trying to work with Homebrew on my Atomic Fedora system. I was developing a custom formula and running brew audit to debug it, but it failed because GCC & ruby was not available on the host, and i was doing brew bundle install to make this work but had no luck.

The issue wasn’t with Homebrew itself, it was that my host environment was missing the specific dependencies needed for that workflow. I could have installed more packages globally on the host, but that would have made the system more cluttered and harder to manage.

Similarly recently I was trying to develop an app in flutter for internal use but have faced issues running that .. and things got solved when I am using a sand boxed environment. Also for agents, toolbox can be a bliss . they can run any command and there is a very low chance of breaking stuff.

Why Toolbox?

Toolbox containers are useful because they integrate well with your host system without forcing you to abandon isolation. They share your home directory and can access host resources such as the SSH agent, while still giving you a clean, disposable Linux environment for development.

That makes them especially useful when you need a project-specific toolchain but don’t want to pollute your main system. They also make it easy to define a development workflow as code instead of manually installing packages every time.

I realized that if I could create my own customized Toolbox image, I could keep the tools and dependencies I use regularly in one reusable environment.

Defining Your Own Development Environment

If you work with package maintenance, formula development, or distro-specific tooling, learning to write a Dockerfile or Containerfile is incredibly valuable. It lets you build a consistent environment that is reproducible and version able.

Here is an example of an AlmaLinux based Toolbox image for Homebrew development:

FROM quay.io/toolbx-images/almalinux-toolbox:latest

LABEL com.github.containers.toolbox="true" \
    name="alma-brew" \
    version="latest" \
    usage="This image is meant to be used with the toolbox or distrobox command" \
    summary="AlmaLinux Toolbox with GCC and Homebrew for developing brew recipes" \
    maintainer="Pratyay Mustafi <pratyaymustafi@outlook.com>"

# Copy setup scripts and package lists
COPY scripts/ /scripts/
COPY packages/ /packages/

# Run the setup scripts, then remove the build-time files
RUN chmod +x /scripts/*.sh && /scripts/*.sh
RUN rm -rf /scripts /packages

This approach makes it easy to build a container that includes exactly what you need, without modifying the host system.

I also wanted an Arch-based environment with Chaotic-AUR and paru, so I created a second image for that workflow:

FROM quay.io/toolbx/arch-toolbox:latest

LABEL com.github.containers.toolbox="true" \
    name="arch-chaotic-toolbox" \
    version="latest" \
    usage="This image is meant to be used with the toolbox or distrobox command" \
    summary="Arch Linux Toolbox with Chaotic-AUR and paru" \
    maintainer="Pratyay Mustafi <pratyaymustafi@outlook.com>"

# Copy setup scripts and package lists
COPY scripts/ /scripts/
COPY packages/ /packages/

# Run the Chaotic-AUR setup script, then remove the build-time files
RUN chmod +x /scripts/*.sh && /scripts/chaotic.sh
RUN rm -rf /scripts /packages

A Simple Layout of the file structure.

A project like this can stay clean and easy to maintain if it follows a simple layout:

.
├── .github
│ └── workflows
│ ├── build.yml
│ └── clean-runs.yml
├── .gitignore
├── ContainerFiles
│ ├── brew
│ └── chaotic
├── LICENSE
├── README.md
├── packages
│ ├── brew.packages
│ └── chaotic.packages
└── scripts
    ├── brew.sh
    └── chaotic.sh

This structure keeps each concern separated:

scripts/ contains the setup logic
packages/ contains package lists
ContainerFiles/ stores the image definitions
README.md explains how to build and use the environment

That keeps the workflow organized and easier to extend later.

Example Package List

For the Arch-based image, the package list can be as simple as this:

devel
git
paru

This is nice because package changes are declarative. If I need to add a tool, I can update the package list and rebuild the image whenever I need a new dependency or a different tool chain.

Setting up Chaotic AUR based toolbox

For Arch-based work, I also wanted a clean way to configure Chaotic AUR and install the packages I use most often. The setup script below does just that:

#!/usr/bin/env bash
set -euo pipefail

echo "==> Configuring Chaotic AUR repository..."
pacman-key --init
pacman-key --recv-key 3056513887B78AEB --keyserver keyserver.ubuntu.com
pacman-key --lsign-key 3056513887B78AEB
pacman -U --noconfirm 'https://geo-mirror.chaotic.cx/chaotic-aur/x86_64/chaotic-keyring.pkg.tar.zst'
pacman -U --noconfirm 'https://geo-mirror.chaotic.cx/chaotic-aur/x86_64/chaotic-mirrorlist.pkg.tar.zst'
sed -i 's|^Server = https://cdn-mirror.chaotic.cx|# Server = https://cdn-mirror.chaotic.cx|' /etc/pacman.d/chaotic-mirrorlist
printf '\n[chaotic-aur]\nInclude = /etc/pacman.d/chaotic-mirrorlist\n' >> /etc/pacman.conf

echo "==> Installing packages from chaotic.packages..."
grep -v '^#' /packages/chaotic.packages > /tmp/chaotic.pkglist
if [! -s /tmp/chaotic.pkglist]; then
    echo "chaotic.packages is missing or empty" >&2
    exit 1
fi
xargs pacman -Syu --needed --noconfirm < /tmp/chaotic.pkglist
rm -f /tmp/chaotic.pkglist
rm -rf /var/cache/pacman/pkg/*

echo "==> Configuring toolbx permissions..."
echo "%wheel ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/toolbox
chmod 0440 /etc/sudoers.d/toolbox

This keeps the setup steps reproducible and easy to manage. If the Arch repository or package list changes, the update is straightforward.

Why This Workflow Works So Well

This pattern has several practical advantages:

Reproducible builds : the environment is defined in code
Portability: the same image can be built elsewhere
Isolation: dependencies stay inside the container instead of the host
Speed: no repeated manual package setup
Simplicity: the environment is easier to debug and maintain.

It is a great fit for package maintenance, Linux tooling, custom formula work, and any development workflow that depends on a specific tool chain.

Toolbox/Distrobox gives you a flexible middle ground: you get the isolation of a container without losing the convenience of working closely with your host environment.

For me, building a specialized toolbox image solved an immediate problem and gave me a more maintainable sand boxed way to work going forward. I can now create exactly the environment I need, whether that’s for Home brew development, Arch based tooling, or any other project-specific workflow.

If you work with Linux tooling, package building, or want reproducible dev setups, this is a workflow with toolbox container based development is worth adopting. Source code on GitHub.


toolbox container type	image link
brew-toolbox	quay.io/pratyay360/brew-toolbox:latest	docker.io/pratyay360/brew-toolbox:latest	ghcr.io/pratyay360/brew-toolbox:latest
chaotic-toolbox	quay.io/pratyay360/chaotic-toolbox:latest	docker.io/pratyay360/chaotic-toolbox:latest	ghcr.io/pratyay360/chaotic-toolbox:latest
android-toolbox	quay.io/pratyay360/android-toolbox:latest

Create Your Own Specialized Toolbox Containers for Development

PRATYAY MUSTAFI — Fri, 09 Oct 2026 18:35:00 +0000

I recently ran into a problem while trying to work on Homebrew on my Atomic Fedora system. I was developing a custom formula and running brew audit, but it failed because GCC & ruby was not available on the host, and i was doing brew bundle install to work reliably but had no luck.

Why Toolbox?

I realized that if I could create my own customized Toolbox image, I could keep the tools and dependencies I use regularly in one reusable environment.

Defining Your Own Development Environment

Here is an example of an AlmaLinux based Toolbox image for Homebrew development:

FROM quay.io/toolbx-images/almalinux-toolbox:latest

LABEL com.github.containers.toolbox="true" \
    name="alma-brew" \
    version="latest" \
    usage="This image is meant to be used with the toolbox or distrobox command" \
    summary="AlmaLinux Toolbox with GCC and Homebrew for developing brew recipes" \
    maintainer="Pratyay Mustafi <pratyaymustafi@outlook.com>"

# Copy setup scripts and package lists
COPY scripts/ /scripts/
COPY packages/ /packages/

# Run the setup scripts, then remove the build-time files
RUN chmod +x /scripts/*.sh && /scripts/*.sh
RUN rm -rf /scripts /packages

This approach makes it easy to build a container that includes exactly what you need, without modifying the host system.

I also wanted an Arch-based environment with Chaotic-AUR and paru, so I created a second image for that workflow:

FROM quay.io/toolbx/arch-toolbox:latest

LABEL com.github.containers.toolbox="true" \
    name="arch-chaotic-toolbox" \
    version="latest" \
    usage="This image is meant to be used with the toolbox or distrobox command" \
    summary="Arch Linux Toolbox with Chaotic-AUR and paru" \
    maintainer="Pratyay Mustafi <pratyaymustafi@outlook.com>"

# Copy setup scripts and package lists
COPY scripts/ /scripts/
COPY packages/ /packages/

# Run the Chaotic-AUR setup script, then remove the build-time files
RUN chmod +x /scripts/*.sh && /scripts/chaotic.sh
RUN rm -rf /scripts /packages

A Simple Layout of the file structure.

A project like this can stay clean and easy to maintain if it follows a simple layout:

.
├── .github
│ └── workflows
│ ├── build.yml
│ └── clean-runs.yml
├── .gitignore
├── ContainerFiles
│ ├── brew
│ └── chaotic
├── LICENSE
├── README.md
├── packages
│ ├── brew.packages
│ └── chaotic.packages
└── scripts
    ├── brew.sh
    └── chaotic.sh

This structure keeps each concern separated:

scripts/ contains the setup logic
packages/ contains package lists
ContainerFiles/ stores the image definitions
README.md explains how to build and use the environment

That keeps the workflow organized and easier to extend later.

Example Package List

For the Arch-based image, the package list can be as simple as this:

devel
git
paru

This is nice because package changes are declarative. If I need to add a tool, I can update the package list and rebuild the image whenever I need a new dependency or a different tool chain.

Setting up Chaotic AUR based toolbox

For Arch-based work, I also wanted a clean way to configure Chaotic AUR and install the packages I use most often. The setup script below does just that:

#!/usr/bin/env bash
set -euo pipefail

echo "==> Configuring Chaotic AUR repository..."
pacman-key --init
pacman-key --recv-key 3056513887B78AEB --keyserver keyserver.ubuntu.com
pacman-key --lsign-key 3056513887B78AEB
pacman -U --noconfirm 'https://geo-mirror.chaotic.cx/chaotic-aur/x86_64/chaotic-keyring.pkg.tar.zst'
pacman -U --noconfirm 'https://geo-mirror.chaotic.cx/chaotic-aur/x86_64/chaotic-mirrorlist.pkg.tar.zst'
sed -i 's|^Server = https://cdn-mirror.chaotic.cx|# Server = https://cdn-mirror.chaotic.cx|' /etc/pacman.d/chaotic-mirrorlist
printf '\n[chaotic-aur]\nInclude = /etc/pacman.d/chaotic-mirrorlist\n' >> /etc/pacman.conf

echo "==> Installing packages from chaotic.packages..."
grep -v '^#' /packages/chaotic.packages > /tmp/chaotic.pkglist
if [! -s /tmp/chaotic.pkglist]; then
    echo "chaotic.packages is missing or empty" >&2
    exit 1
fi
xargs pacman -Syu --needed --noconfirm < /tmp/chaotic.pkglist
rm -f /tmp/chaotic.pkglist
rm -rf /var/cache/pacman/pkg/*

echo "==> Configuring toolbx permissions..."
echo "%wheel ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/toolbox
chmod 0440 /etc/sudoers.d/toolbox

This keeps the setup steps reproducible and easy to manage. If the Arch repository or package list changes, the update is straightforward.

Why This Workflow Works So Well

This pattern has several practical advantages:

Reproducible builds : the environment is defined in code
Portability: the same image can be built elsewhere
Isolation: dependencies stay inside the container instead of the host
Speed: no repeated manual package setup
Simplicity: the environment is easier to debug and maintain.

It is a great fit for package maintenance, Linux tooling, custom formula work, and any development workflow that depends on a specific tool chain.

Toolbox/Distrobox gives you a flexible middle ground: you get the isolation of a container without losing the convenience of working closely with your host environment.

If you work with Linux tooling, package building, or want reproducible dev setups, this is a workflow with toolbox container based development is worth adopting. Source code on GitHub.


toolbox container type	image link
brew-toolbox	quay.io/pratyay360/brew-toolbox:latest	docker.io/pratyay360/brew-toolbox:latest	ghcr.io/pratyay360/brew-toolbox:latest
chaotic-toolbox	quay.io/pratyay360/chaotic-toolbox:latest	docker.io/pratyay360/chaotic-toolbox:latest	ghcr.io/pratyay360/chaotic-toolbox:latest
android-toolbox	quay.io/pratyay360/android-toolbox:latest

Releasing tools on different channels with goreleaser

PRATYAY MUSTAFI — Mon, 05 Oct 2026 11:23:00 +0000

Creating a CLI tool is easy, compared to distributing it

Goreleaser makes publishing almost a cake walk, but it comes with a steep learning curve. Still, distribution is just as important as the product itself. Shipping your tool as standalone binaries isn’t enough. reaching users through established channels matters It increses your tool’s reputation and gives a free visibility. Like for macOS, there’s Homebrew, now a days many Linux distributions are promoting it, brew is backed by a large community. Similarly, Winget and Scoop are important distribution channels. Being available through these channels brings significantly more visibility and ease of use.

By the way, GoReleaser is a publishing automation tool, and it’s not exclusive to Go, one can build and distribute apps written in many languages like Go, Zig, Rust, Typescript and more.

Let’s first learn about different types of package managers before publishing there.

homebrew.

Brew is generally maintained by the community and formulas are mostly written in Ruby :).

So do you have to learn ruby to publish on homebrew?

The answer is no, you don’t. goreleaser covers everything for you.

You can create an empty GitHub repo named homebrew-tap or any other name with a homebrew- prefix. the prefix is recommended

gh repo create user1/homebrew-tap --public

brew new-tap user1/tap

brew install gh git

What is tap?

A tap is a repository with some recipes that brew needs to follow to install a tool. recipe is, in the sense, a formula to install a tool the repo user1/homebrew-tap will be reffered as user1/tap while using.

On the other side you can make a repo like user1/homebrew-cli –> user1/cli (tap).

scoop?

Scoop is a command line installer for Windows. Think of it as the Windows equivalent of Homebrew, but with its own flavor. To distribute your tool via Scoop, you’ll need to create a “bucket.” A bucket is basically Scoop’s version of a tap, a repo with the name scoop-bucket is suggested.

gh repo create user1/scoop-bucket --public
scoop bucket add bucket-name <https://github.com/user1/bucket-name> ## adding a bucket to scoop
scoop install bucket-name/your-tool ## installing your tool from the bucket

Creating a Scoop bucket is straightforward:

Winget

Now, Winget is Microsoft’s official package manager for Windows built into the operating system.

The process here is a bit different. Instead of creating a new repo you have to fork the main repo,

~~and then create a new branch for your tool~~ you don’t have to do this thing manually goreleaser handles that for you.

Winget do’s and don’ts

There are a few things to keep in mind:

one tool = one branch,

you can’t submit multiple tools in one branch as the pr is for tracking the changes of a single tool, goreleaser automates this process too.

Generally, Linux users are techy so they are more likely to install .deb and .rpm packages, as well as tools like eget, And the thing with go as a language is that it includes all the necessary C libraries in the binaries so it can be runned by just putting in $PATH on any machine.

the process generally is like you have to create/modify a file in other repo. But github-actions only gives your workflow access to that repo only

create a PAT (personal access token) with scopes read, write, releasing, files, repos, actions, action-metadata etc, and add it to your repo secrets. then you can use that token in your workflow to access other repo.

Remember you can’t create any variable with GITHUB_ prefix in the secrets, so you have to use a different name for your secret like PAT.

to create a release, you have to create a numeric tag only as winget refuses to accept alphanumeric tags.

like,

1.1.1
0.1.2-1

tags can be created using

git tag 1.1.1
git push -u origin 1.1.1

## if you use jj then 

jj new # stage changes

jj desc # describe changes

jj bookmark advance main # advance bookmark main to the new staged state.

jj tag set 1.1.1

jj git push --all #or 

jj git push --tag 1.1.1

If you have followed my previous post on doing ci with mise

then read that post first as I am going to use the same approach here. Also I am assuming you are already using mise on your machine. goreleaser is available on mise, so you can install it using mise use goreleaser@latest.

To getting started, you have to generate a goreleaser config file using goreleaser init command. It will create a .goreleaser.yml file in your repo. You can modify it according to your needs. For detailed info please refer to the official documentation.

name: build and release
on:
  push:
    tags:
      - '*'
  workflow_dispatch:

permissions:
  contents: write
  pages: write
  id-token: write

jobs:
  ci:
    runs-on: ubuntu-latest
    container:
        image: ghcr.io/jdx/mise:2026.8.16
    steps:
      - name: checkout code
        uses: actions/checkout@main
        with:
          fetch-depth: 0
      - name: Trust git directory in container
        run: git config --global --add safe.directory '*'

      - name: Install dependencies & building
        run: |
            mise deps
            mise fetch
            mise run release
        env:
          GITHUB_TOKEN: ${{ secrets.PAT }}
          MISE_EXPERIMENTAL: true

mise.toml

[tools]
go = "latest"
goreleaser = "latest"

[deps]
go = { auto = true }

[tasks]
fetch = { description = "Fetch Go module dependencies", run = "go mod download" }
testcase = { description = "Run Go testcase", run = "go run ./test/test.go" }
build = { description = "Build Go binary", run = ["mise deps", "mise run fetch", "goreleaser build --snapshot --clean"] }
test = { description = "test binary", run = ["mise deps", "mise run testcase", "mise run build"] }
testcases = { description = "Run Go test cases", run = "go test ./..." }
release = { description = "Build and release using Goreleaser", run = "goreleaser release --clean" }

So I had composed the .goreleaser.yml file for ensor it should look like this.

# yaml-language-server: $schema=https://goreleaser.com/static/schema.json
version: 2

project_name: ensor

before:
  hooks:
    - go mod tidy
    - go generate ./...

builds:
  - id: ensor
    main: .
    binary: ensor

    env:
      - CGO_ENABLED=0

    goos:
      - linux
      - windows
      - darwin
      - freebsd
      - openbsd

    goarch:
      - amd64
      - arm64
      - "386"

    ignore:
      - goos: darwin
        goarch: "386"

    flags:
      - -trimpath

    ldflags:
      - -s -w -X github.com/Pratyay360/ensor/cmd.version={{.Version}}

archives:
  - id: default
    ids:
      - ensor

    formats:
      - tar.gz

    name_template: >-
      {{ .ProjectName }}_
      {{- title .Os }}_
      {{- if eq .Arch "amd64" }}x86_64
      {{- else if eq .Arch "386" }}i386
      {{- else }}{{ .Arch }}{{ end }}
      {{- if .Arm }}v{{ .Arm }}{{ end }}

    format_overrides:
      - goos: windows
        formats:
          - zip

checksum:
  name_template: checksums.txt

changelog:
  sort: asc
  use: github

  filters:
    exclude:
      - "^docs:"
      - "^test:"

  groups:
    - title: Features
      regexp: "^feat"
      order: 0

    - title: Bug fixes
      regexp: "^fix"
      order: 1

    - title: Others
      order: 999

nfpms:
  - id: packages
    package_name: ensor
    description: "Censor secrets from your codebase"
    homepage: "https://github.com/Pratyay360/ensor"
    maintainer: "Pratyay360 <pratyaymustafi@outlook.com>"
    license: Apache-2.0

    formats:
      - deb
      - rpm
      - apk

homebrew_casks:
  - name: ensor
    homepage: "https://github.com/Pratyay360/ensor"
    description: "Censor secrets from your codebase"
    license: Apache-2.0

    binaries:
      - ensor

    generate_completions_from_executable:
      executable: ensor
      args:
        - completion
      base_name: ensor
      shell_parameter_format: cobra
      shells:
        - bash
        - zsh
        - fish

    directory: Casks
    commit_msg_template: "Brew cask update for {{ .ProjectName }} version {{ .Tag }}"

    repository:
      owner: Pratyay360
      name: homebrew-tap
      branch: main
scoops:
  - name: ensor
    homepage: "https://github.com/Pratyay360/ensor"
    description: "Censor secrets from your codebase"
    license: Apache-2.0
    commit_msg_template: "Scoop update for {{ .ProjectName }} version {{ .Tag }}"

    repository:
      owner: Pratyay360
      name: scoop-bucket
      branch: main

winget:
  - name: winget
    publisher: Pratyay360
    publisher_url: "https://github.com/Pratyay360"
    publisher_support_url: "https://github.com/Pratyay360/ensor/issues"
    package_identifier: pratyay360.ensor
    short_description: "Censor secrets from your codebase"
    description: "A unified CLI for censoring secrets from your codebase"
    license: Apache-2.0
    homepage: "https://github.com/Pratyay360/ensor"
    commit_msg_template: "{{ .PackageIdentifier }}: {{ .Tag }}"

    repository:
      owner: Pratyay360
      name: winget-pkgs
      branch: ensor # branch name should be your tool name. for easy navigation later on.

release:
  github:
    owner: Pratyay360
    name: ensor

snapshot:
  version_template: "{{ incpatch .Version }}-next"

for other tech stack you can use make or just or mise.

I am yet to explore aur as they have stopped registration and haven’t seen any literature on conda forge so have to try this later on (maybe content for a new post), Also creating a custom coppr repo or ppa to distribute tool is tbd.

LightCMS: Writing, Without the Fuss

PRATYAY MUSTAFI — Mon, 28 Sep 2026 14:17:49 +0000

LightCMS: A CMS That Encourages You to Write Again

You picked a static site generator because you wanted something fast, clean, and lightweight. But somewhere between Hugo, Git, CI/CD pipelines, and VS Code extensions, “writing a blog post” turned into a technical project and the motivation to actually share what you know got lost in the process.

LightCMS fixes that.

It’s a self hostable, open-source headless git backed CMS built specifically for static sites wrapped in a gorgeous editor. The goal of lightcms is to encourage you as a writer.

How It Works

Your content still lives in GitHub. Your CI/CD still builds and deploys it automatically. Nothing about your existing static-site setup changes under the hood — LightCMS just removes the need to touch Git, Markdown syntax, or front matter schema to use it.

Why It’s Different

Encouraging as a hobby. LightCMS is built with a single goal to make writing enjoyable again.
Built for writing: LightCMS tries to provide an experience that the entire process feels as pleasant and friction less as possible
Copilot: Lightcms comes with a copilot inbuilt and there is also a dictation plugin to make your experience of sharing knowledge smooth.
Lighter on the planet. Static sites are already one of the most eco friendly ways to publish content and light cms aids managing content for static site generators.

See It Live

LightCMS is live on lightcms.me

and the github repo is https://github.com/Pratyay360/lightcms

Everyone has something worth writing and sharing about a lesson learned, a project shipped, a bug that took three days to fix. LightCMS exists so that the tooling never gets in the way of sharing that experience.

Generate UPI QR Codes Dynamically on Any Device with upiqrcode

PRATYAY MUSTAFI — Mon, 28 Sep 2026 06:39:18 +0000

Generate secure, NPCI compatible UPI payment QR codes directly in the browser using Rust and WebAssembly.

Introducing upiqrcode

What if you could generate a UPI payment QR code instantly, on any device, without sending payment details to a server?

Meet upiqrcode — an open-source WebAssembly (WASM) library that generates UPI payment intent links and renders them as vector SVG QR codes, entirely on the client side.

Whether you’re building a payment page, a small business checkout, a donation flow, or a personal payment tool, upiqrcode makes it easy to generate dynamic UPI QR codes directly in the browser.

No backend round trips. No unnecessary data collection. Just fast, local QR code generation.

What Is Dynamic UPI?

UPI (Unified Payments Interface) has made digital payments incredibly accessible across India. From small street vendors to large online businesses, UPI QR codes have become a convenient way to receive payments.

A dynamic UPI QR code contains a payment intent that can include details such as:

UPI ID: The recipient’s Virtual Payment Address (VPA).
Payee name: The name displayed in the payment app.
Amount: An optional, predefined payment amount.
Transaction note: A short description of the payment.
Transaction reference: An optional identifier for the transaction.

When someone scans the QR code using a compatible UPI app — such as PhonePe, Google Pay, Paytm, or BHIM — the app can read the payment details and prefill the payment screen.

The user reviews the information and confirms the payment in their UPI app.

With upiqrcode, these payment details can be turned into a QR code dynamically, without requiring a server to generate the image.

How Does upiqrcode Work?

The core idea behind upiqrcode is simple: move QR generation to the device instead of relying on a remote service.

The library is written in Rust and compiled to WebAssembly. The resulting WASM module runs inside the browser, allowing the application to construct a UPI payment URI and generate a vector SVG QR code locally.

Here’s the typical workflow:

1. Enter the payment details

Provide the recipient’s UPI ID and payee name.

For example:

UPI ID: success@upi
Payee name: Example Store
Amount: 150.00
Transaction note: Order payment

2. Generate the payment intent

The library constructs a UPI payment URI using the supplied details.

3. Render the QR code

The WASM module generates a QR code that can be rendered as an SVG. Since SVG is a vector format, the QR code can scale to different screen sizes without becoming blurry.

4. Scan or open the payment app

The generated QR code can be scanned by a compatible UPI app. An application may also offer an Open in App action to launch a compatible payment handler where supported.

The payment itself is completed through the user’s chosen UPI app — generating the QR code does not initiate or authorize a payment.

Why Rust and WebAssembly?

Using Rust and WebAssembly makes it possible to run the QR generation logic efficiently in the browser.

Here are some of the key benefits.

1. Client-Side Performance

QR generation happens locally, eliminating the need to send a request to a backend just to create a QR code.

This makes the workflow lightweight and responsive.

2. Privacy by Design

Payment details can remain on the user’s device during QR generation.

Because the library does not need a server to construct the QR code, there is no need to transmit the recipient details or payment amount to a remote QR-generation service.

Actual privacy also depends on how the surrounding application is built, including its analytics, logging, and network requests.

3. Cross-Platform Compatibility

WebAssembly enables the compiled library to run in supported browser environments across desktop and mobile devices.

That means developers can integrate the same core generation logic into different web applications without implementing the entire QR-generation process separately for every platform.

4. Crisp, Scalable SVG Output

SVG QR codes are useful for web interfaces, printable receipts, invoices, and payment pages.

They can be resized while maintaining their vector quality, making them suitable for both small mobile screens and larger displays.

Understanding the UPI QR Code Format

At its core, a UPI QR code encodes a payment intent URI.

A simplified example looks like this:

upi://pay?pa=success%40upi&pn=Example%20Store&am=150.00&cu=INR&tn=Order%20payment

The URI contains the information that a compatible UPI application uses to populate the payment screen.

Supported Payment Parameters

ParameterDescriptionRequired?paPayee's UPI ID (VPA)YespnPayee nameYesamPayment amountOptionalcuCurrency, typically INROptionaltnTransaction noteOptionaltrTransaction reference IDOptional

Note: This is a simplified representation. Implementations should follow the applicable UPI intent specification and validate parameters according to their intended use.

QR Data Fields

The application can work with structured data before constructing the payment URI.

For example:

payeeVPA — the recipient's UPI ID.
payeeName — the recipient's display name.
amount — the requested payment amount, if specified.
currency — the currency code, typically INR.
transactionNote — an optional description of the payment.
transactionId — an optional unique transaction reference, where supported by the implementation.

The exact data structure depends on the library’s API, but the goal is the same: accept payment details, construct a valid intent URI, and encode that URI into a QR code.

What Happens When Someone Scans the QR Code?

The process is straightforward:

The QR scanner reads the encoded upi://pay URI.
The compatible UPI application parses the payment parameters.
The payment screen displays the available recipient and transaction details.
The user reviews the details and authorizes the payment through the app.

Where Can You Use Dynamic UPI QR Codes?

Dynamic QR generation is useful in several scenarios.

E-commerce checkout: Generate a QR code with the order amount already filled in.

Small businesses: Display payment QR codes for individual purchases without manually creating a new image each time.

Donations and fundraising: Include a predefined amount or a descriptive transaction note.

Invoices and receipts: Embed payment QR codes directly into generated documents.

Personal payment tools: Share a QR code with a recipient and optional payment details.

Web applications: Integrate QR generation into browser-based applications without operating a dedicated QR generation API.

For payment verification, the responsible party must have an escrow account in place to receive and process webhooks from banks.

Privacy and Security Considerations

Keeping QR generation on the client side is a useful privacy advantage, but it is important to understand what it does — and does not — protect.

Payment details used to generate the QR code can stay in browser memory.
A back end is not required solely for constructing the QR image.
The library does not itself authorize a payment or move money.
The receiving UPI app remains responsible for presenting the payment details and obtaining user confirmation.

The Bigger Picture

upiqrcode demonstrates how WebAssembly can make browser-based utilities more capable without adding unnecessary infrastructure.

By combining Rust’s performance, WebAssembly’s portability, and SVG’s flexibility, it provides a practical approach to generating UPI payment QR codes directly on a user’s device.

For developers building payment interfaces, this means one less server-side operation to maintain — and a simpler way to keep QR generation local.

Final Thoughts

Dynamic UPI QR codes are a small feature that can make payment experiences much smoother.

With upiqrcode, developers can generate UPI payment intent links and vector QR codes directly in the browser, customize payment details, and integrate the results into a variety of applications.

The most interesting part is not just generating a QR code. It’s doing so with a lightweight, privacy-conscious architecture powered by Rust and WebAssembly.

If you’re building tools around UPI payments, upiqrcode is worth exploring.

Explore the project, try it in your application, and build something useful with it.

There is a website demonstrating upiqrcode you can check this out.

Originally published at pratyay.online.

Newsletters Should Live Next to Your Code — Not in any Database

PRATYAY MUSTAFI — Mon, 28 Sep 2026 05:59:40 +0000

newsy

Hello, Internet! 👋

I’m excited to introduce newsy
— a newsletter service for your static site, powered by GitHub Issues.

If you’re reading this, you probably know the projects that inspired it: Utterances , Giscus , and Gitalk. These projects completely reimagined commenting on static sites by using GitHub Issues as a backend. No database, no CMS, no vendor lock-in — just your repo and a little embed script.

Newsy takes that same idea and applies it to newsletters.

Think about it. Instead of signing up for a traditional email marketing service, maintaining a separate mailing list, or paying monthly for a newsletter platform you barely use, your newsletter can simply live alongside your code in a GitHub repository.

That’s the core idea behind Newsy: democratizing newsletter services.

We wanted to strip away the overhead of traditional platforms — the dashboards, the pricing tiers, the data you don’t own — while keeping everything close to the tools you already use and love.

Your blog is static. Your comments are GitHub Issues. Why shouldn’t your newsletter be too?

DEV Community: PRATYAY MUSTAFI

Lightcms: A CMS that allows you to rediscover the writer Within You ✍️

newsy a free to use zero hastle newsletter platform for your static sites powered by github.

GitHub: Enable Newsletter Using newsy Widget.

[Boost]

GitHub: Enable Newsletter Using newsy Widget.

GitHub: Enable Newsletter Using newsy Widget.

light-cms / newsy

github backed newsletter platform for your static site

✨ Features

🎬 Demo

🚀 Quick start

Why Your Tauri based appImage not working on Linux (And How to Fix It)

Tauri Apps Built as Appimages are not working on modern linux distributions, like fedora, arch

How to Fix This ?

And Change a Little Thing in the Existing Workflow

Replace All tauri build Commands With tauri build && source src-tauri/scripts/patch-appimage-wayland.sh

Making Tauri Apps Packaged as AppImages Usable Again

Tauri Apps Built as Appimages are not working on modern linux distributions, like fedora, arch

How to Fix This ?

And Change a Little Thing in the Existing Workflow

Replace All tauri build Commands With tauri build && source src-tauri/scripts/patch-appimage-wayland.sh

Mastering Toolbx Containers: A Guide to Frictionless Linux Development

Why Toolbox?

Defining Your Own Development Environment

A Simple Layout of the file structure.

Example Package List

Setting up Chaotic AUR based toolbox

Why This Workflow Works So Well

Create Your Own Specialized Toolbox Containers for Development

Why Toolbox?

Defining Your Own Development Environment

A Simple Layout of the file structure.

Example Package List

Setting up Chaotic AUR based toolbox

Why This Workflow Works So Well

Releasing tools on different channels with goreleaser

Creating a CLI tool is easy, compared to distributing it

So do you have to learn ruby to publish on homebrew?

What is tap?

Winget do’s and don’ts

the process generally is like you have to create/modify a file in other repo. But github-actions only gives your workflow access to that repo only

mise.toml

LightCMS: Writing, Without the Fuss

LightCMS: A CMS That Encourages You to Write Again

How It Works

Why It’s Different

See It Live

Generate UPI QR Codes Dynamically on Any Device with upiqrcode

Introducing upiqrcode

What Is Dynamic UPI?

How Does upiqrcode Work?

Why Rust and WebAssembly?

1. Client-Side Performance

2. Privacy by Design

3. Cross-Platform Compatibility

4. Crisp, Scalable SVG Output

Understanding the UPI QR Code Format

Supported Payment Parameters

QR Data Fields

What Happens When Someone Scans the QR Code?

Where Can You Use Dynamic UPI QR Codes?

Privacy and Security Considerations

The Bigger Picture

Final Thoughts

Newsletters Should Live Next to Your Code — Not in any Database

Replace All `tauri build` Commands With `tauri build && source src-tauri/scripts/patch-appimage-wayland.sh`

Replace All `tauri build` Commands With `tauri build && source src-tauri/scripts/patch-appimage-wayland.sh`