DEV Community: PRATYAY MUSTAFI

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.

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

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.

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?

Project Newsy

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

Introducing Newsy: A Newsletter Platform Powered by GitHub Issues

Newsy is a newsletter platform inspired by projects like Utterances, Giscus, and Gitalk projects that reimagined commenting on static sites by using GitHub Issues as the backend.

Newsy takes the same idea and applies it to newsletters.

Instead of relying on a traditional email marketing service, maintaining a separate mailing list, or paying for SMTP APIs, your newsletter can live alongside your code in a GitHub repository.

Newsy is built around a simple idea: creating a newsletter should never be a complicated thing.

It aims to remove much of the overhead that comes with traditional newsletter platforms while keeping everything close to the tools developers already use.

Here’s a quick demo:

https://youtu.be/sfjo6ZVgC9w?si=RMeu6YWOWwOhn8q9

Making your own operating system with bootc

PRATYAY MUSTAFI — Thu, 24 Sep 2026 18:03:00 +0000

Containerizing web applications is standard practice these days, but deploying your entire operating system as a container image fundamentally changes how you interact with and manage your system. If you have been exploring the cloud-native ecosystem, you have likely heard of the bootc and ostree projects. But what exactly do they do, and why should you care?

First, let’s talk about what bootc is ?

Bootc (bootable containers) fundamentally changes how we operate our OS. Instead of just spinning up containers on top of a traditional host, you practically boot into and live inside one.

Operating systems built this way are inherently immutable , meaning you cannot write directly to the root directory (/). While this might sound restrictive at first glance, it provides massive advantages for system security, predictability, and stability.

Why an immutable, container centric OS?

A bootc based OS gives you very little headroom to break your system. It is not a drill you tried some tinkering with and suddenly the system refuses to boot. If you were still able to break it, no worries — because your system treats itself as a version-controlled system:

Atomic upgrades: Updates download in the background and unpack in parallel to the running system without interrupting your work. It is either successful or failed — no in-between state.
Instant rollbacks: If a bad update or regression ever slips through, you can instantly roll back to the previous working deployment with a simple reboot.

There are also excellent templates and tooling built around bootc, such as BlueBuild, which has a fantastic community. Because your OS is essentially a container image, you can customize it, build, and distribute it via a container registry.

Creating and Sharing Custom ISOs

Building your own container image is straightforward, but what if you want to use it on your machine? You can’t directly install a container image on a new system.

Should you be re-basing to your image after installing CoreOS? No — then why write recipes to mend your own OS?

BlueBuild gives you an option to generate your own ISO files with blue-build generate-iso, but creating that on your machine is a lot of work. So we are going to delegate that to GitHub Actions, but there remains a catch: GitHub allows release assets up to 2 GB per file, which is often too small for full OS ISOs.

Alternative storage options include object storage like S3, but there is an egress ingress cost associated, and paying money for a small hobby is a big no-no. Services like Gofile.io can be great options for storing and sharing ISO files.

Be gentle with GitHub-hosted runners — the whole process can be computationally expensive

Here is an example of my resource consumption:

GitHub Actions Workflow Run

You can check out the repository building these ISOs here: Pratyay360/blueee-os.

Recommended Base Images for Customization

If you are looking to start building your own custom bootc images, here are popular upstream base image registries:

Distribution	Base Image Registry
Fedora	fedora-ostree-desktops
AlmaLinux	almalinuxorg
CentOS Stream	centos-bootc

I have automated most of my social media accounts for free.

PRATYAY MUSTAFI — Sat, 19 Sep 2026 11:07:00 +0000

Recently, I have started writing blogs as a hobby to discipline myself about building a habit which is consistent

However, writing is only half the battle. As the saying goes, “If people don’t know your product exists, they can’t judge its value.”

To seriously grow, and sharing whatever I do with a wider audience is essential.

But who is my target audience?

People who are curious about technology and are accustomed to read articles.  
These specific requirements make my target audience quite niche,  
Which limits my choices of social media platforms even more limited.  
To keep people informed about my work, I can use microblogging platforms like (X twitter/threads/blue sky/ mastodon) and LinkedIn.

But writing 10 different post on 10 different platforms is a lot of work, and I am not into that.

Also, as programmers, we tend to be “lazy” as we hate repetitive tasks,

also on the other side we love doing overengineering to solve simple problems.

Here is what I have so far:

A blog website built with a Static Site Generator (SSG).
An automatically generated RSS feed (handled automatically by the SSG).
A Cronjob to check for new posts.

First I have had planned to use some action runners on schedule like github actions, to check and trigger based on rss feed, but after I started, going through the different developer sections, I felt that’s not worth my time as some one has already done so.

So, Why reinvent the wheel when there are already some good solutions available.

Exploring automation solutions:

~~iftttt.com (This is free on paper only , and unusable )~~
zapier.com (Very limited free plan, but at least allows performing basic automation for free)
windmill.com (cloud: Very limited free plan, Can be self hosted)
make.com (free plan isn’t very limited and this is the simplest solution I have found so far)

So, I will be using make.com but how to use make.com to automate my social media posting?

X (twitter) api used to be free but that’s now paid so using official API dropped. ❌
For threads. though it’s free but platforms are yet to integrate it.
mastodon is free to use in most of the platforms
same for Blue sky but it isn’t free on zapier .

I have only found make.com to be a better suited automation platform even for free users

It barely restricts any core features .

But the only problem with them is low monthly credits, 1000 for an entire month.

And similar to Deterministic Finite Automata, here each step consumes 1 credit no matter failed or not.

But why am I telling you all of this and how is this free. Also will you be posting on such unsupported social media platforms manually ?

Answer is no. You don’t as we are going to use buffer.

Buffer is a social media aggregator and management platform which can manage upto 3 accounts for free

Twitter asking money hell no ❌ I am going to automate with buffer .

And make.com allows you connect upto 3 actions in a chain.

If you have used my affiliate link for make.com, they have told me that they will give all the users 10,000 credits for free which is their pro plan for the first month.

Buffer is generous enough to allow you to connect 3 social media accounts and post on them for free. but you can mostly post 10 posts per day on free plan which is more than enough for me.

So you can hook 3 accounts to buffer and two on make.com.

My workflow consumes 4 credits on each run and such that, you get about 8 runs a day. 4×30×8

so if executions happen at an interval of 3 hrs you will not be exhausting the free limits.

For your reference I am sharing Images of buffer and Make.com dashboard

Untitled1

Untitled

Untitled2

Untitled3

Visit make with my referral link. (for 1st month free pro)

All this for absolutely free and with no credit card requirement.

Navigating around bootc and immutable/atomic distros

PRATYAY MUSTAFI — Thu, 17 Sep 2026 18:28:00 +0000

So, as you all know I have been a Linux user for the past 5-6 years.

And have installed os 100s of times on my system because of kernel panics or some bad driver bricking my machine, this made me an avid distro hopper.

As I have already written about the approx timeline of my distro hopping, I’m not going to repeat it here.

I personally loved KDE Plasma, and its look and feel overall. The simplicity and customization options are something I loved the most

And Fedora has the best experience with KDE Plasma.

And for the past 1 - 1.5 years, topics related to DevOps, like KVM, docker-compose, and reproducible builds, sparked curiosity in me. I got a bit deep digging into containerization, and how containerization works with namespaces and cgroups is very interesting. Though Docker has become synonymous with containers itself. But all the container runtimes follow OCI specs (Open Container Initiative) .

Podman

Podman is a daemonless container runtime. This means Podman just runs the service and vanishes from the entire process tree; unlike containerd or Docker, we don’t need to run a containerd or dockerd daemon. With Docker, running killall docker /containerd just stops all your running containers by default.

Podman is specifically impressive because of its rootless nature. One can run any number of containers as an unprivileged user and perform privileged operations within the container, similar to a fake-root environment. Btw, this is the exact same approach used in tools like rootlesskit, very similar to ports in FreeBSD, or MacPorts on Apple.

Podman doesn’t run persistently on your system, making it incredibly memory efficient.

The toolchain is practically identical to Docker; you can use podman build, podman run, podman push, etc.

Furthermore, Podman’s build tool, Buildah, is noticeably faster, making it preferable for building images quickly and efficient specially in CI/CD environments.

I probably don’t need to give a re-introduction to containers; you already know that if you’re here.

Tools like Toolbox or Distrobox just utilize this exact approach of unprivileged containers sharing the host’s user space, specifically mounting

$HOME (like /home/user/).

TBH, I personally love the philosophy behind OSTree-based operating systems: the idea of atomic updates, either successful or failed, is the exact same reason making os tree virtually unbreakable.

The concept of layering here is brilliant. The base image is immutable, and any system changes are stored in a separate layer. This makes it incredibly easy to roll back to a previous state if something gets messed up. It gives you an unbeatable safety net, and the logic is identical to how standard OCI container images are layered.

But layering packages onto the host OS isn’t always the ideal thing to do. The best approach is to use a Toolbox container for installing and running your day-to-day apps.

You can create a random Toolbox container and install any app you want. No matter how many containers you spin up, if their base image is the same, they will share that underlying image and won’t cost you extra gigabytes in storage. Sharing that base layer saves disk space and makes managing multiple environments effortless.

But aren’t containers bloated? Don’t they cost you a lot of storage space (the container tax)? The answer is both yes and no. Yes, it does cache a lot of data, but the benefits are well worth the trade-off. You get a super solid base OS while keeping the flexibility of other distros. I’ve installed paru (the Arch User Repository helper) inside a Toolbox container, installed .deb and .rpm packages, and things just work.

Distrobox or Toolbox?

I want something easy. I don’t want to type toolbox enter every time I need to run a basic app.

As I’ve mentioned, Toolbox containers generally respect the host machine a bit more (plus PAM is shared with the host), but Distrobox is undeniably convenient because of the export feature like distrobox-export --app /usr/bin/ghostty and distrobox-export --bin /usr/bin/ghostty

But what if I share something that makes Toolbox just as convenient or better ?

curl -fsSL https://github.com/Pratyay360/toolbox-export/raw/refs/heads/main/install.sh | bash

Benefits of ostree ?

libostree or Ostree is like a version control system similar to git but for the entire os. It is a crucial component of your atomic distro. Either you update your machine reboot, update completes successfully or unsuccessfully.

Even after success, ostree based os can still rollback to the previous state if anything is not working. resetting your os back to previous commit just works. It’s too hard to mess with such a

resilient system. Specially if you are using, your own recipie to build os Though it’s hard to make a faulty container image. You can identify any flaws during the image build process.

So, is everything perfect with Toolbox containers?

Networking related apps like wireshark, airmon-ng etc etc. and drivers don’t play nice; I am yet to use installed in containerd , though script evaluation is fast. Also, I’ve noticed apps installed via Distrobox often fail to honour the system theme, on the other side Toolbox respects the system theme + apps share the same secret store, in my case it’s kde wallet, and the apps I have installed in Toolbox never made me feel like they are alien to my system.

What if I don’t want the prepacked apps that comes with Fedora can i modify without pinning?

What if I want to remove Konsole and use Ghostty as my default without layering & pinning it onto my host os? I’ve actually run Ghostty installed inside an Arch Linux Toolbx as my default terminal, and it felt 100% native.

If you want absolute control on what softwares should be available on os and what not, I highly suggest making your own customized bootc image. Believe me, it is as easy as sipping a cup of tea thanks to tools like Bluebuild or OSBuild and the community around it.

I personally have 3 to 4 Toolbox images running continuously on my system, containing most of my daily apps.

One containing everything development related like ides, editors.

One containing all the media and specially CLI tools in a arch based toolbox. and another just for testing my apps. All my web browsers are downloaded via the arch toolbox.

And a Debian based toolbox just for testing my apps. and I use that ephemerally.

asciicast

See the disk usage of my system by containers above.

By the way, I am a full stack developer. And I have a graveyard of dozens of late-night ideas, abandoned projects, and half finished stuffs. You can believe me when I say the storage utilized by those 10-15 project folders easily takes up 2 to 2.5x the amount of storage that all my containers do! and that’s just from npm’s node_modules only and rust, go cache is yet to look into.

Ensor, censorship for your codebase

PRATYAY MUSTAFI — Tue, 15 Sep 2026 20:32:46 +0000

Ensor: Censorship for Your Codebase

Detect it. Redact it. Keep the code readable.

Hardcoded secrets are one of those problems that looks simple until you're dealing with a real codebase.

API keys end up in HTTP collections. Tokens get copied into YAML files. Credentials sneak into examples, configuration files, test fixtures, or snippets that eventually find their way into Git.

Secret scanners are excellent at telling us that a secret exists.

Secret managers are excellent at telling us where secrets should live.

But there is an awkward step in between:

What do you actually do with the secret that is already sitting inside your code?

That's the problem I built Ensor to solve.

What is Ensor?

Ensor is a fast, interactive CLI for detecting and redacting secrets from your codebase, while also providing tools for managing environment-variable formats.

It is designed around a simple workflow:

Codebase
   ↓
Scan for secrets
   ↓
Identify the value
   ↓
Map it to a variable
   ↓
Replace the hardcoded secret
   ↓
Keep the code readable

By default, Ensor extracts discovered secrets into an environment file and replaces the values in your project with configurable placeholders.

So instead of this:

headers:
  Authorization: Bearer sk_live_xxxxxxxxxxxxxxxxx

you can end up with something like:

headers:
  Authorization: Bearer ${STRIPE_SECRET_KEY}

The important part is that the surrounding file remains readable.

The Missing Step in Secret Management

There are already excellent tools for different parts of the secret-management lifecycle.

Tools such as Gitleaks, TruffleHog, and betterleaks can help detect secrets.

Then there are tools and systems for actually managing secrets:

SOPS
Vault / OpenBao
Infisical
Bitwarden Secrets Manager
cloud secret managers
GitOps-oriented secret workflows

These solve different problems.

But detection often leaves you with a very manual task:

"Okay, we found the secret. Now go through the project and replace it everywhere."

That's the part Ensor focuses on.

It sits between secret detection and secret management.

The Problem That Started It

I wanted to keep my API requests and development configuration in Git.

For example, Bruno stores requests as .bru files, while many other API clients and development tools use YAML, JSON, TOML, or similar formats.

I wanted those files to remain useful when I wasn't sitting at my main machine.

That created an annoying choice.

Option 1: Encrypt everything

Using something like SOPS is great when you need encrypted files.

But encryption also means the file is no longer immediately readable.

Instead of opening a request and seeing:

method: GET
url: https://api.example.com/users
headers:
  Authorization: Bearer ...

you might first have to decrypt it.

Option 2: Manually remove the secrets

This works.

It is also exactly the kind of repetitive task people eventually forget to do.

And secrets don't only live in .env files.

They can appear inside:

API request collections
YAML configuration
JSON files
example code
shell scripts
test fixtures
documentation
generated files
random configuration files

That is where automation becomes useful.

How Ensor Works

Ensor is built around three main capabilities.

1. Scan and redact secrets

Run:

ensor

Ensor scans the current project for potential secrets and helps redact them.

The scanner is powered by the betterleaks detection engine.

Rather than simply reporting:

SECRET FOUND

Ensor turns the finding into an actionable workflow.

You can associate the detected value with a meaningful environment-variable name and replace the hardcoded value in the codebase.

2. Map existing environment variables

Suppose you already have:

STRIPE_SECRET_KEY=sk_live_xxxxxxxxx
DATABASE_URL=postgres://...
GITHUB_TOKEN=ghp_xxxxxxxxx

Ensor can use those values as a source of truth and find where they appear in your project.

Instead of manually searching for the raw values, Ensor can replace them with their corresponding variable names.

So this:

const token = "ghp_xxxxxxxxx";

can become:

const token = process.env.GITHUB_TOKEN;

The exact replacement depends on the file and workflow, but the goal is the same:

remove the secret while keeping the code useful.

3. Convert environment files

Ensor is not only a redaction tool.

It also includes:

ensor convert

for converting environment configurations between common formats.

For example:

.env
 ↓
JSON
 ↓
YAML
 ↓
TOML

This is useful when different tools expect different configuration formats.

You can keep one set of environment values and translate it when needed rather than manually rewriting the same configuration.

Why an Interactive CLI?

I deliberately didn't want Ensor to behave like another silent black-box scanner.

Secret remediation can be destructive.

A tool replacing values throughout a project should make it obvious what is happening.

That's why Ensor uses an interactive terminal interface.

It is built with Huh, Bubble Tea, and Lip Gloss.

The result is a workflow that lives in the terminal but still provides enough interaction to review what the tool is doing.

A Practical Workflow

A typical workflow might look like this:

cd my-project

ensor

Ensor scans the project and identifies potential secrets.

You can then map the discovered values to environment-variable names and let Ensor replace them in the relevant files.

Your Git diff becomes something closer to:

- Authorization: Bearer sk_live_xxxxxxxxx
+ Authorization: Bearer ${STRIPE_SECRET_KEY}

The important thing isn't the exact placeholder syntax.

It's that the source code remains understandable without embedding the credential itself.

Install Ensor

Using mise

mise use github:pratyay360/ensor@latest

Using Go

go install github.com/Pratyay360/ensor@latest

Using the install script

curl -sSL https://raw.githubusercontent.com/Pratyay360/ensor/main/install.sh | sh

Prebuilt binaries and packages are also available for Linux, macOS, Windows, and FreeBSD in the GitHub Releases.

See It in Action

Here's a short video demonstrating the CLI:

There are also interactive terminal demos:

And for environment conversion:

What Ensor Is — and Isn't

Ensor isn't intended to replace a proper secrets manager.

It also isn't a substitute for secret rotation after a credential has been exposed.

If a real credential has already been committed to a repository, the correct response is still to treat that credential as compromised and rotate or revoke it as appropriate.

Ensor addresses a different part of the workflow:

How do I remove secrets from the codebase without turning the code itself into an unreadable mess?

That's the gap I'm trying to fill.

What's Next?

Ensor is still evolving.

There are plenty of places where secret redaction can become smarter: better mappings, more file formats, improved replacement strategies, stronger integrations, and tighter development workflows.

The project is open source, so contributions, issues, and ideas are welcome.

Links

GitHub:
https://github.com/Pratyay360/ensor

License: Apache-2.0

Final Thought

Secret management is often presented as a binary problem:

secret or no secret.

In practice, there is a whole workflow around that secret.

You need to detect it.

You need to identify what it belongs to.

You need to remove it from the code.

And you need to keep the code usable afterwards.

Ensor is built for that middle step.

Censorship for your codebase.

setting up redirect rules in dns

PRATYAY MUSTAFI — Tue, 15 Sep 2026 11:35:00 +0000

How Google and Microsoft Handle Redirects

So how do Google/Microsoft-like companies handle the redirects we see and use on a daily basis?

The most notable one I can remember was Perplexity.in → redirecting users to Gemini. From a technical standpoint, how do you redirect to a completely separate DNS zone without any control over that zone? + How are TLS certs served in such a way?

Google’s domain resolves securely; parameters remain intact; browsers show no warnings.

All common HTTP request methods, such as GET, POST, DELETE, and PUT, can function correctly through proper redirection. However, to ensure that methods other than GET (such as POST, PUT, or DELETE) are preserved during a redirect, it is necessary to use HTTP status codes 307 (Temporary Redirect) or 308 (Permanent Redirect). These status codes instruct clients to repeat the original request method and body at the new location, thereby maintaining the integrity of the operation.

So how are they served? How is HTTPS/TLS handled? How do search engines handle these redirects, and how do they know that a domain is valid or an alternate destination for the original domain?

Don’t we need to tell the server, “Hey, this is your domain,” and store an A, AAAA, or CNAME record for it? How does the server know that this is a valid domain?

So here comes the role of your DNS provider and the way they handle redirections.

Setting up redirection via a DNS provider is straightforward: you point your subdomain to a local server range Cloudflare, for example, suggests using 192.0.2.1 paired with their proxy—and then create a rule within the provider’s dashboard to redirect all requests to the target domain.

When a user visits the subdomain, the request is routed to the local server, which then triggers the redirect to the destination. Note that this must be done using a subdomain because CNAME records cannot be assigned to an apex domain. Consequently, you can only redirect subdomains, such as “www” or any other custom prefix within that zone.

Types of redirections

google suggests some codes for redirections like 30* series.

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

305 Use Proxy

306 Unused

307 Temporary Redirect

308 Permanent Redirect

This ensures that search engines understand how to handle the redirection and how to process the old URL.

The approach is straightforward: configure your DNS records to point to the DNS server itself, then establish a rule with your DNS provider to redirect all requests to the target domain. Consequently, when a user visits your subdomain, the request is handled by the provider’s local server, which then issues a redirect to the target destination.

Cloudflare suggests utilizing their proxy feature to route requests through their servers, allowing them to handle redirections more effectively. I previously implemented a similar setup using freedns.afraid.org via their “web forward” feature, which successfully redirected traffic but only supported HTTP no HTTPS. In contrast, Cloudflare routes traffic through their extensive proxy network, they can issue TLS certificates and serve content securely over HTTPS.

Using chezmoi to manage dotfiles

PRATYAY MUSTAFI — Thu, 10 Sep 2026 20:45:00 +0000

CHEZMOI is a nice, modern, secure dotfiles manager with built-in support for handling secrets and provides a nice configurable/hackable ecosystem to tinker with. Chezmoi is a batteries-included dotfiles manager .

Unlike yadm, chezmoi doesn’t just create a git repo of your user space . Also, chezmoi supports integration with multiple password managers

Also, chezmoi is super nice with dotfiles. For example, .bashrc will be named as dot_bashrc

And if encrypted with chezmoi, it will be stored as encrypted_dot_bashrc.age

How to use age with chezmoi?

chezmoi age-keygen -o key.txt

chezmoi comes prepackaged with age. you just can run any age related command with just a chezmoi prefix

age ==> chezmoi age

and everything stays the same.

You can use chezmoi with age encryption with ssh, pgp, passphrase for recipient ..

I don’t recommend using a remote password manager to store secret values cz I have faced delay in shell startup due to slow internet or dns related issues.

$callout💡 Always remember AGE_ (in caps) is your private key and should be stored safely ..and the one age.. (in small) is your public key and we will be encrypting this to this public key as an recipient $

So, I am storing my secrets in plain text in my dot files isn’t that bad and will not chezmoi mess by leaking my secrets.

answer is yes and no .

1st you need to configure a chezmoi config

something like this:-

encryption = "age"
[git]
autoCommit = true
autoPush = true
[delta]
by-side = true
numbers = true
[age]
identity = "/home/<username>/.config/chezmoi/keys.txt"
recipient = "public age key here"

If you have added a file as encrypted chezmoi will remember that and always keep that encrypted remotely.

chezmoi add --encrypt ~/.profile

will be stored as encrypted_dot_profile.age

Re-tracking a file after manual edits

If you edited a file directly (instead of using chezmoi edit), that’s fine.

If you want, chezmoi to re track the file from your home directory into the source state, run:

chezmoi re-add

This will re-add the file according to your current config (including encryption rules), so the repo still only stores the encrypted version when applicable.

Doing ci/cd the easy way.

PRATYAY MUSTAFI — Wed, 02 Sep 2026 19:24:00 +0000

To Begin with I Would Love to reIntroduce You to My Favourite Cli Tool Mise

Mise is a version manager for dev tools & dependencies, a task runner, an environment variables manager all in one place. Mise ensures that every collaborator is working on the same environment and each every stage is reproducible.

In an earlier post, I have discussed, managing environment variables with mise . Today I will be discussing mise’s task runner feature.

For example, if you are using mise, then you can write task recipes to execute a particular job. One mise task can have multiple child subtasks.

Like:

[tasks.install]
description = "Install JS dependencies"
run = "nub install"

[tasks.build]
description="build project"
run = "nub run build"

[tasks.start]
description="start project in production env"
run = "nub run start"

[tasks.upload]
run = "surge ./dist test69.surge.sh"
description = "deploy the built dir on surge"

Btw surge is an awesome tool that deploys your static site for free on their CDN.

you can check them out: https://surge.sh

You can see basic tasks for a simple Node.js application. But you might ask, “How do I use this in CI/CD?”

The simple answer is:

With the help of mise as a task runner and with subtasks.

[tasks.ci]
description = "production build"
run = [
    mise run install
    mise run build
]

[tasks.deploy]
description="deploy project"
run = [
    mise run ci
    mise run upload
]

Whenever someone runs mise run ci, the output always stays deterministic, which you can test on your own machine. before pushing.

And Now a Question Arises: What If?

I’ve Written Something Wrong in Tasks Then Isn’t It the Same as Writing the Entire Pipeline?

The simple answer is no. Mise never allows you to ship an invalid configuration, plus you can always debug your tasks:

mise doctor

Safety?

Mise always checks and matches check-sums (SLSA) for each package downloaded. It’s generally suggested to not use “latest”, but to pin versions for example, node@24.03 or node@24.04.

And if you want to containerize the app before running it:

mise oci run

This will spin up a container for you containing the application. (This is not suggested for chunk blobs) you can move those build artifacts to some alpine linux or distroless container.

Want to Spin up a Devcontainer ?

mise gen devcontainer --write

Mise handles most of the things for you.

It’s up to you and your creativity on, how well you write task recipes. Personally, I prefer writing atomic tasks so each task stays debug able, manageable and reproducible.

Mise can handle shell scripts as tasks too, and you can use virtually any CLI tool thanks to its nice plugin ecosystem.

Let’s Stay on Our Main Topic: CI.

In any CI platform like GitHub Actions, GitLab Pipelines, Bitbucket Pipelines, Forgejo CI, or any custom CI one thing is always common in all, your ability to run containers and running commands inside it.

Want to write a GitHub Action?

mise gen github-action —write


name: ci

on:
  workflow_dispatch:
  pull_request:
  push:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

env:
  MISE_EXPERIMENTAL: true

jobs:
  ci:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v6
      - uses: jdx/mise-action@v3
      - run: mise run ci

But our goal isn’t to understand yaml for doing CI, but to simplify the process of writing CI pipelines. The goal is to simplify the process:

name: ci

on:
  push:
  workflow_dispatch:
  pull:

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

jobs:
  ci:
    runs-on: ubuntu-latest
    container:
        image: ghcr.io/jdx/mise:latest
    steps:
      - name: checkout code
        uses: actions/checkout@main

      - name: Install dependencies & building
        run: |
            mise deps
            mise run fetch
            mise run build

        env:
          SOME_ENV: ${{ secrets.SOME_ENV }}

      - name: Upload artifact
        uses: actions/upload-pages-artifact@main
        with:
          path: ./public

      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@main

For you, the basic structure of the pipeline stays the same always like some kind of like a boilerplate and the quest of one tab vs 4 spaces somehow becomes irrelevant. You can now focus on writing tasks and let mise handle the rest.

The fun part is that you can now run the same on any CI platform,

each will be giving you a predictable result

See a sample workflow for Forgejo Actions:

name: CI

on:
  push:
  pull_request:
  workflow_dispatch:

env:
  MISE_EXPERIMENTAL: true

jobs:
  check:
    name: Check
    runs-on: codeberg-medium-lazy
    container:
      image: ghcr.io/jdx/mise:latest

    steps:
      - name: Check out source code
        uses: actions/checkout@v7.0.0

      - name: install dependencies
        run: |
            mise deps
            mise run deploy
        env:
          SOME_ENV: ${{ secrets.SOME_ENV }}

And the same for GitLab Actions:

image: ghcr.io/jdx/mise:latest

stages:

- build

build:
  stage: build
  script:
    - mise deps
    - mise run deploy