DEV Community: Sayem Chowdhury

Meet Lunarr: a self-hosted media server for local and SFTP libraries

Sayem Chowdhury — Sat, 13 Jun 2026 06:58:23 +0000

I have been building Lunarr, a self-hosted web media server for people who want to scan, organize, and watch their own movie and TV libraries in the browser.

It is still early, but the core idea is simple:

Add local or SFTP media libraries, scan them, match metadata, and play them through a clean web UI.

Lunarr is not trying to replace Plex or Jellyfin overnight. Those projects are mature and cover a huge surface area. Lunarr is currently focused on being small, direct, and practical for self-hosted setups where media may live on the same machine or on remote SFTP storage.

What Lunarr does today

Lunarr currently supports:

Local movie and TV libraries
SFTP movie and TV libraries
TMDb metadata matching
Movie, show, season, and episode organization
Browser playback
Direct streaming when the browser can play the file
Temporary HLS remux/transcode when needed
Seekable request-driven HLS playback
Sidecar .vtt subtitle detection
Admin/user accounts
Library sharing controls
Manual scans, scheduled scans, and local file watching
Docker deployment

The SFTP support is one of the important parts for me. A lot of self-hosted setups do not keep media on the same machine as the web app. Lunarr can scan remote folders and, when possible, play seekable remote media without first copying the whole file locally.

Playback model

Lunarr tries direct playback first when the browser can handle the file.

When direct playback is not suitable, Lunarr uses temporary HLS playback. Instead of transcoding an entire movie up front, it generates segments around what the player is actually requesting.

For example, if you jump from 55 minutes to 13 minutes and then to 80 minutes, Lunarr does not transcode everything between those points. It repositions FFmpeg, generates the requested segment, and prepares a small lookahead window so playback can continue.

That keeps CPU and disk usage more proportional to what the viewer is actually watching.

Quick start with Docker

docker run -d \
  --name lunarr \
  --restart unless-stopped \
  -p 3000:3000 \
  -e AUTH_SECRET=replace-with-a-random-secret-at-least-32-chars \
  -e ORIGIN=http://127.0.0.1:3000 \
  -v lunarr-data:/data \
  -v /mnt/media:/media:ro \
  sayem314/lunarr:latest

Then open:

http://127.0.0.1:3000

Create the first admin account, add a movie or TV library, and start a scan.

For local media, mount your host media folder into the container and add the container path, for example /media.

For SFTP media, add the remote connection from the Libraries page.

Why build another media server?

Mostly because I wanted a focused project with a modern web stack, clear internals, and first-class support for both local and SFTP libraries.

Some goals:

Keep deployment simple
Make scanning behavior visible
Keep playback temporary and cleanup-friendly
Avoid requiring users to reorganize everything perfectly
Support browser playback without pretending every file is browser-native
Build something easier to iterate on while still being useful

Current status

Lunarr is beta software. It works, but there are still areas where mature media servers are ahead, especially around the long tail of media containers, subtitle formats, adaptive bitrate streaming, and unusual timestamp/keyframe edge cases.

The current focus is reliability: scanning, playback sessions, seeking behavior, cleanup, and Docker-based deployment.

Tech stack

Lunarr currently uses:

SvelteKit
Bun/Node
SQLite/libSQL
FFmpeg for remux/transcoding
NodeAV for metadata/probing
Docker for easier deployment

Try it

Docker image:
https://hub.docker.com/r/sayem314/lunarr

GitHub:
https://github.com/lunarr-app/lunarr-go

Feedback is welcome, especially from people running self-hosted media setups with local disks, SFTP storage, or mixed libraries.

Run Codex, Claude Code, and OpenCode in Docker — Without Giving Them Your Host

Sayem Chowdhury — Wed, 03 Jun 2026 12:30:03 +0000

AI coding CLIs are powerful — and that power is the problem.

Codex, Claude Code, and OpenCode can read your codebase, run shell commands, install packages, and edit files. When they run directly on your host, a bad prompt, a confused model, or a compromised dependency can touch anything your user account can reach.

I built ai-agents to put that workflow inside Docker instead.

Over 500 developers have already pulled the images. This post explains what it does, what it actually protects, and how to set it up in under two minutes.

The idea

Instead of installing an AI CLI globally and letting it run on your OS:

Pull a pre-built Docker image with the CLI + language tooling baked in
Bind-mount your project so edits are live on disk
Mount your existing login (~/.codex, ~/.claude, etc.) — no API keys in the image
Run from any repo with a shell alias

No repo clone required. No custom Dockerfile per project. One alias in ~/.zshrc and you're done.

┌─────────────────────────────────────────┐
│  Host OS — protected by Docker          │
│  ┌───────────────────────────────────┐  │
│  │  Container                        │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │  /workspace (your repo)     │  │  │  ← bind-mounted, writable
│  │  │  Codex / Claude / OpenCode  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘

Docker is the outer sandbox. Inside the container, the CLI still gets full access to /workspace and whatever auth dirs you mount — that's intentional. The agent needs to write code and run tests.

What you get

Three CLIs, one pattern:

Tool	Image tag	Inner sandbox flag
OpenAI Codex	`sayem314/ai-agents:codex`	`--sandbox danger-full-access`
Claude Code	`sayem314/ai-agents:claude-code`	`--dangerously-skip-permissions`
OpenCode	`sayem314/ai-agents:opencode`	(none — Docker is the boundary)

15 published tags total: 3 tools × 5 language stacks.

Lang	What's inside
`full` (default)	Node, Python, Go, Rust + Playwright CLI + Chromium
`node`	Node 24, npm, pnpm, bun
`python`	Python 3.14, uv
`go`	Go 1.26
`rust`	Rust stable, clang, lld

Examples: codex, codex-node, claude-python, opencode-rust.

Multi-arch (amd64 + arm64) — works on Apple Silicon and Linux out of the box.

Quick start

Prerequisites: Docker installed, and sign in to your chosen CLI once on the host (so ~/.codex or ~/.claude exists).

Add aliases to ~/.zshrc or ~/.bashrc:

# Codex
alias codex='docker run -it --rm -w /workspace \
  -v "$PWD:/workspace" \
  -v "$HOME/.codex:/root/.codex" \
  -v "$HOME/.config/codex:/root/.config/codex" \
  sayem314/ai-agents:codex --sandbox danger-full-access'

# Claude Code
alias claude-code='docker run -it --rm -w /workspace \
  -v "$PWD:/workspace" \
  -v "$HOME/.claude:/root/.claude" \
  -v "$HOME/.config/claude:/root/.config/claude" \
  sayem314/ai-agents:claude-code --dangerously-skip-permissions'
alias claude='claude-code'

# OpenCode
alias opencode='docker run -it --rm -w /workspace \
  -v "$PWD:/workspace" \
  -v "$HOME/.config/opencode:/root/.config/opencode" \
  -v "$HOME/.local/share/opencode:/root/.local/share/opencode" \
  sayem314/ai-agents:opencode'

Then:

source ~/.zshrc
cd ~/my-app
codex          # or claude-code / opencode

First run pulls the image automatically. Every run is ephemeral (--rm) — no leftover container state.

How auth works

You log in on your host once. The alias mounts those config dirs into the container at /root/...:

Tool	Host paths mounted
Codex	`~/.codex`, `~/.config/codex`
Claude Code	`~/.claude`, `~/.config/claude`
OpenCode	`~/.config/opencode`, `~/.local/share/opencode`

No tokens baked into the image. No keys in your shell rc unless you choose API-key auth for CI.

For git push from inside the container, add read-only mounts:

-v "$HOME/.gitconfig:/root/.gitconfig:ro" \
-v "$HOME/.ssh:/root/.ssh:ro"

What Docker actually protects

Protected:

Host filesystem outside mounted volumes
Host processes, packages, and network namespace (unless you expose ports)
Leftover state — container is removed on exit

Not protected:

Your bind-mounted repo — the agent can read, edit, and delete project files
Mounted auth dirs — writable unless you add :ro
Secrets in the repo (.env, keys, credentials)

Treat the agent like a powerful local developer with access to everything you mounted. Review diffs before committing, same as always.

The --sandbox danger-full-access / --dangerously-skip-permissions flags relax the CLI's inner restrictions so it can run builds, tests, and package installs freely inside the container. Docker remains the outer boundary.

Why not just use the official install?

Fair question. Here's the trade-off:

Approach	Pros	Cons
Native CLI on host	Fastest I/O, simplest setup	Agent runs with your user permissions everywhere
Official OpenCode Docker image	Maintained upstream	Single tool, no lang variants, no unified pattern
ai-agents	Same alias pattern for 3 CLIs, 5 lang stacks, subscription auth mounts	Bind-mount I/O overhead on macOS, runs as root inside container

On macOS, add :cached to volume mounts and enable VirtioFS in Docker Desktop for better performance:

-v "$PWD:/workspace:cached"

Picking an image

Your project	Tag
Polyglot / general use	`codex`, `claude-code`, `opencode`
Node/TS only	`*-node`
Python only	`*-python`
Go module	`*-go`
Rust crate	`*-rust`

Full images are larger but work everywhere. Language-specific tags pull faster and use less disk.

Need browser automation? Playwright CLI + Chromium ships only on full tags.

What's under the hood

Two-layer build:

Language layer — official base images (node:24-bookworm, python:3.14-bookworm, etc.) + shared deps (git, curl, build tools)
Tool layer — CLI installed via official scripts on top

Codex installs to /opt/codex (not ~/.codex) so mounting ~/.codex for auth doesn't hide the Linux binary. Language layers stay local; only the 15 tool tags are published to Docker Hub.

CI publishes updated images on a staggered schedule — Codex, Claude, and OpenCode each get their own workflow.

Limitations (honest)

Runs as root inside the container. Files created in your project may be root-owned on the host. --user $(id -u):$(id -g) won't work today — CLIs live in /root/.local/bin.
Not a security silver bullet. If you mount $HOME or your entire disk, you've undone the isolation.
Resume/history depends on mounting the correct auth paths and running from the same project directory. Session storage is tool-specific — see the docs for details.

Try it

docker pull sayem314/ai-agents:codex

Or browse the full docs, image matrix, and troubleshooting guide on GitHub:

→ github.com/sayem314/ai-agents

Star the repo if it's useful — and open an issue if something breaks. 500+ pulls in and I'm still iterating.

Questions? Drop a comment or open a GitHub issue. What AI CLI do you run — and do you sandbox it?

Devo: a code-first alternative to n8n and Activepieces

Sayem Chowdhury — Tue, 26 May 2026 06:12:21 +0000

I’m building Devo, a self-hosted automation builder for people who prefer code over workflow canvases.

Think n8n or Activepieces, but code-first instead of canvas-first.

Instead of wiring nodes together, every automation is a small JavaScript/TypeScript task. Each task has its own:

main.ts
.env
package.json

That means tasks can import npm packages, use normal code patterns, and be reviewed like regular source code.

Why I’m building it

Visual workflow tools are great for simple integrations.

But once an automation becomes more complex, node graphs can become harder to reason about:

business logic gets split across many nodes
error handling becomes awkward
testing is not natural
reviewing changes is difficult
reuse is limited

For many automations, code is simply a better interface.

Devo tries to keep the good parts of automation platforms, while making the actual logic plain JavaScript/TypeScript.

How it works

The main UI is an AI chat plus a browser editor.

You can ask the agent something like:

Build a webhook that receives Shopify orders and stores them in Postgres.

Devo generates TypeScript code, shows it in the editor, and lets you edit it before saving/deploying.

Tasks can currently run from:

manual runs
webhook endpoints
cron schedules with timezone support

Because every task has a package.json, you can use npm packages just like a normal project.

Example

A webhook task can look like this:

export async function webhook(req: Request) {
  const order = await req.json();

  console.log("received order", order.id);

  return Response.json({
    ok: true,
    order_id: order.id
  });
}

The task can then be deployed behind an opaque webhook URL.

Self-hosted by default

Devo is built for local and self-hosted use.

It stores app data locally and runs task code as child processes with timeouts and output limits.

Important note: this is still early MVP software. The current runtime is not a secure multi-tenant sandbox. It is meant for trusted self-hosted use right now.

Current stack

SvelteKit / Svelte 5
Better Auth
Kysely + SQLite/libSQL
Monaco editor
OpenAI Agents SDK
Bun or Node task execution

Try it

GitHub:

https://github.com/sayem314/devo

Docker quick start:

docker run --rm \
  -p 3000:3000 \
  -v devo-data:/data \
  -e AUTH_SECRET="$(openssl rand -base64 32)" \
  -e ORIGIN="http://127.0.0.1:3000" \
  sayem314/devo:latest

Then open:

http://127.0.0.1:3000

Feedback wanted

I’d love feedback on:

whether the “code-first automation” direction makes sense
what triggers/runtimes should come next
how task isolation should work for self-hosted users
whether this feels meaningfully different from existing workflow tools

If you’ve used n8n, Activepieces, Zapier, Temporal, Val Town, or similar tools, I’d especially like to hear where this approach feels useful or not useful.

Shiprr, a Git-based PaaS for deploying web apps with regional runtime placement

Sayem Chowdhury — Mon, 04 May 2026 18:40:00 +0000

I built Shiprr, a Git-based platform for deploying web apps without having to wire up your own deployment pipeline, runtime fleet, or control plane.

It is aimed at long-running web apps, where you want the convenience of a PaaS but still need control over region, resources, domains, and access.

What Shiprr does

Shiprr supports:

GitHub and GitLab repositories
Source builds
Automatic framework detection
Regional runtime placement
Custom domains
Managed TLS
Access controls
App sizing from the dashboard

The goal is to make the path from Git push to a live app as direct as possible, while still keeping deployment behavior understandable.

Why I built it

A lot of deployment tools fall into one of two extremes:

very simple, but limited
very flexible, but operationally heavy

I wanted something in between: a platform that feels lightweight, but still supports real production workflows.

What it is not

Shiprr is not trying to be:

a serverless platform
a general infrastructure control plane
a replacement for all cloud services

It is focused on deploying web apps cleanly, with sane defaults and enough control for production use.

Current direction

The main focus is:

Git-based deployments
regional runtime placement
predictable app sizing
basic operational visibility
a workflow that stays simple for smaller teams

Feedback welcome

I would especially appreciate feedback on:

whether the positioning makes sense
what would make it easier to adopt
what you would expect from a PaaS before trusting it for a real app

Site: https://shiprr.app

13 Free Web-Based Developer Tools You'll Actually Use

Sayem Chowdhury — Sat, 24 May 2025 11:00:00 +0000

As developers, we often need quick access to various tools for debugging, testing, and data manipulation. While there are many great tools out there, they often come with a price tag or require installation. Today, I want to share a collection of web-based developer tools that are completely free, run in your browser, and focus on privacy.

Why Web-Based Tools?

No installation required
Access from any device
Privacy-focused (client-side processing where possible)
Zero cost

Network & Security Tools

1. DNS Lookup

Quickly check DNS records using Google's DNS-over-HTTPS. Perfect for:

Verifying DNS configurations
Troubleshooting domain issues
Checking record propagation

2. SSL Certificate Checker

Verify SSL certificates and their chain of trust. Great for:

Security audits
Certificate expiration monitoring
SSL configuration validation

3. HTTP Headers Analyzer

Analyze HTTP headers for any website. Useful for:

Security header verification
Server configuration checks
CORS policy validation

4. WHOIS Lookup

Get detailed domain registration information. Handy for:

Domain ownership verification
Registration date checks
Contact information lookup

5. Ping Tool

Test network connectivity and response times. Essential for:

Network troubleshooting
Latency monitoring
Basic connectivity tests

API Development Tools

6. Request Debugger

A Postman-like interface for testing HTTP requests. Features:

Multiple HTTP method support
Header management
Request body editing
Response inspection

7. WebSocket Debugger

Test and debug WebSocket connections with:

Real-time message monitoring
Bi-directional communication
Connection status tracking

8. GraphQL Explorer

A basic tool for GraphQL API testing:

Execute query
Schema exploration
Real-time response viewing

Developer Utilities

9. JSON Beautifier

Format and validate JSON data with:

Syntax highlighting
Error detection
Pretty printing

10. Base64 Encoder/Decoder

Quick conversion between text and Base64:

Encode text to Base64
Decode Base64 to text
Copy to clipboard functionality

11. Text Diff Checker

Compare text differences with:

Side-by-side comparison
Syntax highlighting
Line-by-line diff view

12. Regex Tester

Test and validate regular expressions:

Real-time matching
Sample text testing
Common pattern examples

13. CSV/TSV Viewer

View and analyze tabular data:

Sort and filter capabilities
Table formatting
Export options

Privacy and Security

All these tools are designed with privacy in mind:

Client-side processing where possible
No data storage
No tracking

Try It Out

You can access all these tools at https://kvmpods.com/tools. They're completely free to use and don't require any registration.

Having quick access to these tools can significantly improve your development workflow. Whether you're debugging an API, checking network configurations, or manipulating data, these web-based tools can save you time and effort.

Deploy Your Ghost Blog in Minutes with KVMPods

Sayem Chowdhury — Sat, 23 Nov 2024 13:13:00 +0000

Want to start a professional blog without the hassle of complex infrastructure? Let's deploy Ghost - an open source publishing platform - using KVMPods pre-made template or your own Docker Compose configuration.

Why Ghost?

Ghost is a modern publishing platform that offers:

Clean, minimalist design
Built-in SEO tools
Native newsletter system
Member subscriptions
Custom themes
Markdown support

Option 1: Quick Deploy with KVMPods Template

The fastest way to get started is using this template:

Log into your KVMPods dashboard
Navigate to Templates
Find the Ghost template
Click "Deploy"
Follow the setup wizard

Option 2: Custom Deployment

If you prefer to customize your setup, here's production-ready Docker Compose template:

services:
  ghost:
    image: ghost:5-alpine
    container_name: ghost
    restart: unless-stopped
    ports:
      - "2368:2368"
    environment:
      url: ${GHOST_URL}
      database__client: mysql
      database__connection__host: mysql
      database__connection__user: ${MYSQL_USER}
      database__connection__password: ${MYSQL_PASSWORD}
      database__connection__database: ${MYSQL_DATABASE}
    volumes:
      - ./ghost/content:/var/lib/ghost/content
    depends_on:
      mysql:
        condition: service_healthy
    networks:
      - ghost-network

  mysql:
    image: mysql:8.0
    container_name: ghost-mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - ./mysql/data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 30s
      timeout: 5s
      retries: 3
    networks:
      - ghost-network

networks:
  ghost-network:

Key features of this template:

Health checks for MySQL
Persistent volume storage
Secure networking

Deployment Steps

Log into your KVMPods dashboard
Click "New Server"
Select your preferred location
Choose a plan
Once your server is ready, go to the Apps section
Click "Create New App"
Paste the Docker Compose file above and set env variables

Post-Deployment Configuration

Access your Ghost admin panel at:

http://<SERVER_IP>:2368/ghost

Initial setup steps:

Create your admin account
Configure your blog details
Select a theme
Create your first post
Set up newsletters (optional)
Configure memberships (optional)

Cost Optimization

KVMPods offers exceptional value:

Plans start at just €10/month
Host multiple apps on a single server
All plans include:
- Dedicated VM resources
- NVMe storage
- Automated backups (charges applicable)
- Technical support

💡 Pro Tip: Maximize your server's value by hosting multiple applications. One of our customers runs 6 different apps on a single server, bringing their per-app cost down to just €1.66!

KVMPods: Run Docker Compose Apps with True VM Isolation

Sayem Chowdhury — Fri, 22 Nov 2024 12:08:03 +0000

Ever tried running Docker Compose in production and hit limitations? KVMPods gives you your own KVM virtual machine where you can run multiple Docker Compose apps with true isolation from other users.

The Problem with Traditional Container Platforms

Most container platforms share resources between containers and users, which can lead to:

Noisy neighbor problems
Kernel feature limitations
Resource contention
Security concerns
Restricted Docker Compose features

# On traditional platforms
# You often can't use certain features
# Or face resource conflicts with other users 😕
services:
  app:
    image: ghost:latest
    # Will this actually work as expected?
    # Are you sharing resources with others?

Enter KVMPods

With KVMPods, you get:

Your own KVM virtual machine (server)
Run multiple Docker Compose apps within your server
Complete isolation from other users

Just paste your Docker Compose file and deploy:

# Your docker-compose.yml
# Works exactly as expected! 🎉
services:
  wordpress:
    image: wordpress:latest
    restart: always
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    ports:
      - "8080:80"
    volumes:
      - wordpress_data:/var/www/html

  db:
    image: mariadb:latest
    restart: always
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
      MYSQL_ROOT_PASSWORD: somewordpress
    volumes:
      - db_data:/var/lib/mysql

volumes:
  wordpress_data:
  db_data:

Key Features

🔒 True Isolation

Your own KVM virtual machine - no resource sharing with other users

💪 Full Docker Compose Support

All Docker Compose features work as expected:

Volumes
Networks
Environment variables
Port mappings
Everything!

🚀 Enterprise Infrastructure

NVMe storage
Dedicated RAM
Support for both x86 and ARM

Getting Started

Sign up at kvmpods.com
Create your KVM server
Paste your Docker Compose files and deploy!

It's that simple. No CLI tools, no complex configurations - just pure Docker Compose as it was meant to be.

Perfect For:

Production Docker Compose deployments
Multiple applications on one server
Microservices architectures
Any workload needing true isolation

Pricing

Starting at €10/month for your own KVM virtual machine where you can run multiple Docker Compose applications.

Get Started

Start deploying your Docker Compose apps today at kvmpods.com

Questions? Comments? Let me know below! 👇

KVMPods - Your KVM Server for Docker Compose Apps

Introducing KVMPods – Effortless Docker Compose Hosting

Sayem Chowdhury — Wed, 13 Nov 2024 15:45:00 +0000

🚀 After 8 months of development, I’m excited to introduce KVMPods!

KVMPods is built for anyone who wants a simple, fast way to host their favorite apps with Docker Compose. It lets you launch public or private apps directly from a Docker Compose file, all while skipping the usual VPS setup headaches. You get everything needed in one place to deploy and run Docker Compose apps easily.

Why KVMPods?

No Hassle: Deploy any Docker Compose app, no need to set up a VPS or configure servers.
Fast and Reliable: Experience top-tier performance at an affordable price.
Transparent Pricing: Straightforward pricing—no hidden fees or surprises.

Who Is It For?

KVMPods is perfect for developers, startups, small teams, or anyone who wants Docker Compose without the usual VPS maintenance. Whether you’re a power user or just looking to host a few apps without server management, KVMPods makes it easy.

Ready to give it a try? Check out KVMPods.com and let me know what you think!