DEV Community: Mohamad Ashraful Islam

How I Built My Personal Blog Using the DEV.to API

Mohamad Ashraful Islam — Tue, 21 Jul 2026 06:42:56 +0000

Write once, publish everywhere. That was the goal when I built my personal blog.

For years, I published articles directly on DEV.to because of its amazing developer community and reach. But I also wanted a blog on my own domain where I had complete control over the design, branding, and user experience.

Instead of maintaining two separate blogs, I decided to make DEV.to my CMS and let my website fetch articles automatically using the DEV.to API.

The result is my personal blog:

👉 https://blog.ashraful.dev/

Every time I publish a new article on DEV.to, it automatically appears on my website. No copy-pasting. No duplicated content. No extra work. :contentReference[oaicite:0]{index=0}

The Problem

Initially, my workflow looked like this:

Write the article.
Publish it on DEV.to.
Copy the Markdown.
Paste it into my website.
Fix formatting.
Publish again.

This wasn't difficult, but it was repetitive.

Every blog post required maintaining two separate copies of the same content.

Eventually, I asked myself:

Why am I manually copying content when DEV.to already provides an API?

That simple question completely changed my blogging workflow.

Why I Chose DEV.to

There are many blogging platforms available:

Medium
Hashnode
Ghost
WordPress
Notion

I chose DEV.to because:

It has a large developer community.
Articles are easily discoverable.
Markdown support is excellent.
It provides a free public API.
I don't need to manage another CMS. :contentReference[oaicite:1]{index=1}

Instead of building an admin panel for my blog, I simply use DEV.to as the content management system.

The Architecture

My setup is surprisingly simple.

            Write Article
                  │
                  ▼
              DEV.to
                  │
            DEV.to API
                  │
                  ▼
          Personal Website
      (blog.ashraful.dev)

My website never stores blog posts locally.

Instead, it fetches them directly from the DEV.to API whenever needed.

This keeps everything synchronized automatically.

Fetching Articles

DEV.to exposes a public endpoint for fetching a user's published articles.

Example:

GET https://dev.to/api/articles?username=YOUR_USERNAME

In JavaScript:

const response = await fetch(
  "https://dev.to/api/articles?username=ashraful"
);

const posts = await response.json();

The response includes useful metadata like:

Title
Description
Cover image
Published date
Tags
Reading time
Slug
URL

No authentication is required for public articles. :contentReference[oaicite:2]{index=2}

Loading a Single Blog Post

Listing articles is only half the job.

When a visitor clicks on an article, the website fetches its full content.

The API endpoint looks like this:

GET https://dev.to/api/articles/{username}/{slug}

Example:

GET https://dev.to/api/articles/ashraful/my-awesome-post

The response contains:

Markdown
Rendered HTML
Cover image
Metadata
Reactions
Comments count

The most important field for me is:

{
  "body_markdown": "# My Blog Post..."
}

That's exactly what I render on my website. :contentReference[oaicite:3]{index=3}

Rendering Markdown

Once I receive the Markdown, I render it like any normal Markdown document.

This gives me complete control over:

Typography
Code highlighting
Tables
Images
Custom components

Because the original content is still Markdown, I don't lose any formatting.

My Publishing Workflow

Publishing a new article has become incredibly simple.

Write Article
      │
      ▼
Publish to DEV.to
      │
      ▼
Done ✅

That's it.

There's no second publishing step.

The website automatically displays the new article because it always reads from the API.

Benefits of This Approach

Single Source of Truth

There's only one copy of every article.

I never have to wonder:

"Which version is the latest?"

DEV.to is always the source.

No Duplicate Work

Before:

Publish to DEV.to

↓

Copy Markdown

↓

Paste into Website

↓

Publish Again

Now:

Publish to DEV.to

↓

Finished

One click instead of many.

Better SEO

One concern when publishing content on multiple websites is duplicate content.

The good news is that DEV.to supports canonical URLs, allowing search engines to understand which version should be treated as the original. This helps avoid SEO issues when cross-posting articles. :contentReference[oaicite:4]{index=4}

Custom Design

Although the content comes from DEV.to, my website has its own:

Layout
Branding
Navigation
Theme
Search
Reading experience

Visitors get a consistent experience while I continue using DEV.to as the backend.

Performance Considerations

Calling an external API on every request isn't always ideal.

To improve performance, you can:

Cache API responses.
Use Incremental Static Regeneration (ISR).
Pre-render popular articles.
Refresh the cache periodically.

This reduces API requests while keeping content up to date.

Error Handling

Whenever you depend on an external API, you should plan for failures.

For example:

API downtime
Rate limits
Network issues
Invalid responses

A simple fallback page or cached copy can greatly improve the user experience.

Why I Like This Setup

This approach gives me the best of both worlds.

I get:

The reach of DEV.to.
A fully customized personal website.
No CMS maintenance.
No duplicate content management.
One publishing workflow.

Most importantly, I spend my time writing instead of maintaining content in multiple places.

Could You Do the Same?

Absolutely.

If you already publish on DEV.to, you can build your own blog in just a few hours using its public API.

Whether you're using:

Next.js
React
Vue
Nuxt
Svelte
Astro

the process is almost identical:

Fetch articles.
Display the list.
Fetch a single article by slug.
Render the Markdown.
Style it however you like.

The API is simple, well documented, and perfect for personal portfolio websites. :contentReference[oaicite:5]{index=5}

Final Thoughts

Building my blog around the DEV.to API has been one of the simplest yet most rewarding improvements to my personal website.

Instead of managing two separate publishing platforms, I now have a single workflow: write once, publish once, and let the API do the rest.

If you're already sharing technical articles on DEV.to and want a blog on your own domain, I highly recommend giving this approach a try. It's lightweight, developer-friendly, and removes a lot of repetitive work—letting you focus on what matters most: writing great content.

What Is Load Balancing? A Beginner's Guide to Faster and More Reliable Applications

Mohamad Ashraful Islam — Tue, 21 Jul 2026 03:55:49 +0000

Imagine you're standing in line at a supermarket with only one cashier open. The queue is long, and everyone has to wait.

Now imagine the store opens four more checkout counters. Customers are directed to the shortest queue, and everyone gets served much faster.

That's exactly how load balancing works in computer networks.

Instead of sending every user request to a single server, a load balancer distributes requests across multiple servers, ensuring no single machine becomes overloaded.

In this article, we'll explore what load balancing is, why it's important, how it works, and the different algorithms used to distribute traffic.

What Is Load Balancing?

A load balancer is a system that sits between users and your application servers. It receives incoming requests and forwards them to one of several backend servers based on a set of rules.

Without a load balancer:

                 Users
                   │
                   ▼
            +-------------+
            |   Server 1  |
            +-------------+

Every request goes to the same server.

If too many users connect at once, the server may slow down or even crash.

With a load balancer:

                    Users
                      │
                      ▼
            +------------------+
            |  Load Balancer   |
            +------------------+
              │      │      │
      ┌───────┘      │      └────────┐
      ▼              ▼               ▼
+------------+ +------------+ +------------+
|  Server 1  | |  Server 2  | |  Server 3  |
+------------+ +------------+ +------------+

Requests are shared across all servers.

If you still confused about scaling part then read the article. Also this article is prerequisite of leaning load balancing.

Mohamad Ashraful Islam

Sep 22 '20

Horizontal vs Vertical Scaling

#systemdesign #server #loadbalancing #scaling

2 min read

Why Do We Need Load Balancing?

Modern applications often serve thousands—or even millions—of users.

If all requests go to one server, it may suffer from:

High CPU usage
Memory exhaustion
Slow response times
Application crashes
Downtime

Load balancing helps by spreading traffic evenly, allowing applications to remain fast and available even during heavy usage.

A Real-Life Example

Imagine you're running a video streaming service similar to Jellyfin.

On a normal day:

20 people are watching videos.
One server handles the load without problems.

Then a popular movie is released.

Suddenly:

5,000 people start streaming at the same time.

Without load balancing:

5000 Users
     │
     ▼
Server 1

The server becomes overwhelmed.

With load balancing:

5000 Users
      │
      ▼
+------------------+
|  Load Balancer   |
+------------------+
   │      │      │
   ▼      ▼      ▼
1000    2000   2000 Users

Each server handles only part of the traffic, keeping the service responsive.

How Load Balancing Works

Let's walk through a simple request.

A user visits:

https://example.com

The request reaches the load balancer.

The load balancer checks:

Which servers are available?
Which server has the least load?
Which routing algorithm is configured?

It then forwards the request to the selected server.

User
 │
 ▼
Load Balancer
 │
 ├──► Server 1
 ├──► Server 2
 └──► Server 3

The chosen server processes the request and sends the response back through the load balancer to the user.

To the user, everything appears as a single website.

Load Balancing Algorithms

A load balancer needs a strategy to decide where to send each request.

Here are some of the most common algorithms.

1. Round Robin

This is the simplest method.

Requests are distributed one after another.

Request 1 → Server 1

Request 2 → Server 2

Request 3 → Server 3

Request 4 → Server 1

Request 5 → Server 2

Advantages

Easy to implement
Fair when servers have similar hardware

Disadvantages

Doesn't consider server workload

2. Least Connections

The load balancer sends the next request to the server with the fewest active connections.

Example:

Server 1
120 Connections

Server 2
25 Connections

Server 3
70 Connections

The next request goes to Server 2.

This method is useful when requests take different amounts of time to complete.

3. Least Response Time

Instead of counting connections, this algorithm chooses the server responding the fastest.

Example:

Server	Response Time
Server 1	20 ms
Server 2	80 ms
Server 3	12 ms

The next request goes to Server 3.

4. Weighted Round Robin

Sometimes servers have different hardware.

Example:

Server	CPU Cores
Server 1	32
Server 2	16
Server 3	8

Instead of sending the same number of requests to each server, the load balancer assigns weights.

Server 1
50%

Server 2
30%

Server 3
20%

More powerful servers receive more traffic.

5. IP Hash

Some applications require users to always reach the same server.

The load balancer hashes the client's IP address.

User A
↓

Server 2

User B
↓

Server 1

This is useful for applications that maintain user sessions locally.

Health Checks

A load balancer continuously checks whether backend servers are healthy.

Example:

Server 1 ✓

Server 2 ✗

Server 3 ✓

If Server 2 fails, the load balancer automatically stops sending traffic to it.

Once it recovers, it can be added back into the pool.

This increases application availability without requiring user intervention.

Session Persistence (Sticky Sessions)

Some applications store user session data in memory.

If requests bounce between servers, users may be logged out unexpectedly.

Sticky sessions solve this problem by ensuring a user's requests continue to go to the same backend server.

However, modern applications often store sessions in shared databases or caches like Redis, reducing the need for sticky sessions.

Hardware vs Software Load Balancers

Hardware Load Balancers

Dedicated networking devices used in large enterprise environments.

Examples:

F5 BIG-IP
Citrix ADC

Advantages

Extremely high performance
Specialized hardware
Enterprise support

Disadvantages

Expensive
Less flexible
Requires dedicated equipment

Software Load Balancers

Run on standard servers or virtual machines.

Popular options include:

Nginx
HAProxy
Traefik
Envoy
Caddy

Advantages

Low cost
Flexible
Easy to deploy
Cloud-friendly

For most home labs, startups, and small businesses, software load balancers are more than sufficient.

Load Balancing in Docker

If you're running multiple container instances, a load balancer can distribute requests among them.

                Users
                  │
                  ▼
          +----------------+
          |     Nginx      |
          +----------------+
             │     │     │
             ▼     ▼     ▼
       App-1 App-2 App-3

This improves scalability and allows you to update containers with minimal downtime.

Load Balancing in Kubernetes

Kubernetes automatically uses load balancing to expose applications.

Internet
     │
     ▼
 Kubernetes Service
     │
 ┌───┼───┐
 ▼   ▼   ▼
Pod  Pod  Pod

As Pods are added or removed, Kubernetes updates the routing automatically.

Benefits of Load Balancing

Using a load balancer offers several advantages:

Improved performance
Better scalability
High availability
Automatic failover
Easier maintenance
Reduced downtime
Better user experience

It also allows you to perform rolling updates, replacing or upgrading servers one at a time without taking the entire application offline.

Common Misconceptions

"A load balancer makes my application faster."

Not necessarily.

A load balancer doesn't make an individual server faster. Instead, it distributes traffic so that no single server becomes a bottleneck.

"One server is enough forever."

As your application grows, you'll eventually need multiple servers. Designing your application with load balancing in mind makes future scaling much easier.

"Load balancing replaces backups."

Load balancing improves availability, not data protection. You still need a proper backup strategy.

When Do You Need Load Balancing?

You should consider using load balancing if:

Your application receives heavy traffic.
You want high availability.
You run multiple application servers.
You need zero-downtime deployments.
You want automatic failover.
You expect your application to grow over time.

For small personal projects, a single server may be enough. But as demand increases, load balancing becomes an essential part of a scalable architecture.

Conclusion

Load balancing is one of the core technologies behind modern web applications. From streaming platforms and e-commerce websites to cloud services and container orchestration systems, it's what keeps applications fast, responsive, and highly available.

By intelligently distributing traffic across multiple servers, a load balancer prevents overload, improves reliability, and allows your infrastructure to scale with user demand.

Whether you're building a home lab, deploying Docker containers, or designing a production system, understanding load balancing is a valuable step toward building resilient and scalable applications.

Linux Backup Strategies: Beyond Just `rsync`

Mohamad Ashraful Islam — Mon, 20 Jul 2026 13:39:05 +0000

Data loss isn't a matter of if—it's a matter of when. Whether it's a failing hard drive, accidental deletion, ransomware, or a simple typo in the terminal, every Linux user should have a backup strategy. While rsync is an incredibly powerful tool, it's only one piece of the puzzle.

In this guide, we'll explore modern Linux backup strategies, understand where rsync fits in, and build a reliable backup plan that you can trust.

Why Backups Matter

Imagine these situations:

You accidentally run rm -rf in the wrong directory.
Your SSD suddenly dies.
A Docker volume becomes corrupted.
Your server is compromised.
A power outage damages your filesystem.
Your laptop is stolen.

Without backups, recovery may be impossible.

A good backup strategy protects you from hardware failure, software bugs, human error, and disasters.

What Makes a Good Backup?

A reliable backup should be:

Automatic – Runs without manual intervention.
Versioned – Keeps previous versions of files.
Redundant – Stored in more than one location.
Encrypted – Protects sensitive data.
Tested – Regularly verified by restoring files.

Remember:

A backup that has never been tested is just a theory.

The 3-2-1 Backup Rule

The most widely recommended backup strategy is the 3-2-1 Rule.

It means:

3 copies of your data
2 different storage devices
1 copy stored off-site

Example:

                Original Data
                      │
          ┌───────────┴───────────┐
          │                       │
          ▼                       ▼
 External SSD              Cloud Storage
          │
          ▼
   Local Backup Copy

This protects against:

Disk failures
Fire
Theft
Flood
Ransomware

Understanding `rsync`

rsync is one of the most popular backup tools on Linux.

Instead of copying everything every time, it copies only the changed files, making it incredibly efficient.

Example:

rsync -avh --delete /home/user/Documents/ /mnt/backup/Documents/

Options explained:

Option	Meaning
`-a`	Archive mode (preserves permissions, timestamps, symlinks, etc.)
`-v`	Verbose output
`-h`	Human-readable sizes
`--delete`	Remove files from destination that no longer exist in source

The Problem with `rsync`

Many people think rsync is a backup.

It isn't.

It's primarily a synchronization tool.

Suppose you accidentally delete a file:

Source
├── photo.jpg ❌ deleted

Running:

rsync --delete

also deletes the file from your backup.

Your backup now contains the same mistake.

This is why relying solely on rsync can be dangerous.

Versioned Backups

Instead of overwriting yesterday's backup, keep multiple versions.

Example:

Backups

├── 2026-07-01
├── 2026-07-02
├── 2026-07-03
├── 2026-07-04

If today's backup contains a corrupted file, you can restore yesterday's version.

This protects against:

Accidental deletions
File corruption
Malware
Ransomware

Incremental Backups

An incremental backup stores only the files that changed since the last backup.

Example:

Day 1
100 GB copied

Day 2
Only 500 MB changed

Backup Size
500 MB

Benefits:

Faster backups
Less storage space
Lower disk usage

Popular tools:

BorgBackup
Restic
Duplicity

Differential Backups

Differential backups store changes since the last full backup.

Example:

Sunday
Full Backup

Monday
Changes since Sunday

Tuesday
Changes since Sunday

Wednesday
Changes since Sunday

Restoring is faster than incremental backups because you only need:

One full backup
One differential backup

Snapshot-Based Backups

Modern filesystems can create snapshots almost instantly.

A snapshot captures the state of a filesystem at a specific moment.

Filesystem

Snapshot A
Snapshot B
Snapshot C

Snapshots are:

Fast
Space-efficient
Easy to restore

Supported by:

Btrfs
ZFS
LVM

Snapshots are excellent for protecting against accidental changes, but they are not backups unless stored on a separate device.

Archive Backups with `tar`

Sometimes you just want to archive a directory.

Example:

tar -czf backup.tar.gz /data

For better compression:

tar -cJf backup.tar.xz /data

Compression comparison:

Format	Speed	Compression
gzip	Fast	Good
bzip2	Medium	Better
xz	Slow	Excellent
zstd	Very Fast	Excellent

Remote Backups

Backing up to another machine protects against hardware failure.

Using rsync over SSH:

rsync -azP /data user@backup-server:/backup/

Advantages:

Encrypted
Efficient
Reliable

For home labs, this is often the easiest way to create an off-site or secondary backup.

Cloud Backups

Local backups are great—but what if your house floods or catches fire?

Cloud storage provides geographic redundancy.

Popular providers include:

Backblaze B2
Wasabi
AWS S3
Google Cloud Storage
Microsoft Azure
Dropbox
Google Drive

Tools like Restic and Rclone make cloud backups straightforward.

Encrypt Your Backups

Backups often contain:

Passwords
Photos
Personal documents
Financial records

If someone steals your backup drive, they shouldn't gain access to your data.

Tools:

GPG
LUKS
Restic (built-in encryption)
BorgBackup (built-in encryption)

Encryption is especially important for cloud backups and portable drives.

Automating Backups

A backup that depends on memory is likely to be forgotten.

Use automation:

Cron

0 2 * * * /usr/local/bin/backup.sh

Runs every day at 2:00 AM.

Systemd Timers

Systemd timers provide more flexibility than cron, including better logging and missed-job handling.

Docker Backup Strategies

If you use Docker, don't just back up the containers.

Focus on:

Docker volumes
Bind mounts
Configuration files
Docker Compose files
Environment (.env) files

Example:

docker-compose.yml
.env
config/
volumes/

Containers can be recreated. Your data cannot.

Verify Your Backups

The worst time to discover a broken backup is during an emergency.

Regularly test your backups.

Checklist:

Restore random files.
Verify archive integrity.
Check file permissions.
Ensure timestamps are preserved.
Confirm backups complete successfully.
Review logs for errors.

Practice recovery before you actually need it.

Recommended Backup Tools

Tool	Best For
rsync	File synchronization
tar	Archives
BorgBackup	Deduplicated encrypted backups
Restic	Cloud backups
Rclone	Cloud storage synchronization
Timeshift	Desktop system snapshots
Snapper	Btrfs snapshots
Duplicity	Encrypted incremental backups

A Practical Home Server Backup Strategy

Here's a simple yet effective backup plan for a self-hosted Linux server.

Daily

rsync important data to an external SSD.
Create compressed archives of configuration files.
Verify backup logs.

Weekly

Sync backups to a remote server over SSH.
Upload critical data to cloud storage.

Monthly

Test restoring files.
Check disk health (SMART).
Verify backup integrity.
Remove outdated backups according to your retention policy.

This layered approach protects against accidental deletion, hardware failure, and site-wide disasters.

Common Backup Mistakes

Avoid these common pitfalls:

❌ Keeping backups on the same drive.
❌ Never testing restores.
❌ Forgetting hidden files.
❌ Ignoring Docker volumes.
❌ Storing backups unencrypted.
❌ Running backups manually.
❌ Keeping only one backup copy.
❌ Assuming RAID is a backup.

Remember:

RAID improves availability—it does not replace backups.

Conclusion

rsync is an excellent tool, but it's only one part of a comprehensive backup strategy. A truly reliable backup system combines multiple techniques: synchronization, versioning, encryption, automation, remote storage, and regular testing.

By following the 3-2-1 rule, keeping versioned backups, automating the process, and verifying restores, you can dramatically reduce the risk of losing important data.

Because in the world of Linux—and computing in general—the best backup isn't the one you make after disaster strikes. It's the one that's already waiting when it does.

How Reverse Proxies Actually Work (And Why Every Self-Hosted Server Needs One)

Mohamad Ashraful Islam — Sun, 19 Jul 2026 16:51:42 +0000

Imagine walking into a large office building. You don't know which department handles your request, so you first stop at the reception desk.

The receptionist asks what you need, checks your request, and directs you to the correct department.

A reverse proxy works exactly like that receptionist.

Instead of exposing every application directly to the internet, all traffic first reaches the reverse proxy. The reverse proxy then decides where that request should go.

If you're running a home server, VPS, or Kubernetes cluster, understanding reverse proxies is one of the most valuable networking concepts you can learn.

Let's dive in.

What Is a Reverse Proxy?

A reverse proxy is a server that sits between clients and your backend applications.

Instead of users connecting directly to your services, they connect to the reverse proxy first.

Internet
     │
     ▼
+--------------------+
|   Reverse Proxy    |
+--------------------+
        │
 ┌──────┼─────────┐
 │      │         │
 ▼      ▼         ▼
Jellyfin Immich  Nextcloud

The client never talks directly to Jellyfin, Immich, or Nextcloud.

Everything passes through the reverse proxy.

Reverse Proxy vs Forward Proxy

People often confuse these two.

Forward Proxy

A forward proxy works for the client.

You
 │
 ▼
Forward Proxy
 │
 ▼
Internet

Examples:

Corporate networks
School internet
VPNs
Anonymous browsing

The website sees the proxy—not you.

Reverse Proxy

A reverse proxy works for the server.

Internet
     │
     ▼
Reverse Proxy
     │
     ▼
Your Applications

Clients don't know which server actually handled the request.

Why Not Just Open Every Port?

Suppose your server runs:

Application	Port
Jellyfin	8096
Immich	2283
Nextcloud	8080
Grafana	3000
Portainer	9443

Without a reverse proxy, you'd access them like this:

https://example.com:8096
https://example.com:2283
https://example.com:8080

That's messy.

Instead, a reverse proxy lets you use:

https://movies.example.com
https://photos.example.com
https://cloud.example.com
https://grafana.example.com

Much cleaner.

How a Reverse Proxy Routes Requests

Imagine someone opens:

https://movies.example.com

The request reaches your reverse proxy.

The reverse proxy checks:

Host: movies.example.com

It finds a rule:

movies.example.com
      ↓
http://192.168.1.20:8096

The request is forwarded to Jellyfin.

If someone instead visits:

https://photos.example.com

The proxy routes it to:

http://192.168.1.20:2283

which is your Immich server.

The client never notices this routing.

A Real Example

Suppose your home server hosts four services.

192.168.10.10

├── Jellyfin
├── Immich
├── Grafana
└── Portainer

You install Nginx Proxy Manager.

DNS records:

movies.example.com
photos.example.com
grafana.example.com
portainer.example.com

Routing table:

movies.example.com
    ↓
localhost:8096

photos.example.com
    ↓
localhost:2283

grafana.example.com
    ↓
localhost:3000

portainer.example.com
    ↓
localhost:9443

Everything is now accessible using simple URLs.

HTTPS Becomes Easy

Without a reverse proxy, every application must:

Generate certificates
Renew certificates
Configure HTTPS
Handle redirects

That's a lot of work.

Instead:

Internet
    │ HTTPS
    ▼
Reverse Proxy
    │ HTTP
    ▼
Applications

The reverse proxy handles:

SSL certificates
Let's Encrypt
Automatic renewal
HTTPS redirects

Your backend applications can remain on HTTP inside your trusted local network.

Security Benefits

A reverse proxy isn't just about convenience.

It adds another security layer.

It can:

Hide internal IP addresses
Block malicious requests
Limit request rates
Require authentication
Restrict countries
Filter bad bots
Prevent direct access to services

Your applications become much harder to attack.

Load Balancing

Suppose one server isn't enough.

Instead of one backend:

App Server 1
App Server 2
App Server 3

The reverse proxy distributes traffic.

Client 1 → Server 1

Client 2 → Server 2

Client 3 → Server 3

Benefits:

Higher availability
Better performance
Fault tolerance

Large websites rely heavily on this.

Caching

Imagine your homepage receives thousands of requests.

Instead of asking your application every time:

User
  │
  ▼
Reverse Proxy
  │
Cache Exists?
  │
 Yes ─────► Return Cached Page
  │
 No
  ▼
Application

Static content like:

Images
CSS
JavaScript
Fonts

can be served directly from the reverse proxy.

This greatly reduces application load.

Compression

Modern reverse proxies can compress responses.

Instead of sending:

HTML
CSS
JavaScript

uncompressed, they use:

Gzip
Brotli

Smaller responses mean:

Faster websites
Lower bandwidth usage
Better user experience

WebSockets and Streaming

Applications like:

Jellyfin
Home Assistant
Immich
VS Code Server

use persistent connections.

Reverse proxies understand WebSockets and keep these connections alive while still handling routing and HTTPS.

Popular Reverse Proxy Software

Software	Best For
Nginx	High performance and flexibility
Nginx Proxy Manager	Easy web interface for beginners
Traefik	Docker and Kubernetes integration
HAProxy	High-performance load balancing
Caddy	Automatic HTTPS with minimal configuration
Envoy	Large-scale microservices and cloud-native deployments

Each has its strengths, but for many self-hosters, Nginx Proxy Manager provides an excellent balance of simplicity and features.

Common Mistakes

Many beginners accidentally:

Expose application ports directly to the internet.
Skip HTTPS entirely.
Open unnecessary firewall ports.
Forget to configure X-Forwarded-For and X-Forwarded-Proto headers.
Leave administrative interfaces like Portainer publicly accessible without authentication.
Mix internal and external DNS records in ways that create routing issues.

Taking time to configure your reverse proxy correctly can prevent these problems.

When Do You Need a Reverse Proxy?

You probably need one if you:

Host more than one web application.
Want friendly domain names instead of port numbers.
Need HTTPS certificates.
Run Docker containers.
Self-host services at home.
Want a central place to manage routing, security, and access control.

For many self-hosted environments, a reverse proxy quickly becomes an essential part of the stack rather than an optional extra.

Conclusion

A reverse proxy is much more than a traffic router. It acts as the front door to your infrastructure, deciding where requests go, protecting your applications, managing HTTPS, balancing traffic, and improving performance through caching and compression.

Whether you're running a single Raspberry Pi with a few services or a rack of servers in a data center, the underlying concept is the same:

Clients talk to the reverse proxy, and the reverse proxy talks to your applications.

Once you understand this pattern, you'll notice it everywhere—from home labs and Docker setups to cloud platforms and some of the world's largest websites. It is one of the foundational building blocks of modern web infrastructure.

Celery Tasks on RabbitMQ 4.0: Classic Queues vs Quorum Queues

Mohamad Ashraful Islam — Mon, 13 Jul 2026 04:59:50 +0000

Celery Tasks on RabbitMQ 4.0: Classic Queues vs Quorum Queues

When building distributed systems with Celery and RabbitMQ, one of the most common pitfalls is tasks disappearing. This usually happens in clustered setups when using classic queues. RabbitMQ 4.x introduced some changes and new queue types, which affects Celery users in production. In this post, we'll explore:

How RabbitMQ cluster connections work
Differences between classic and quorum queues
Limitations of each queue type
Why tasks sometimes disappear on classic queues in a 3-node cluster
How to fix these issues

RabbitMQ Cluster Architecture (n/2 + 1)

A RabbitMQ cluster is a peer-to-peer network of nodes where each node can accept connections and coordinate with other nodes. In production, cluster operations often rely on a majority quorum rule:

Minimum nodes to operate = floor(n/2) + 1

For example, in a 3-node cluster:

n = 3
(3 / 2) + 1 = 2 nodes
At least 2 nodes must be up and reachable for the cluster to accept writes or form a majority.

This ensures consistency and reliability, especially for replicated queues.

RabbitMQ 3-node cluster diagram

        +------------+
        | Node A     |
        | (rabbitmq1)|
        +------------+
           |    \
           |     \
           |      \
        +------------+        +------------+
        | Node B     |--------| Node C     |
        | (rabbitmq2)|        | (rabbitmq3)|
        +------------+        +------------+

Each node is a disc node (stores persistent queues).
Messages in classic queues are stored on the node where the queue is declared.
Cluster nodes maintain peer-to-peer links; (n/2)+1 nodes are needed to maintain consistency in operations like leader election.

Classic Queues in RabbitMQ 4.x

Classic queues are the original queue type in RabbitMQ:

Messages are stored on the node where the queue is created
By default, they are not replicated across nodes (unless mirrored, but mirrored queues are deprecated and removed from 4.x ((https://www.rabbitmq.com/docs/3.13/ha)[Read more]))
Suitable for single-node setups or non-critical workloads

What changed in RabbitMQ 4.0

classic_mirrored_queue_version feature is removed in 4.0
- This means old mirrored queues are deprecated
- Classic queues are now always node-local unless manually mirrored via legacy options

Why tasks disappear in a classic queue

In a 3-node cluster, consider a task published to a classic queue:

Queue lives on Node A
Cluster requires (n/2)+1 = 2 nodes to operate correctly
If Node A becomes temporarily unreachable (network glitch, maintenance), Celery can still publish tasks to Node B
Node B cannot deliver the task because queue master is on Node A
As a result, tasks appear lost, especially in short outages

Example scenario

Producer publishes task -> Node B
Queue master       -> Node A
Cluster majority    -> 2 nodes required (A + B)
Node A unavailable for short time
Result: Task cannot be delivered, disappears

The main reason for disappearing tasks is that classic queues exist on a single node, while the cluster is enforcing majority (n/2)+1. If the node hosting the queue is unreachable, even briefly, the task cannot be routed to the master.

Quorum Queues

Quorum queues were introduced to replace mirrored queues and solve the reliability problems of classic queues in clusters.

How quorum queues work

Messages are replicated across multiple nodes
Writes require majority acknowledgment (consensus) to be considered successful
Safe against node failures, because tasks exist on multiple nodes

Quorum queue diagram in 3-node cluster

             +----------------------+
             |      Task Producer    |
             +----------+-----------+
                        |
                        v
             +----------------------+
             | Quorum Queue Leader   |
             |       Node A         |
             +----------+-----------+
                        |
           -------------------------------
           |                             |
           v                             v
+----------------------+       +----------------------+
| Quorum Queue Follower |       | Quorum Queue Follower |
|       Node B          |       |       Node C          |
+----------------------+       +----------------------+

A task is only removed when leader + majority followers confirm
Even if Node A goes down, Node B or C can continue serving the queue

Limitations of quorum queues

Limitation	Explanation	How to mitigate
Slower than classic queues	Each write requires majority acknowledgment	Use quorum queues only for critical tasks
No priorities	Quorum queues do not support task priorities	Use separate queues for priority handling
Memory pressure	Replication consumes memory on all nodes	Monitor memory and adjust `ram nodes` if needed
Prefetching	Workers must fetch 1 task at a time for reliability	`worker_prefetch_multiplier = 1` in Celery

Celery configuration for quorum queues

broker_url = "amqp://admin:admin@rabbitmq1:5672//"

task_default_queue = "celery"
task_default_queue_type = "quorum"

task_acks_late = True
task_reject_on_worker_lost = True
worker_prefetch_multiplier = 1

Ensures tasks are not lost even if nodes fail
Compatible with a RabbitMQ cluster
Works reliably with countdown/ETA tasks when paired with separate queues

Classic vs Quorum: Summary Table

Feature	Classic Queue	Quorum Queue
Persistence	Node-local, disk	Node-local, replicated to majority
Reliability	Low in clusters	High, survives node failures
Supports ETA / countdown	Yes	Yes
Priorities	Yes	No
Throughput	High	Lower than classic
Recommended for production	❌ Only small setups	✅ Critical tasks

Key Takeaways

Classic queues are node-local in RabbitMQ 4.0, so tasks can disappear if the master node is unavailable.
RabbitMQ clusters enforce (n/2)+1 majority for operations, which interacts poorly with classic queues on a single node.
Quorum queues replicate tasks across nodes, making task loss nearly impossible.
Celery settings like task_acks_late and worker_prefetch_multiplier must be tuned with quorum queues.
Countdown / ETA tasks should be isolated in separate queues to avoid blocking main workers.

Recommended Production Setup (3-node cluster)

Celery workers -> connect to all 3 nodes
Default queue -> Quorum queue
Countdown queue -> Quorum queue, separate worker
Classic queues -> Only for dev or non-critical workloads

This configuration ensures tasks are never lost, even during node failure or cluster partitions.

This setup is robust and production-ready for Celery + RabbitMQ 4.0 clusters.

AsyncIO Task Runner (Coro Runner): Simplifying Concurrent Python Task Management

Mohamad Ashraful Islam — Fri, 05 Dec 2025 05:36:19 +0000

Introduction

Managing asynchronous tasks in Python can be complex, especially when you need fine-grained control over concurrency limits and task scheduling. Enter Coro Runner (async-coro-runner), a lightweight Python utility that makes concurrent asynchronous task management straightforward and efficient.

In this post, we'll explore what makes Coro Runner unique, how to use it, and why it might be the perfect solution for your async workload management needs.

What is Coro Runner?

Coro Runner is a Python library built on top of Python's native asyncio module that provides a simple yet powerful interface for managing concurrent asynchronous tasks. It's designed to simplify the execution of multiple async tasks with configurable concurrency limits, all within a single-threaded environment.

The library is particularly useful when you need to:

Execute multiple async tasks concurrently with controlled parallelism
Manage task queues with different priorities
Avoid overwhelming resources with too many concurrent operations
Schedule tasks dynamically from anywhere in your application

Key Features

1. Configurable Concurrency

Define exactly how many tasks should run simultaneously, preventing resource exhaustion while maximizing throughput.

2. Simple API

Add tasks from anywhere in your codebase with a straightforward interface that doesn't require deep asyncio knowledge.

3. Worker Queue System

Multiple queues can be configured with their own priority levels, allowing sophisticated task management.

4. Built on asyncio

Leverages Python's battle-tested asyncio module (introduced in Python 3.4), ensuring stability and compatibility.

Installation

Getting started is as simple as:

pip install coro-runner

Quick Start Guide

Here's a basic example to get you started:

from coro_runner import CoroRunner

# Initialize the runner with a concurrency limit of 10
runner = CoroRunner(concurrency=10)

# Define an async task
async def process_data(item_id, **kwargs):
    # Your async processing logic here
    await some_async_operation(item_id)
    return f"Processed {item_id}"

# Add tasks from anywhere in your code
runner.add_task(process_data, args=[1], kwargs={"priority": "high"})
runner.add_task(process_data, args=[2], kwargs={"priority": "low"})
runner.add_task(process_data, args=[3], kwargs={"priority": "high"})

Important: Your task function must be an async function (defined with async def).

Real-World Use Case: FastAPI Integration

One of the most powerful applications of Coro Runner is in web applications. Here's an example using FastAPI to handle background tasks:

from fastapi import FastAPI
from coro_runner import CoroRunner

app = FastAPI()

# Initialize runner once at startup
runner = CoroRunner(concurrency=10)

async def background_task(task_id: int):
    # Simulate some async work
    await asyncio.sleep(1)
    print(f"Task {task_id} completed")

@app.get("/fire-task")
async def trigger_tasks(count: int = 25):
    # Schedule multiple tasks
    for i in range(count):
        runner.add_task(background_task, args=[i])

    return {"message": f"Scheduled {count} tasks"}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

Why Choose Coro Runner?

Compared to Raw asyncio

While Python's asyncio is powerful, managing task concurrency often requires boilerplate code. Coro Runner abstracts this complexity:

Without Coro Runner:

# Managing concurrency manually with asyncio
semaphore = asyncio.Semaphore(10)

async def limited_task(task_func, *args):
    async with semaphore:
        return await task_func(*args)

# Need to manage the semaphore for every task...

With Coro Runner:

# Simple and clean
runner = CoroRunner(concurrency=10)
runner.add_task(your_task, args=[1, 2, 3])

Declare Once, Use Everywhere

A significant advantage is that you can initialize the runner once and call it from anywhere in your application:

# config.py
from coro_runner import CoroRunner
runner = CoroRunner(concurrency=20)

# module_a.py
from config import runner
runner.add_task(task_a, args=[1])

# module_b.py
from config import runner
runner.add_task(task_b, args=[2])

Advanced Features (Coming Soon)

The Coro Runner roadmap includes exciting enhancements:

Monitoring Tool Integration: Real-time task monitoring and analytics
Low-Level API: Advanced features like callbacks, acknowledgments, and error handling
Robust Logging: Detailed execution tracking for debugging and optimization

Use Cases

Coro Runner shines in scenarios such as:

Web Scraping: Fetch multiple URLs concurrently while respecting rate limits
Data Processing: Process large datasets with controlled parallelism
API Integration: Call multiple external APIs without overwhelming them
Background Jobs: Queue and execute background tasks in web applications
Batch Operations: Perform bulk operations with controlled concurrency

Example: Controlled Web Scraping

import aiohttp
from coro_runner import CoroRunner

runner = CoroRunner(concurrency=5)  # Only 5 concurrent requests

async def fetch_url(url: str):
    async with aiohttp.ClientSession() as session:
        async with session.get(url) as response:
            return await response.text()

# Schedule 100 URLs but only 5 will run at once
urls = [f"https://api.example.com/data/{i}" for i in range(100)]
for url in urls:
    runner.add_task(fetch_url, args=[url])

Development and Contribution

Coro Runner is actively developed and welcomes contributions. The project uses Uv for dependency management and includes:

Comprehensive test suite with pytest
GitHub Actions for CI/CD
Docker support for isolated testing
Example applications demonstrating real-world usage

To contribute:

# Clone the repository
git clone https://github.com/iashraful/async-coro-runner.git
cd async-coro-runner

# Install dependencies
uv sync

# Run tests
uv run pytest -s

Project Links

GitHub Repository: iashraful/async-coro-runner
PyPI Package: coro-runner
Documentation: Full Documentation
Author: Ashraful Islam

Requirements

Python 3.12 or later
uv (for development)

Conclusion

Coro Runner provides a clean, simple abstraction over asyncio's task management, making it easier to build high-performance concurrent applications in Python. Whether you're building web scrapers, API integrations, or background job processors, Coro Runner helps you manage concurrency without the complexity.

The library's philosophy is clear: provide powerful concurrency control with the simplest possible API. With its growing feature set and active development, Coro Runner is positioned to become an essential tool for Python developers working with asynchronous code.

Give it a try in your next project, and experience the simplicity of managed async task execution!

Getting Help

Have questions or running into issues? Here's how to get help:

Issues: GitHub Issues
Discussions: Engage with the community on GitHub
Documentation: Check the docs folder for detailed guides

Stay Updated

⭐ Star the repository on GitHub to stay updated with the latest features and improvements!

Have you used Coro Runner in your projects? Share your experience in the comments below!

Building a Rock-Solid Home Server Backup Strategy - My 3-2-1 Approach

Mohamad Ashraful Islam — Tue, 05 Aug 2025 17:24:55 +0000

When you’re running a home server that stores your personal files, photos, media, and even services like Pi-hole or Jellyfin, a proper backup strategy isn’t optional—it’s essential. Data loss can happen due to hardware failure, accidental deletion, or even corruption. That’s why I follow a proven and practical method known as the 3-2-1 backup strategy.

In this blog post, I’ll walk you through how I’ve implemented this strategy using a combination of external SSD storage and network-based backups over SSH.

Originally Posted on Ashraful's Blog

What is the 3-2-1 Backup Strategy?

The 3-2-1 rule is a simple yet powerful backup principle:

3 copies of your data (1 primary + 2 backups)
2 different types of media (e.g., SSD, HDD, cloud, etc.)
1 copy stored offsite

This strategy reduces the risk of total data loss by spreading your backups across multiple locations and types of storage.

1. Primary Storage: My Home Server

My home server is the heart of my digital setup. It hosts:

A media server (Jellyfin)
Personal files and documents
Photos and videos (via Immich)
Various self-hosted services (like Pi-hole, Portainer, etc.)

This is where the primary copy of all my data lives.

2. Local Backup: External SSD with Rsync Script

To maintain a local backup, I’ve connected an external SSD directly to my home server.

The SSD is mounted and automatically recognized on boot.
I back up everything important to this drive using a Bash script powered by rsync.
A cron job or systemd timer can automate the execution of this script regularly.

Here’s a sample of the SSD backup script:

#!/bin/bash

SOURCE="/data"
DEST="/mnt/backup_ssd"

echo "Starting backup to external SSD..."
mkdir -p "$DEST"
rsync -azP --delete "$SOURCE/" "$DEST/"
echo "Backup to SSD completed."

Here is the actual script of mine. Github Repo

This makes sure the SSD always has the latest version of my data and also removes deleted files for consistency.

3. Network Backup: Remote Sync Over SSH with Variables

To fulfill the offsite part of the 3-2-1 strategy, I’ve also implemented a remote backup over my local network.

Here’s how it works:

I use a custom Bash script that uses rsync over SSH.
It pulls variables like source, destination, remote user, and host from the script, making it easy to reuse or tweak.

Here’s a sample of the SSH-based backup script:

#!/bin/bash

SOURCE="/data"
REMOTE_USER="user"
REMOTE_HOST="192.168.1.10"
REMOTE_PATH="/mnt/backup/data"

echo "Starting remote network backup..."
rsync -azP -e ssh "$SOURCE/" "$REMOTE_USER@$REMOTE_HOST:$REMOTE_PATH"
echo "Remote backup completed."

This ensures I’m keeping a secondary backup in a different physical location, even if it's just across the network.

Why This Setup Works for Me

Redundancy: With multiple local and remote backups, I have peace of mind even if one disk fails.
Speed: The SSD makes for quick restores, while SSH syncs avoid re-copying everything unnecessarily.
Privacy: Everything stays in my own network—no cloud involved.

Final Thoughts

Implementing a backup strategy might seem tedious at first, but trust me—it’s worth every bit of effort. Data loss can be painful and costly, especially when it comes to irreplaceable personal content.

By following the 3-2-1 strategy and using a mix of external SSDs and network-based backups, I’ve built a system that’s simple, reliable, and tailored to my setup. If you’re running a home server, I highly recommend investing time in your own backup plan—your future self will thank you.

Setting Up Pi-hole in Docker with Proper DNS Configuration

Mohamad Ashraful Islam — Tue, 05 Aug 2025 05:55:28 +0000

This guide walks through

Installing Pi-hole with Docker Compose
Ensuring port 53 is available
Disabling the system's DNS resolver if necessary
Configuring your router to use Pi-hole
Setting up local DNS entries (if you need)

📦 Step 1: Install Pi-hole Using Docker Compose

Create a docker-compose.yml file:

version: "3"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80"
      - "8443:443"
    environment:
      TZ: "Asia/Dhaka"
      WEBPASSWORD: "changeme"
    volumes:
      - "./etc-pihole/:/etc/pihole/"
      - "./etc-dnsmasq.d/:/etc/dnsmasq.d/"
    dns:
      - 127.0.0.1
      - 1.1.1.1
    cap_add:
      - NET_ADMIN

Then run:

docker compose up -d

🚪 Step 2: Make Sure Port 53 Is Available

Port 53 is critical for DNS. Run this to check if it's already in use:

sudo lsof -i :53

If you see something like systemd-resolved or named, you need to free that port.

🛑 Step 3: Disable the System DNS Resolver (If Needed)

On most Linux distros, systemd-resolved binds to port 53 by default.

To disable it:

sudo systemctl disable --now systemd-resolved

Also replace the symlink for /etc/resolv.conf:

sudo rm /etc/resolv.conf
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf

(You can also add a fallback like 8.8.8.8 if needed.)

🌐 Step 4: Configure Your Router to Use Pi-hole

To apply ad blocking to your whole network:

Log into your router admin page
Find the DHCP/DNS settings
Set Primary DNS to the IP of your Pi-hole server (e.g., 192.168.1.10)
Remove or override any secondary DNS that bypasses Pi-hole (like 8.8.8.8)

Now all devices will query Pi-hole for DNS.

🧭 Step 5: Configure Local DNS (And Why)

✅ Why Configure Local DNS?

Setting up local DNS allows you to:

Access devices by name (nas.local, printer.lan, etc.)
Avoid typing IP addresses manually
Make services on your home server feel more like the cloud

🔧 How to Do It

Go to Pi-hole Admin Panel → Local DNS → DNS Records
Add entries like:

movie.ashraful.dev → 192.168.10.10
nas.lan → 192.168.10.20

Test from any device:

ping movie.ashraful.dev

If it resolves, you're all set!

✅ Summary

Pi-hole in Docker is clean and powerful — just make sure port 53 is free.
Disable systemd-resolved if it blocks port 53.
Set your router’s DNS to point to Pi-hole to enable network-wide filtering.
Use local DNS to make your network smarter and easier to use.

Enjoy ad-free browsing across your entire network! 🧠🛡️

Fixing DNS Resolution After Disabling systemd-resolved for Pi-hole

Mohamad Ashraful Islam — Tue, 05 Aug 2025 04:49:15 +0000

However, after doing this, I ran into a strange issue: some Python programs (specifically those using dnspython) could no longer resolve domain names. Here's how I diagnosed and fixed the problem.

Originally Posted on Ashraful's Blog

🔍 The Problem

To route DNS through Pi-hole, I disabled systemd-resolved:

sudo systemctl disable --now systemd-resolved

My home server then used Pi-hole's IP (e.g., 192.168.10.10) as its DNS server. Most things worked fine — ping, curl, and dig had no issues.

But some Python code using dnspython threw an error like:

dns.resolver.NoNameservers: All nameservers failed to answer the query

Or even:

FileNotFoundError: [Errno 2] No such file or directory: '/etc/resolv.conf'

🧠 What’s Going On?

Many programs — including dnspython — read DNS server information directly from /etc/resolv.conf.

When systemd-resolved is active, /etc/resolv.conf is often a symlink to a dynamically generated file like:

/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

But once systemd-resolved is disabled, this symlink points to a non-existent file. Programs depending on it will fail to resolve any domains.

✅ The Fix

We need to replace the broken symlink with a static resolv.conf file that directly specifies our Pi-hole DNS.

1. Remove the broken symlink

sudo rm /etc/resolv.conf

2. Create a new static file

sudo nano /etc/resolv.conf

Paste your Pi-hole DNS IP (replace with your actual IP):

nameserver 192.168.10.10

Optionally, add a fallback:

nameserver 192.168.10.10
nameserver 8.8.8.8

Save and close the file.

3. (Optional) Prevent overwrites

To ensure no other service modifies it (e.g., NetworkManager):

sudo chattr +i /etc/resolv.conf

To remove the protection later:

sudo chattr -i /etc/resolv.conf

🧪 Test DNS Resolution

Using nslookup:

nslookup google.com

Using Python:

import dns.resolver
result = dns.resolver.resolve("google.com")
print(result[0])

If everything is working, you'll get a valid IP response.

🧵 Summary

Because I'm using Pi-hole as my network guardian, I wanted to disable any system-level DNS services that could bypass it. Disabling systemd-resolved was necessary — but it broke /etc/resolv.conf, which some programs still depend on.

By creating a manual resolv.conf that points to Pi-hole, I ensured full DNS functionality while keeping all traffic filtered and protected.

Happy tinkering! 🛠️🧠🔒

The Untold Story of My Home Server - A Journey Through Self-Hosted Services

Mohamad Ashraful Islam — Sun, 03 Aug 2025 05:17:15 +0000

Why a Home Server?

Before diving into the services, let’s talk about why I set up a home server. Cloud services like Netflix, Google Drive, or Evernote are convenient, but they come with recurring costs, privacy concerns, and dependency on someone else’s infrastructure. A home server lets me host my own media, back up my photos, manage my network, and even run custom apps—all on my terms. My setup runs on a (mini pc bought from Amazon) Ubuntu machine with Docker, making it easy to manage and scale. Here’s a look at the services that make it tick.

1. Immich: My Photo and Video Sanctuary

Immich is my go-to for backing up and managing photos and videos. Think Google Photos, but self-hosted, private, and free.

Why I Chose It: Immich offers automatic backups, face recognition, and a clean mobile app, all without sending my personal memories to the cloud. It’s perfect for keeping my family’s photos secure.
How It Works: I installed Immich via Docker, and it syncs photos and videos from my phone automatically over Wi-Fi. It organizes them by date, location, or people (using AI-based tagging), and I can access them from any device via a web interface or app.
My Experience: Immich has saved me from losing precious memories—like my kid’s first birthday video—while keeping them off Big Tech’s servers. The setup took some tweaking to get the AI features running smoothly, but it’s been worth it.

2. Jellyfin: My Personal Netflix

Jellyfin is the crown jewel of my home server, turning it into a media streaming powerhouse. This open-source media server lets me stream my collection of movies, TV shows, music, and even audiobooks to any device—my TV, phone, or laptop—without a subscription.

Why I Chose It: Unlike Plex, which has a freemium model with paid features, Jellyfin is 100% free and open-source. It gives me full control over my media library, with no cloud dependency.
How It Works: I store my media files (MP4s, MP3s, etc.) on the server’s hard drive. Jellyfin organizes them with metadata, album art, and subtitles, creating a sleek interface that rivals commercial streaming platforms. I access it via a web browser or Jellyfin’s apps on my devices.
My Experience: Setting up Jellyfin was a breeze with Docker. I love binge-watching my favorite shows on my Roku, knowing it’s all hosted at home. Plus, I can share my library with family without worrying about data leaks.

3. Cloudreve: My Personal Cloud Storage

Cloudreve is my Google Drive alternative, offering a self-hosted cloud storage solution for files, documents, and more.

Why I Chose It: Cloudreve is lightweight, supports multiple storage backends (like local drives or S3), and has a user-friendly interface. It’s perfect for accessing files from anywhere without relying on third-party cloud providers.
How It Works: I set up Cloudreve to store files on my server’s hard drive. It provides a web interface and WebDAV support, so I can upload, download, or share files securely. I also use it to back up important documents.
My Experience: Cloudreve has been a game-changer for sharing large files with friends or accessing work documents remotely. The setup was straightforward, though I had to configure SSL for secure access.

4. Pi-Hole: The Ad-Blocking Network Guardian

Pi-Hole is my network-wide ad and tracker blocker, making my internet experience faster and cleaner.

Why I Chose It: Pi-Hole blocks ads at the DNS level, meaning no pop-ups or video ads on any device connected to my network. It’s also a great way to monitor network activity.
How It Works: Running in a Docker container, Pi-Hole acts as my network’s DNS server. It filters out requests to known ad and tracker domains, replacing them with nothing. I pointed my router’s DNS settings to Pi-Hole, and it works seamlessly.
My Experience: The difference is night and day—web pages load faster, and YouTube is ad-free on my smart TV. The dashboard showing blocked domains is oddly satisfying to check.

5. Portainer: Keeping My Containers in Check

Portainer is my go-to tool for managing Docker containers, making it easy to monitor and control all the services on my server.

Why I Chose It: Portainer’s web-based interface simplifies Docker management, especially for someone like me who prefers a GUI over command-line tinkering.
How It Works: Portainer connects to my Docker environment and lets me start, stop, or update containers, check logs, and monitor resource usage. It’s like a control panel for my server’s services.
My Experience: Portainer has saved me countless hours of debugging. I can see at a glance if Jellyfin or Immich is acting up and restart containers with a click.

6. Nginx Proxy Manager: Simplifying Reverse Proxies

Nginx Proxy Manager makes it easy to manage reverse proxies, allowing secure access to my services with custom domains and SSL certificates.

Why I Chose It: Setting up reverse proxies manually with Nginx configs is a hassle. Nginx Proxy Manager’s graphical interface lets me configure proxies and SSL (via Let’s Encrypt) in minutes.
How It Works: I use it to route traffic to my services (e.g., jellyfin.mydomain.com to Jellyfin’s port). It handles SSL termination, ensuring secure connections.
My Experience: This was a lifesaver for accessing my services remotely without exposing ports to the internet. The setup was intuitive, and I love the clean dashboard.

7. Cockpit: Remote Management Made Easy

Cockpit is my tool for remotely managing my Ubuntu server, giving me a web-based interface to monitor and tweak system settings.

Why I Chose It: Cockpit is lightweight and integrates well with Ubuntu, offering a one-stop shop for system stats, updates, and user management.
How It Works: Running in a Docker container, Cockpit provides a dashboard to check CPU, memory, disk usage, and logs. I can also manage services or reboot the server remotely.
My Experience: Cockpit is my safety net when I’m away from home. I once fixed a stuck service while on vacation, all from my phone’s browser.

8. My Custom Note and Expense Tracking System: A Personal Touch

The final piece of my home server puzzle is a note and expense tracking system I built myself, tailored to my needs.

Why I Built It: I wanted a simple, private way to track daily notes and expenses without relying on apps like Notion or Mint, which store data in the cloud.
How It Works: Written in [insert language, e.g., Python with Flask or Node.js], it’s a web app running in a Docker container. It has a minimalist interface for adding notes (with tags and search) and logging expenses (with categories and monthly summaries). Data is stored in a local SQLite database.
My Experience: Building this was a labor of love. It’s not perfect, but it’s mine. I use it daily to jot down ideas or track spending, and it’s satisfying to know it’s fully under my control.

The Bigger Picture: Why This Matters

Running these services on my home server has been transformative. Jellyfin and Immich keep my media and memories safe and accessible. Cloudreve and my custom app handle my files and personal data without third-party snooping. Pi-Hole, Portainer, Nginx Proxy Manager, and Cockpit keep everything running smoothly and securely. Together, they’ve saved me money, boosted my privacy, and taught me valuable skills.

But beyond the tech, this setup is about empowerment. It’s about saying “no” to walled gardens and “yes” to owning your digital life. My server isn’t just a machine—it’s a statement that I can build, manage, and control my own corner of the internet.

Getting Started with Your Own Home Server

Inspired to start your own home server? Here’s a quick roadmap:

Hardware: Start small with a Raspberry Pi, an old PC, or a dedicated NAS.
OS: Use Ubuntu Server or a NAS-focused OS like TrueNAS for ease of use.
Docker: Learn Docker to simplify service deployment (Portainer makes this easier).
Services: Pick one or two services (like Jellyfin or Pi-Hole) and expand from there.
Community: Join communities like r/homelab or r/selfhosted on Reddit, or follow home server discussions on X for tips and inspiration.

Conclusion: The Heart of My Digital Home

My home server is more than a collection of services; it’s a reflection of my desire for independence, creativity, and control. From streaming movies with Jellyfin to tracking expenses with my custom app, every service tells a story of problem-solving and discovery. If you’re curious about home servers, I encourage you to dive in. Start small, experiment, and join the growing community of self-hosters. What’s your home server story? Let me know in the comments or on X!

Did you know docker-compose only takes environment variables from`.env` only?

Mohamad Ashraful Islam — Sun, 11 Jun 2023 05:25:45 +0000

Recently I have encountered an issue with docker compose. I have separated the environment files and declared todocker-compose.yaml like following,

    env_file:
      - .dev_env

When I ran docker compose up, it was not working on the compose itself but the container. because of environment variables. Then I found following solution for this.

docker compose --env-file .dev_env --env-file .prod_env up

Windows is not that bad for software development

Mohamad Ashraful Islam — Fri, 01 Jul 2022 17:34:06 +0000

Today it's not about virtualbox/vmware. It's a new Windows 10 feature. They called it WSL(Windows Subsystem for Linux)

Originally Posted on HERE

What is WSL?

Already told Windows Subsystem for Linux. Windows made sure to install Linux operating system inside the Windows environment without extra virtualization software(Virtual Box, VmWare, ...). So, How they did that?? That's burning question. Today I'll not go that way. But one thing I can tell that is, they slightly modified the kernel to fit with windows. Isn't it awesome?? YES! I am really exited to share about it.

What we are going to cover today?

Prerequisites
Enable WSL.
Install Ubuntu (22.04 Maybe).
Set WSL Resource.
Install Docker on Ubuntu.
VSCode WSL development.
Intellij IDE WSL development.

Prerequisites

You must be running Windows 10 version 2004 and higher (Build 19041 and higher) or Windows 11.

To check your Windows version and build number, select Windows logo key + R, type winver, select OK.

Enabling WSL

You can enable from GUI as well as from Powershell. I always prefer the hard way(command line). So, Run the following commands on Powershell.

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

Enabling the Virtualization Technology

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Now you need to restart the machine.

Install WSL Update

Downthe the update installer from here and Run the installer.

Set WSL2 as default WSL version.

wsl --set-default-version 2

Update existing distribution (if any)

wsl --set-version <distribution name> 2

Install Ubuntu (22.04)

There are several ways to install the OS in WSL. You can download from the Windows Store. This is the hassel free process. Once installed you will be able to login using your given password. Don't afraid, there is no UI. Only command line like Ubuntu Server :)

Now open Powershell again,

wsl -l -v

You will get something like following,

Set WSL Resource

Yes. You can still have chance to modify your resource allocation. Otherwise your windows will decide to do so. The process is pretty simple. You need to create a file to a specific location.

Open the file,

notepad "$env:USERPROFILE\.wslconfig"

Add these lines to the editor and save it.

[wsl2]
memory=4GB  
processors=4

You can read the microsoft's document for more configuration.

Now login to the ubuntu again, with Powershell/CMD whatever shell you have.

wsl

Install Docker on WSL(Ubuntu)

It's not mandatory. So, don't push yourself into Docker if your are not a Docker guy.

Installing Docker is same guide as ubuntu. You can follow the official Docker docs OR blindly follow me. Run the following commands on the Ubuntu's terminal not Powershell.

Update the apt package index and install packages to allow apt to use a repository over HTTPS:

$ sudo apt update
$ sudo apt install \
   ca-certificates \
   curl \
   gnupg \
   lsb-release

Add Docker’s official GPG key:

$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Use the following command to set up the repository

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Install Docker Engine

$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Start the docker and check

$ sudo service docker start
$ sudo service docker status

Test your docker installation

$ sudo docker run hello-world

Output:

So, Docker is working.

Incase any Network issue from WSL

$ echo -e "[network]\ngenerateResolvConf = false" | sudo tee -a /etc/wsl.conf
$ sudo unlink /etc/resolv.conf
$ echo nameserver 1.1.1.1 | sudo tee /etc/resolv.conf

IPTables related issues

I found some people have iptables related errors. So I recommend the following command and choose legacy

$ update-alternatives --config iptables

Setting up VSCode

Actually there is nothing to setup. Trust me and do the following things,

You just need to install an extension. You can get it from here.
Create a project on WSL(ubuntu)
On the bottom left corner you will see remote development button.
Select New WSL Window
Open the project from WSL(Ubuntu)

Now it's all yours.

Setting up Intellij IDE (Pycharm in my case.)

Using Intellij IDE (Pycharm) codes stays on the windows machine.
Interpreter(Environment) will be just shared from WSL. The step by step guide is here.

Conclusion

I've talked too much today. But it made me to do so. But, Why I am writing this post?

In short, After 7-8 years I have been trying windows 10. I am so pleased to see the WSL and how it works. So, I thought people may like it too. Thank you.

DEV Community: Mohamad Ashraful Islam

How I Built My Personal Blog Using the DEV.to API

The Problem

Why I Chose DEV.to

The Architecture

Fetching Articles

Loading a Single Blog Post

Rendering Markdown

My Publishing Workflow

Benefits of This Approach

Single Source of Truth

No Duplicate Work

Better SEO

Custom Design

Performance Considerations

Error Handling

Why I Like This Setup

Could You Do the Same?

Final Thoughts

What Is Load Balancing? A Beginner's Guide to Faster and More Reliable Applications

What Is Load Balancing?

Horizontal vs Vertical Scaling

Why Do We Need Load Balancing?

A Real-Life Example

How Load Balancing Works

Load Balancing Algorithms

1. Round Robin

Advantages

Disadvantages

2. Least Connections

3. Least Response Time

4. Weighted Round Robin

5. IP Hash

Health Checks

Session Persistence (Sticky Sessions)

Hardware vs Software Load Balancers

Hardware Load Balancers

Advantages

Disadvantages

Software Load Balancers

Advantages

Load Balancing in Docker

Load Balancing in Kubernetes

Benefits of Load Balancing

Common Misconceptions

"A load balancer makes my application faster."

"One server is enough forever."

"Load balancing replaces backups."

When Do You Need Load Balancing?

Conclusion

Linux Backup Strategies: Beyond Just `rsync`

Why Backups Matter

What Makes a Good Backup?

The 3-2-1 Backup Rule

Understanding rsync

The Problem with rsync

Versioned Backups

Incremental Backups

Differential Backups

Snapshot-Based Backups

Archive Backups with tar

Remote Backups

Cloud Backups

Encrypt Your Backups

Automating Backups

Cron

Systemd Timers

Docker Backup Strategies

Verify Your Backups

Recommended Backup Tools

A Practical Home Server Backup Strategy

Daily

Weekly

Monthly

Common Backup Mistakes

Conclusion

How Reverse Proxies Actually Work (And Why Every Self-Hosted Server Needs One)

What Is a Reverse Proxy?

Reverse Proxy vs Forward Proxy

Forward Proxy

Understanding `rsync`

The Problem with `rsync`

Archive Backups with `tar`