DEV Community: Lau!

Developer Journal day4..Deploying a Hyperledger Fabric Network on Kubernetes — From Zero to Production-Ready published

Lau! — Sun, 17 May 2026 05:35:38 +0000

Blockchain infrastructure is hard. Running it on Kubernetes is even harder. In this article I'll walk you through how I built a production-ready Hyperledger Fabric network on Kubernetes, including automated deployment scripts, network configuration, and the security decisions I made along the way.

🧠 Why Hyperledger Fabric + Kubernetes?
Hyperledger Fabric is the go-to permissioned blockchain framework for enterprise use cases — supply chain, financial services, healthcare. Unlike public chains, you control who participates.
Kubernetes brings what Fabric alone can't give you out of the box:

Self-healing — pods restart automatically on failure
Scalability — spin up more peers as needed
Declarative infrastructure — everything is a manifest
Namespace isolation — clean separation between components

The combination is powerful, but the learning curve is steep. Here's what I built and what I learned.

🏗️ Architecture Overview
The network consists of:
ComponentRoleOrdererOrders transactions and creates blocks (RAFT consensus)PeersEndorse and commit transactions, host the ledgerCA (Certificate Authority)Issues identities for all participantsKubernetes JobsHandle one-time setup tasks (channel creation, chaincode install)
All components live inside a dedicated fabric namespace in Kubernetes, with strict network policies controlling traffic between them.

📁 Project Structure
fabric-k8s/
├── manifests/
│ ├── orderer/
│ ├── peers/
│ ├── ca/
│ └── jobs/
├── scripts/
│ ├── deploy.sh # Main entrypoint
│ └── utils.sh # Helpers: logging, wait functions
├── config/
│ └── configtx.yaml # Network genesis config
└── .env.example # Environment template (no secrets committed)

⚙️ Automated Deployment Scripts
One of the things I'm most proud of in this project is the deploy automation. Rather than running kubectl apply commands manually and hoping for the best, I built a script system with proper logging, error handling, and readiness checks.
Logging with Color
bashRED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
CYAN='\033[0;36m'
NC='\033[0m'

info() { echo -e "${GREEN}[INFO]${NC} $1"; }
warn() { echo -e "${YELLOW}[WARN]${NC} $1"; }
step() { echo -e "\n${CYAN}▶ $1${NC}"; }
error() { echo -e "${RED}[ERROR]${NC} $1"; exit 1; }
Simple but effective — every log line is color-coded by severity, so you know at a glance what's happening during a deploy.
Waiting for Deployments
One of the trickiest parts of Kubernetes automation is knowing when something is actually ready. I wrote a waitDeployment() function that uses kubectl rollout status with a timeout:
bashwaitDeployment() {
local NAME=$1
info "Waiting for deployment/$NAME..."
kubectl rollout status deployment/"$NAME" \
-n "$NAMESPACE" --timeout=120s || error "Timeout on $NAME"
}
Waiting for Jobs
Channel creation and chaincode installation run as Kubernetes Jobs. These need their own wait logic:
bashwaitJob() {
local NAME=$1
info "Waiting for job/$NAME..."
kubectl wait job/"$NAME" \
-n "$NAMESPACE" \
--for=condition=complete \
--timeout=300s || {
warn "Job $NAME timed out. Checking logs..."
kubectl logs -n "$NAMESPACE" -l app="$NAME" --tail=50
error "Job $NAME failed"
}
}
Notice that on failure, it automatically dumps the last 50 lines of logs — no need to manually kubectl logs when something breaks at 2am.

🔐 Network Configuration — The Orderer
The orderer is the most critical component: it's the one that decides the order of transactions across the entire network. I used RAFT consensus (as opposed to the deprecated Solo mode) which means multiple orderer nodes vote on block ordering.
Key configuration decisions:

TLS enabled on all orderer-to-peer communication
Mutual TLS (mTLS) for admin operations
Resource limits set to prevent one noisy component from starving others
Persistent volume for the ledger data (not ephemeral storage)

📦 Kubernetes Manifests
Each component has its own manifest directory. An example of the security-conscious securityContext I applied to every pod:
yamlsecurityContext:
runAsNonRoot: true
runAsUser: 1000
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
No pod runs as root. No pod can escalate privileges. This is table stakes for anything production-adjacent.
Network Policies
Every component is locked down with NetworkPolicy — only the pods that need to talk to the orderer can reach it:
yamlapiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: orderer-ingress
namespace: fabric
spec:
podSelector:
matchLabels:
app: orderer
ingress:
- from:
- podSelector:
matchLabels:
role: peer
ports:
- port: 7050

🔒 Security Decisions
A few things I was deliberate about:

No secrets in the repo — certificates, keys, and passwords are loaded from environment variables and Kubernetes Secrets, never committed to Git.
.env.example pattern — I commit a template with empty values so collaborators know what's needed without exposing real data.
Private repository — the repo stays private; only collaborators with explicit access can see it.
Pre-deploy validation — the script checks for kubectl availability and cluster connectivity before touching anything.

bashwhich kubectl > /dev/null 2>&1 || error "kubectl not found"
kubectl cluster-info > /dev/null 2>&1 || error "No cluster connection"
Fail fast, fail loud.

🧗 Challenges & What I Learned
Crypto material management is the #1 pain point in Fabric. The cryptogen tool generates a mountain of certificates and keys, and keeping track of which cert goes where (and making sure they match between components) took significant debugging time.
RAFT leader election surprised me — during initial setup, if the orderer pods don't all come up within the election timeout, the network never bootstraps. Adding proper readiness probes and the waitDeployment() timeout logic solved this.
Kubernetes Jobs for one-time operations (channel creation, anchor peer updates) was a pattern I hadn't used much before. It's elegant — idempotent, tracked by Kubernetes, with built-in retry logic.

🚀 What's Next

Add Prometheus + Grafana dashboards for peer/orderer metrics
Implement Sealed Secrets or Vault for crypto material management
Write chaincode in Go and deploy it through the pipeline
Add CI/CD with GitHub Actions to automate manifest linting and test deploys

💬 Final Thoughts
This project pushed me across infrastructure, cryptography, distributed systems, and DevOps simultaneously. If you're exploring enterprise blockchain or want to see how Fabric actually runs in a cloud-native environment, I hope this breakdown gives you a useful starting point.
The full project (minus secrets, of course) is on my GitHub. Feel free to open an issue or reach out if you have questions.

Developer Journal Day3.. 🏎️ On-Chain vs Off-Chain Payments for a VIP Car Collection Platform — What would you choose?

Lau! — Tue, 12 May 2026 16:29:08 +0000

I'm currently building a mini project focused on a VIP car collection inventory platform
designed for high-end clients who own and manage luxury or classic vehicle portfolios.

One of the most critical architectural decisions right now is defining the payment system.
Since the project is blockchain-oriented and built around Hyperledger Fabric, I'm evaluating
two different approaches and I'd love to hear from the community.

🔵 Option A — Native Token System (On-Chain)

Create a native credit token inside the Fabric network:

Clients deposit real money → tokens are issued to their wallet
Platform services consume those tokens
Think ERC-20 logic, but implemented natively in Hyperledger Fabric
Creates a fully on-chain payment ecosystem

🟢 Option B — Off-Chain Payments + On-Chain Verification

Payments happen externally through traditional methods (Stripe, bank transfer, etc.):

The blockchain only stores a "payment_confirmed" event
A hash of the payment receipt is recorded on-chain for auditability
Keeps the chain lean; complexity lives in proven, off-chain infra

💬 What I'd like feedback on

Which architecture is more realistic for production?
Which offers better scalability and maintainability long-term?
Which would be more attractive to VIP/high-end clients?
Does a fully on-chain payment experience actually add value in this type of app, or is it over-engineering?
From a software engineering perspective — which would you personally choose and why?

Opinions, technical feedback, architecture suggestions, or hybrid alternatives are all welcome.

Drop your thoughts below 👇

Developer journal day2. Building CarVault 🚗

Lau! — Sat, 09 May 2026 23:49:42 +0000

I’ve been working on CarVault, a VIP car collection inventory platform designed for luxury and high-end vehicle collectors.

****** WEB APLICATION ****
https://carvault-1ay8g63.public.builtwithrocket.new

The project combines:

Hyperledger Fabric
Blockchain architecture
Inventory management
Payment systems
Docker infrastructure
Premium UI/UX

Instead of building a traditional inventory system, the goal is to create a secure and auditable platform capable of handling:

Vehicle ownership history
VIP client management
Immutable audit records
Payment verification
Blockchain-based asset tracking

Current architecture direction:

Frontend UI
    ↓
Backend API
    ↓
Hyperledger Fabric
    ↓
Chaincode + Ledger

At the moment, I’m working on:

Hyperledger Fabric integration
Docker network setup
Chaincode structure
Payment architecture research

The current website represents the visual experience and concept design of the platform.

The full technical implementation — including Hyperledger Fabric integration, Docker infrastructure, backend logic, and chaincode development — will be available separately through my GitHub portfolio as the project evolves.

The visual experience will eventually become the frontend connected to the blockchain backend.

This project is still evolving, but it’s becoming an exciting mix of system design, enterprise blockchain, and luxury-tech concepts.

More updates soon.

Developer Journal..“My First Docker + Nginx Setup on Ubuntu”

Lau! — Fri, 08 May 2026 18:59:40 +0000

Hello Everyone!

A while ago, I decided to learn Docker and, honestly, it turned out to be much simpler than I expected. In this article, I’ll walk you through how I configured Docker on Windows using WSL (Windows Subsystem for Linux) and ran my very first container.

If you're a developer using Windows and want to get into Docker, this post is for you.

Spoiler: At the end, you’ll see the Nginx welcome page in your browser — and that feeling is amazing 🎉

What is Docker? (In Simple Terms)

Docker is a platform that allows you to package your application inside a “container” — an isolated and portable environment that behaves the same way on any machine.

Think of it as a sealed box containing everything your app needs to run.

Prerequisites

Before getting started, you’ll need:

✅ Windows 10 or 11
✅ WSL (Windows Subsystem for Linux) enabled
✅ A Linux distribution installed (we’ll use Ubuntu)
✅ PowerShell running as Administrator
Step 1: Verify and Install WSL

WSL allows you to run Linux commands directly on Windows. Let’s first verify whether it’s installed.

Option A: List all available distributions
wsl --list --online

This command will show all Linux distributions available for installation.

Option B: Install Ubuntu on WSL (if you don’t already have it)
wsl --install -d Ubuntu
Option C: Check installed distributions
wsl --list --verbose

This command is very useful because it shows the state and version of each installed distribution.

Step 2: Open Ubuntu in WSL

From PowerShell, type:

wsl -d Ubuntu

You should see something like:

user@PC:~$

Congratulations! You are now inside Ubuntu. From this point on, all commands will be Linux commands.

Step 3: Verify and Install Docker

First, let’s check if Docker is already installed:

docker --version

If Docker is not installed, you’ll see a message suggesting available packages. Install it with:

sudo apt-get install docker.io -y

The -y flag automatically answers “yes” to confirmation prompts, saving time.

Verify the installation
docker --version

You should see something like:

Docker version 24.0.x
Step 4: Enable and Start the Docker Service

Docker is now installed, but we still need to start the service.

Enable Docker to start automatically
sudo systemctl enable docker
Start the service immediately
sudo systemctl start docker
Step 5: Fix Permission Errors

If you encounter an error like this while running Docker commands:

PERMISSION DENIED WHILE TRYING TO CONNECT TO THE DOCKER API AT UNIX:///VAR/RUN/DOCKER.SOCK

Don’t worry! This is completely normal. Docker requires special permissions.

Add your user to the Docker group:

sudo usermod -aG docker your_user

Replace your_user with your Linux username.

Now you have two options:
Option 1 (Recommended): Close and reopen Ubuntu
exit

Then reopen it from PowerShell:

wsl -d Ubuntu
Option 2: Activate the group immediately
newgrp docker
Verify everything works
docker ps

If you see an empty table with headers like CONTAINER ID, IMAGE, etc., Docker is working correctly 🎉

Step 6: Run Your First Container (Nginx)

Here comes the fun part. Let’s run Nginx, one of the most popular web servers:

docker run -d -p 8080:80 nginx
What does this command do?
docker run → Runs a container
-d → Runs it in detached mode (background)
-p 8080:80 → Maps port 8080 on your machine to port 80 inside the container
nginx → The image you want to run (Docker will download it automatically)

You should see something similar to:

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
Digest: sha256:abc123...
Status: Downloaded newer image for nginx:latest
a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

That last string is your container ID.

Your container is now running 🚀

Step 7: Verify the Container is Running
docker ps

You should see your container listed with the status Up.

Step 8: The Best Part — Open it in Your Browser

Open any browser on Windows (Chrome, Firefox, Edge, etc.) and go to:

http://localhost:8080

If everything worked correctly, you’ll see the beautiful Nginx welcome page saying:

“Welcome to nginx!”

That feeling when you realize everything is actually working is incredible 🚀

Additional Useful Commands

Here are a few Docker commands you’ll probably want to know:

View all containers (including stopped ones)
docker ps -a
Stop a container
docker stop CONTAINER_ID
Remove a container
docker rm CONTAINER_ID
View container logs
docker logs CONTAINER_ID
Lessons Learned

✅ WSL is essential: Without WSL, Docker on Windows can feel complicated. With WSL, the experience becomes much smoother.

✅ Permissions matter: “Permission Denied” errors are completely normal. It’s not a broken installation — you just need the correct user group permissions.

✅ Docker is beginner-friendly: The Docker ecosystem has done an excellent job making containerization accessible.

✅ Documentation is your best friend: If something breaks, check the logs using docker logs.

What’s Next?

Now that Docker is working, you can:

Build your own Dockerfile for a personal application
Explore Docker Hub and discover thousands of pre-configured images
Learn Docker Compose for multi-container orchestration
Publish your own images on Docker Hub
Final Thoughts

My first experience with Docker on Windows was honestly great.

The process is clear, well documented, and most importantly — you get immediate results. And that’s one of the best ways to learn.

If you’re thinking about learning Docker:

Don’t wait any longer.

The journey into containerization begins with a simple:

docker run

Have questions? Ran into problems? Share your experience in the comments — I’d love to hear about your first Docker setup too 💙

References & Resources
Docker Official Documentation
WSL Documentation
Docker Hub

Don’t touch Fabric unless you’re ready for distributed headaches 😵‍💫

Lau! — Fri, 08 May 2026 16:02:48 +0000

Building a VIP Vehicle Inventory System with Hyperledger Fabric 🚗

I recently started designing a new blockchain project focused on managing exclusive vehicle inventories for VIP collectors using Hyperledger Fabric.

The idea is to build a permissioned system where verified members, dealers and validators can securely manage high-value vehicle assets, ownership history and inventory access while keeping sensitive data private.

One thing I’m realizing very quickly is that Fabric is very different from typical blockchain development.

At first, concepts like:

MSPs
endorsement policies
peers
orderers
private data collections

felt less like blockchain and more like trying to assemble enterprise IKEA furniture without instructions 😵‍💫

But the deeper I go, the more I understand why enterprise blockchain architecture requires this level of structure and permission management.

Right now I’m focusing on:

defining actors and trust models
modeling business logic
planning chaincode structure
understanding what belongs on-chain vs off-chain

Still early in development, but excited to keep building and documenting the process.

Hyperledger #Fabric #Blockchain #Web3 #SmartContracts