DEV Community: MD. HABIBULLAH SHARIF

Cut the Noise: The 10 Web Frameworks That Actually Matter in 2026

MD. HABIBULLAH SHARIF — Tue, 02 Jun 2026 13:14:40 +0000

Every six months, someone asks the same question.

"Which framework should I learn?" And every six months, the internet gives them 50 conflicting opinions, outdated blog posts, and at least one person telling them to learn a framework with 200 GitHub stars and one contributor.

This guide isn't that.

This is a practical breakdown - what each framework actually does, who it's for, and which one you should pick today based on your situation. Backed by the Stack Overflow Developer Survey 2025 and Statista market research. No filler. No hype. Just honest picks.

Before You Pick Anything - Answer These Three

Platform? - Frontend web, backend API, mobile, or full-stack?
Language? - What do you already know? Don't learn a new language and a new framework at the same time.
Scale? - Weekend project or enterprise system? Your answer changes everything.

Got it? Good. Let's get into it.

1. React - The Undisputed King of Frontend

Best for: Frontend developers, anyone entering the job market, UI-heavy applications

React is not the newest. It's not the most elegant. But it is the most employable. The job market for React developers is larger than the next three frontend frameworks combined - that's not an opinion, that's survey data.

Facebook (Meta) built it to handle massive UI complexity at scale. The component model and unidirectional data flow changed how the entire industry thinks about frontend.

Why it wins:

Largest frontend ecosystem on the planet - UI libraries, state managers, testing tools
React Native lets you take the same mental model to mobile
Every major tech company uses it - Meta, Airbnb, Netflix, Uber
The sheer volume of tutorials, courses, and StackOverflow answers is unmatched

Watch out for: React is a library, not a full framework. You'll still need to make decisions about routing, state, and data fetching. That flexibility is a feature - but it can overwhelm beginners.

function Welcome({ name }) {
  return <h1>Hello, {name}</h1>;
}

Pick React if: You're entering the job market, building a UI-heavy app, or want the widest possible career options.

2. Next.js - React's More Serious Sibling

Best for: Full-stack developers, production web apps, SEO-critical projects

Next.js is what happens when you take React and give it a proper framework - routing, server-side rendering, API routes, image optimization, and edge deployment out of the box.

In 2026, if you're building a real web product with React, you're probably building it with Next.js. Vercel (who maintains it) has made deployment a one-command experience.

Why it wins:

SSR and SSG solve React's SEO problem completely
App Router makes full-stack feel natural - one project, frontend and backend
Edge and serverless deployment with zero config
Built-in image and font optimization - performance by default

Watch out for: The App Router (new) vs Pages Router (old) divide still confuses developers. The mental model shift between server components and client components takes time.

npx create-next-app@latest my-app

Pick Next.js if: You need SEO, you're building a production product on React, or you want full-stack without managing a separate backend.

3. Express.js - The Minimal Backend Standard

Best for: Backend APIs, Node.js developers, microservices, developers who want control

Express is 15+ years old and still the most downloaded backend framework on npm. There's a reason - it stays out of your way.

No opinions about your folder structure. No forced architecture. You define exactly what your server does and how.

Why it wins:

Absurdly lightweight - the core is just request/response middleware
Massive middleware ecosystem (Passport, Multer, Helmet, etc.)
You already know JavaScript - no new language to learn
Perfect for REST APIs, GraphQL servers, and microservices

Watch out for: Express gives you nothing beyond routing and middleware. You'll write more boilerplate than opinionated frameworks. For large teams or complex apps, that freedom becomes a maintenance burden fast.

const express = require('express');
const app = express();

app.get('/api/users', (req, res) => {
  res.json({ users: [] });
});

app.listen(3000);

Pick Express if: You want full control over your Node.js backend, you're building a lightweight API, or you're learning server-side JavaScript.

4. ASP.NET Core - Enterprise's Favorite

Best for: Enterprise backend, .NET developers, high-performance APIs, cloud-native systems

Microsoft rebuilt .NET from scratch and made it cross-platform, open-source, and fast. ASP.NET Core now regularly benchmarks in the top 3 fastest web frameworks globally - above Node.js, above most Go frameworks.

If your company runs on Azure or the Microsoft ecosystem, this is the default serious choice.

Why it wins:

Exceptional performance - handles massive concurrent load efficiently
First-class Azure integration (App Service, Functions, Service Bus)
Built-in dependency injection, middleware pipeline, and security features
C# is a productive, strongly-typed language with excellent tooling

Watch out for: The ecosystem and job market are concentrated in enterprise environments. If you're building a startup MVP or an indie project, this is heavier than you need.

Pick ASP.NET Core if: You're working in enterprise, your team knows C#, or you're building high-traffic APIs on Azure.

5. Angular - Enterprise's Complete Toolkit

Best for: Large teams, complex enterprise frontends, developers who want every decision made for them

Angular is not a library. It's a complete platform - routing, forms, HTTP, testing, and state management all included and all opinionated. Google builds it. Google uses it. The entire Google Workspace suite runs on Angular.

Why it wins:

Everything is standardized - large teams don't argue about architecture
TypeScript is mandatory (which is a feature, not a bug)
CLI generates consistent code structure across the entire codebase
Dependency injection system is genuinely powerful for complex apps

Watch out for: The learning curve is steep. The boilerplate is real. For small projects, Angular will feel like driving a semi-truck to get groceries. It earns its complexity at scale.

Pick Angular if: You're on a large enterprise frontend, your team is 5+ developers, or you want a framework that makes all the architecture decisions for you.

6. Django - Python's Fastest Path to Production

Best for: Python developers, data-adjacent apps, rapid MVP development, teams that want built-in security

Django's tagline is "the web framework for perfectionists with deadlines." That's not marketing - it's accurate.

Authentication system? Built in. Admin dashboard? Built in. ORM? Built in. CSRF protection? Built in. You can go from django-admin startproject to a working CRUD app with login in under an hour.

Why it wins:

Batteries-included means less glue code and fewer decisions
Built-in admin panel is genuinely useful for internal tools and data management
Perfect for data science teams already working in Python
Django REST Framework (DRF) makes API development fast and consistent

Watch out for: Django's ORM can generate inefficient SQL at scale. For high-performance, heavily async workloads, FastAPI is often the better Python choice in 2026.

from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)
    published = models.DateTimeField(auto_now_add=True)

Pick Django if: You're a Python developer, you're building a data-heavy app, or you need to ship an MVP fast without reinventing the wheel.

7. Laravel - PHP Done Right

Best for: Full-stack PHP developers, startups, agencies, rapid product development

PHP has a reputation. Laravel doesn't deserve to share it. It is, honestly, one of the most elegant and productive frameworks in any language.

Eloquent ORM, built-in authentication scaffolding, job queues, broadcasting, file storage - and Livewire for reactive UI without writing JavaScript. The developer experience is exceptional.

Why it wins:

Eloquent ORM has the cleanest syntax of any major ORM
Laravel ecosystem (Forge, Vapor, Cashier) covers nearly every app need
Livewire lets you build reactive UIs without touching JavaScript
Extremely cost-effective hosting - PHP runs everywhere, cheaply

Watch out for: PHP's reputation keeps some developers away - their loss. Laravel is also not the right choice for high-concurrency real-time applications.

Pick Laravel if: You know PHP, you're building a web product for a client or startup, or you want maximum productivity with a polished full-stack ecosystem.

8. Flutter - One Codebase, Native Everywhere

Best for: Mobile developers, cross-platform apps (iOS + Android), teams that can't maintain two native codebases

Flutter is Google's answer to "why are we writing this twice?" You write Dart, Flutter renders native-looking components on iOS, Android, web, and desktop from the same codebase.

Unlike React Native, Flutter draws every pixel itself - making it fast and visually consistent across platforms.

Why it wins:

True cross-platform from a single codebase - not a compromise
Hot reload in development is one of the best DX experiences in mobile
Used in production at Google, BMW, Alibaba
Strong Material Design and Cupertino widget libraries included

Watch out for: Dart is a language you'll need to learn. The web target isn't great for SEO-heavy sites. Deep platform-specific integrations still require native code.

Pick Flutter if: You're building a mobile app and can't maintain two native codebases, or you want to ship iOS and Android fast without doubling your team.

9. Vue.js - React's Friendlier Competitor

Best for: Developers new to frontend frameworks, teams migrating from jQuery, projects that want progressive adoption

Vue is the framework people reach for when React feels like too much. The learning curve is genuinely lower, the documentation is the best in the frontend world, and the single-file component format keeps your template, script, and styles clean in one file.

Vue 3 with the Composition API is a different product from Vue 2 - faster, more TypeScript-friendly, more scalable.

Why it wins:

Documentation is world-class - the best in any major frontend framework
Progressive adoption - drop a <script> tag into an existing project and you're already using Vue
Nuxt.js (the Vue equivalent of Next.js) is mature and production-ready
Less opinionated than Angular, more structured than raw React

Watch out for: Vue's job market is smaller than React's in North America and Western Europe. In Asia - especially China - Vue is dominant. Know your target market.

Pick Vue if: You're learning your first frontend framework, you're coming from jQuery or plain HTML/JS, or you're building for a market where Vue is strong.

10. Spring Boot - The Java Enterprise Standard

Best for: Java developers, large enterprise systems, microservices architectures, financial and banking systems

Spring Boot is what you use when the stakes are high, the team is large, and the system needs to run reliably for 10 years. Banks, insurance companies, large e-commerce platforms, and government systems run on Spring Boot worldwide.

The auto-configuration system makes the sprawling Spring ecosystem approachable - add a dependency, Spring Boot wires it up.

Why it wins:

Rock-solid, battle-tested, runs in production at massive scale
First-class microservices support - service discovery, circuit breakers, API gateways
Deep integration with cloud-native patterns (Spring Cloud, Kubernetes)
Java salaries in enterprise backend are consistently high

Watch out for: Startup time and memory footprint are higher than modern alternatives. For serverless or rapid-scaling systems, look at Quarkus or Micronaut instead. Spring Boot is for when scale is a known quantity.

Pick Spring Boot if: You're a Java developer, you're building an enterprise system, or you work in fintech, insurance, or large-scale e-commerce.

Quick Decision Table

Framework	Language	Pick When
React	JS / TS	Frontend, job market, UI apps
Next.js	JS / TS	Full-stack, SEO matters, production web
Express.js	Node.js	Lightweight APIs, full control
ASP.NET Core	C#	Enterprise backend, Azure, high performance
Angular	TypeScript	Large teams, complex enterprise frontend
Django	Python	Python stack, rapid development, data-heavy
Laravel	PHP	PHP stack, agencies, elegant full-stack
Flutter	Dart	Cross-platform mobile, single codebase
Vue.js	JS / TS	Beginner-friendly frontend, Nuxt apps
Spring Boot	Java	Enterprise, microservices, finance/banking

The Honest Rule

There is no "best" framework. There's only the best one for your specific situation.

If you already know Python, pick Django. If you're chasing jobs, learn React. If you're building a mobile app alone, Flutter saves you months. If your employer runs Java, Spring Boot is your world.

The mistake developers make is treating this as a philosophical debate. It's not. It's an engineering decision. Pick the one that matches your language, your platform, and your scale. Get good at it. Ship something.

That's the whole answer.

What framework are you currently building with? Drop it in the comments - genuinely curious what the dev.to crowd is reaching for in 2026.

MD. HABIBULLAH SHARIF - Full-Stack & DevOps Engineer. More at habibullah.dev

Code Never Runs First - The Lexer and Parser Do

MD. HABIBULLAH SHARIF — Wed, 27 May 2026 15:19:05 +0000

Your code doesn't run the way you wrote it.

Before the machine executes a single instruction, your source file passes through a pipeline. Two of the most important stages in that pipeline are things most developers never think about — the lexer and the parser.

Every syntax error you've ever seen was one of them catching something. Every IDE that highlights keywords differently from variable names is using one right now.

Let's break down what they actually do.

What Is a Lexer?

The lexer (also called a tokenizer or lexical analyzer) is stage one. It takes your raw source code — just a stream of characters — and breaks it into meaningful units called tokens.

Think of it like reading a sentence. Before you understand grammar, you first recognize individual words. The lexer does that for code.

Take this:

x = 5 + 10;

The lexer scans it character by character and produces:

[ID: "x"]  [ASSIGN: "="]  [NUM: "5"]  [PLUS: "+"]  [NUM: "10"]  [SEMICOLON: ";"]

Each token has a type (what category it belongs to) and a value (the actual text). Keywords, operators, identifiers, literals, punctuation — the lexer categorizes all of it.

What it does NOT do: care whether those tokens make any sense together. That is the next stage's problem.

What Is a Parser?

The parser is stage two. It takes the token stream from the lexer and tries to make structural sense of it. It checks whether those tokens follow the grammar rules of the language, and if they do, it builds an Abstract Syntax Tree (AST) — a hierarchical structure that represents what your code actually means.

The analogy holds here too. The lexer identifies parts of speech. The parser checks if those parts form a valid sentence. "The cat sat on the mat" — valid. "Mat the sat cat" — same words, completely broken.

For x = 5 + 10;, the AST looks like this:

    Assignment
    /        \
   x         Add
            /   \
           5    10

The assignment is the root. The addition is its right-hand side. 5 and 10 are leaf nodes.

Now try x = + 5 10. The lexer produces valid tokens. The parser rejects it — the structure doesn't match any grammar rule it knows.

Why Are They Two Separate Things?

This is a design decision that pays off.

Splitting the work means you can change your language's syntax (parser rules) without touching how it recognizes basic tokens (lexer rules), and vice versa. Each component is smaller, testable, and easier to reason about on its own.

Most production compilers and interpreters auto-generate these from tools like ANTLR, Lex/Flex, or Yacc/Bison — you define the rules, the tool writes the code.

Here's a quick comparison:

	Lexer	Parser
Input	Raw character stream	Token stream
Output	Tokens	Abstract Syntax Tree (AST)
Works at	Word level	Structure level
Detects	Unknown characters, bad tokens	Syntax errors, broken grammar

Where You've Already Seen This

Every syntax error you've ever hit — the parser caught it. When your editor colors a keyword differently from a variable name — the lexer already ran.

Linters, formatters, Prettier, ESLint, TypeScript's type checker — they all build on top of this same pipeline. Even AI code tools that "understand" your code are working with ASTs under the hood, not raw text.

Understanding the lexer and parser doesn't just fill in a computer science gap. It explains why error messages look the way they do, why some tools can analyze your code without running it, and how the entire software toolchain that you use daily actually works.

Enjoyed this? I write about backend architecture, DevOps, Linux, and systems programming. Check out more at habibullah.dev

6‑Hour Hackathon Rescue: Dying API, rm -rf, and a Last‑Minute Win 🏆

MD. HABIBULLAH SHARIF — Tue, 14 Apr 2026 03:57:41 +0000

By Md. Habibullah Sharif — CSE Student, Northern University Bangladesh | Assistant Robotics Secretary, NUBCC

1:47 AM. The terminal blinked.
The folder was gone.
The demo was in 4 hours.

That was the moment I genuinely considered if this was how our hackathon story ended.

It didn't.

This is the real story of how our team — Dreams of X — built NagrikAI, survived three catastrophic failures back-to-back, and walked out of Impact Dhaka 2026 as 2nd Runner-Up among 57 competing teams at BUET.

Not polished. Fully by Allah. Earned.

🧠 Why This Matters Before I Even Start

I need you to feel something before I tell you what we built.

Picture a 50-year-old man sitting on a bamboo floor in a village in Sunamganj — one of the most flood-prone regions on Earth. Three days without electricity. The tube-well is broken. His grandchildren are drinking from a ditch.

He has no smartphone. Can't type. Doesn't know what a "helpline" is. Doesn't speak the English that most tech solutions demand.

But he has a voice. And he has words. And he is desperate.

That man is my grandfather. That story is real.

And the question that haunted me walking into that hackathon was simple and devastating:

What if one spoken sentence in his mother tongue could save his family?

That question became NagrikAI. And everything that follows is what we paid to answer it.

👥 The Team That Shouldn't Have Won

Three CSE students from Northern University Bangladesh. No corporate sponsor. No senior mentor in the room. Just a group chat, a shared laptop charger, and a deadline that didn't care about any of that.

Name	Role in Team	Role in NUBCC
Mahdin Islam Mukim	Team Lead	Vice President
Md. Habibullah Sharif (me)	Development	Asst. Robotics Secretary
Yusuf Abdullah	Development	Robotics Secretary

We weren't the most experienced team in that room. I can say that with full confidence.

But we were the most specific about what we were trying to fix.

💡 Hackathon tip that nobody tells you early enough: Judges see twenty demos in a row. Specificity cuts through the noise faster than complexity. Don't build for "everyone." Build for one exact person with one exact problem — and name them.

💡 What We Built: NagrikAI

Not a chatbot. Not another dashboard. Not a demo that pretends a real problem doesn't exist.

NagrikAI is a civic voice assistant — built specifically for Bangladesh — that converts spoken Bengali or English into structured, actionable data routed to the right government institution. Automatically.

[User speaks] → [AI transcribes] → [NLP structures intent] → [Routes to authority]

Someone speaks this:

"আমাদের গ্রামে গত তিনদিন ধরে বিদ্যুৎ নেই এবং কলের পানি নষ্ট।"
("Our village has had no electricity for three days and the water tap is broken.")

NagrikAI doesn't ask a follow-up question. It doesn't open a form. It doesn't require the person to know what "department" handles electricity.

It acts. It files a structured report — priority: high, category: infrastructure, location: extracted from speech — and routes it to the right institution.

That's the whole idea. Remove the barrier. Restore the voice.

⚙️ Tech Stack — And Why Each Choice Was a Hackathon Decision

Layer	Technology	Why We Chose It
Frontend	Next.js (App Router) + Tailwind CSS	Fast to scaffold, zero config for routing
Voice Capture	`MediaRecorder` Web API	Built into the browser — no third-party SDK, no install friction
NLP Engine	OpenRouter AI API	Flexible model routing; we switched providers mid-hackathon and it saved us
Database	SQLite3	No server to spin up, no credentials to manage, works offline
UI/UX	Minimalist glass-slate interface	Accessibility-first — low-vision, low-literacy users are the target

💡 Hackathon architecture principle: Every tool you choose adds setup time. Ask yourself — can I get this working in under 20 minutes? If not, pick something simpler. Speed of iteration matters more than technical elegance at hour 3.

🔥 The Three Disasters (In Brutal Order)

This is the part people don't write about. They crop it out of the LinkedIn post, the Instagram story, the polished retrospective.

I'm not going to do that. Because if you're reading this before your first hackathon, this is the most useful section in this entire post.

Disaster #1 — The API That Lied to Us

We had our NLP backbone planned. Tested locally. Worked beautifully. Clean JSON outputs, fast response times. We were confident going in.

Then the hackathon started.

Real network. Real load. Real pressure.

Error 429: Too Many Requests
Error 500: Internal Server Error
Error 503: Service Unavailable

Over and over. For two hours.

We sat there watching our core feature collapse in real time while other teams were already building. Every minute we spent debugging the API was a minute not spent building the thing that would win us anything.

We made the call at Hour 2: pivot to OpenRouter.

Ripped out the old integration. Rewrote the entire NLP layer. And prayed the new connection held for the remaining 4 hours.

(It did. Barely.)

💡 What this taught us: Always prepare two API providers before the hackathon starts. Not during. Before. Have your .env keys ready, have a test script that hits both, know your fallback before you ever need it. The 20 minutes you spend on this the night before saves you 2 hours of panic inside the event.

Disaster #2 — The `rm` That Shouldn't Have Happened

Hour 4. Tired. Hungry. Running a cleanup script to remove some temp build files.

The command ran. The terminal returned. We moved on.

Thirty seconds later: "Hey... where did the components folder go?"

Silence.

It wasn't the temp folder. It was the wrong directory. And it was gone.

I won't say who ran it. That's not the point. The point is that we all felt it — that specific horror that only developers know. When your stomach drops before your brain fully processes what just happened.

We had Git. We recovered most of it. We lost about 45 minutes of work reconstructed from memory and blind frustration.

That left us with 2 hours.

💡 What this taught us: At a hackathon, commit to Git obsessively — every 30 minutes, every feature, every small fix. Set a timer if you have to. And never run a cleanup or deletion command without doing echo or ls on the path first. Exhausted developers make expensive typos.

Disaster #3 — $18 Over Budget, Then `rm -rf`

Hour 5. The API bill landed.

We'd crossed the free tier. $18 over, before we'd even finished building. The budget we didn't have was now in the negative.

We made a decision in that state — that specific state of exhaustion and low blood sugar and stress — and ran a rm -rf command on what we thought was a safe directory.

It was not safe.

Between the first rm and this one, we had now stress-tested every developer nightmare in a single 6-hour window.

API failure. Data loss. Budget overrun. More data loss.

And then we sat down, took a breath, and kept going.

Because there was nothing else to do.

💡 What this taught us: Set hard API cost limits before the event — most providers let you cap spend at $5 or $10. It takes 2 minutes to configure and removes an entire category of disaster. Also: never run rm -rf when you're tired. Close the terminal. Walk away. Come back.

🎤 The Demo That Changed Everything

When demo time came, NagrikAI worked.

I want you to understand how significant that sentence is. After everything — it worked.

A team member spoke a sentence in Bengali. The audio hit the transcription layer. The NLP extracted the intent. The confirmation card appeared. The civic report was filed.

Clean. Fast. Exactly as designed.

The judges asked questions. We answered every single one. But I think what really moved them wasn't the code — it was the story behind the code.

Why are you building this?

And we told them about the 50-year-old man on the bamboo floor who can't navigate a helpline but knows exactly what he needs. We told them about 170 million people in Bangladesh who deserve technology that speaks their language, not the other way around.

"We weren't building another chatbot. We were building a bridge between a voice and an action."

The judges saw it. And they rewarded it.

💡 The demo lesson most teams miss: Your demo should answer three questions without being asked. Who is this for? What does their life look like before this? What does it look like after? If a judge has to imagine the impact, you've already lost half the room. Make them see it.

🏆 The Result

2nd Runner-Up. 57 teams. Impact Dhaka 2026.

Organized by Cognisor AI at BUET ECE Building under the theme "AI for Urban Transformation" — Bangladesh's first international AI hackathon.

Beyond the trophy: the top 3 teams receive opportunities to engage with Japan's tech startup ecosystem, including platforms like Sushi Tech Tokyo 2026.

Three students from Northern University Bangladesh. On an international platform. Competing against teams from across the country.

I still can't fully believe it.

📰 It Made the News

This wasn't just a win for us — it was picked up nationally:

Platform	Coverage
🗞️ BD Pratidin	আন্তর্জাতিক এআই হ্যাকাথনে 'ড্রিমস অব এক্স' দল দ্বিতীয় রানার-আপ
🏛️ NUB Official Notice	NUB Student Team Runner-Up in International AI Hackathon
📣 NUBCC Facebook	Official Community Announcement

🧩 What I Actually Learned

Not the LinkedIn version. The real version — organized so it's actually useful to you.

⚡ Before the hackathon:

Prepare two API providers. Test both. Have both .env keys ready.
Set API spend limits on every account. $5–$10 cap. Takes 2 minutes. Prevents disasters.
Agree on your Git commit rhythm with your team before the clock starts. Every 30 minutes, minimum.

🔧 During the hackathon:

SQLite is criminally underrated for MVPs. Zero config, offline-capable, fast. Stop overthinking the database.
MediaRecorder Web API gives you browser-native audio capture with no third-party SDK. Use it.
When something breaks badly at hour 3, the pivot decision needs to be fast. Don't debug a sinking ship for more than 30 minutes. Cut and move.

🎯 For your pitch and demo:

Name your user. Not "users in rural areas." Give them a face, an age, a specific problem. Judges remember people, not demographics.
Show the before and after — not just the product. What does your user's life look like without this? What changes with it?
Answer "why you?" before they ask it. Your personal connection to the problem is not a soft detail. It is your strongest differentiator.

🧭 On purpose:

Technology built for marginalized communities — not just about them — is where real impact lives.
If your product requires the user to adapt to it, you've already failed the people who need it most.
A clear "why" is not decoration on top of your idea. It is the idea.

🔗 The Project

NagrikAI — Civic Voice Assistant for Bangladesh
Stack: Next.js · Tailwind · OpenRouter · SQLite3 · MediaRecorder API
Built in: 6 hours
Status: MVP (Competition Build)

🐙 GitHub: NagrikAI-Voice — Impact Dhaka 2026

⚠️ This repository contains proprietary competition code. Shared for reference and learning. Cloning for commercial use without explicit permission is not permitted.

💬 A Note to Every Developer Who's Been in That Moment

You know the moment I mean.

The one where the terminal just... tells you something is gone. Where the API returns something that makes no sense. Where you look at the clock and the math doesn't add up anymore.

Where a quiet, horrible voice in your head says: "Maybe this isn't for you."

I've been there. We were all there that night.

And I want to say something that I mean completely:

That moment is not the end of your story. It's the middle.

The best builders I know aren't the ones who never fail. They're the ones who've been humbled, panicked, and still showed up to the demo.

Every rm -rf that didn't kill you made you more careful.
Every API that failed made you architect better.
Every budget overrun made you wiser about cost.

This stuff is the education. Not the degree.

Ship what matters. Build for real people. Keep going when it gets dark.

That's the whole lesson.

🤝 Connect With Me

I write about AI, civic tech, and building things that matter for communities that are often invisible to the tech industry. If that resonates with you — let's talk.

Platform	Link
🌐 Website	habibullah.dev
🐙 GitHub	github.com/md8-habibullah
✍️ Dev.to	dev.to/md8_habibullah
💼 LinkedIn	linkedin.com/in/md-habibullahs
🐦 Twitter / X	x.com/md8_habibullah
📘 Facebook	facebook.com/md8.habibullah
📸 Instagram	instagram.com/md8.habibullah

Built with love and an unreasonable amount of pressure.
— Habibullah 🇧🇩

Brave Browser Is the King in 2025–2026. There Is No Second Option

MD. HABIBULLAH SHARIF — Sun, 29 Mar 2026 03:43:33 +0000

I don't usually say things this firmly.

But after years of watching Chrome slowly tighten its grip on everything — your data, your extensions, your search results, your attention — and after trying basically every alternative, I'm saying it plainly:

If you're using Chrome in 2026, you are volunteering your private life to a trillion-dollar advertising machine. For free. Every day.

Brave is the exit. Not a compromise. Not a "good enough." The actual answer.

First — What Chrome Did and Why It Matters

In 2024, Google finalized Manifest V3 — a change to Chrome's extension system that effectively crippled ad blockers. uBlock Origin, the most powerful privacy extension ever made, stopped working fully on Chrome. The reason Google gave was "security." The real reason was that effective ad blocking threatens their entire business model.

Brave continues to support Manifest V2 extensions like uBlock Origin, NoScript, and uMatrix that Chrome has removed, making it the better choice for power users who rely on these privacy tools.

Let that sit. Chrome took away your ability to block ads. Brave still gives it to you.

And it gets better — you don't even need uBlock Origin on Brave. It already has a better blocker built in.

Brave Shields — The Built-In Blocker That Extensions Can't Match

Every website you visit, Brave's Shields is running before the page loads. It blocks:

Third-party ads and trackers
Cross-site cookies
Fingerprinting scripts
Social media buttons that track you even if you don't click them
Cookie consent banners (via the built-in Cookiecrumbler system)

This is not an extension. It's not add-on software bolted on the side. Unlike adblocking in other browsers, Brave's adblocking engine is built into the browser and maintained by their privacy team — deep optimizations that are impossible for extension-based blockers, which are restricted by browser extension APIs and sandboxing. This native architecture is also why Brave's ad and tracker blocking is entirely unaffected by Manifest V3.

And in January 2026, Brave overhauled its Rust-based adblock engine, reducing memory consumption by 75% — roughly 45 MB of memory savings by default, scaling even higher for users with additional blocking lists enabled.

Your browser is faster and uses less battery because it's blocking. That's the opposite of how Chrome works.

Want uBlock Origin Anyway? Add It.

If you're a power user who wants your own filter lists on top of Brave's built-in blocking — you can. Brave supports Chrome Web Store extensions. Install uBlock Origin, add your custom lists (EasyPrivacy, Fanboy's Annoyance, whatever), and stack it on top of Shields.

Most users won't need it. But the option is there. Chrome took that option away. Brave kept it.

What Google Never Gave You — What Brave Does by Default

Feature	Chrome	Brave
Ad blocking	❌ (MV3 killed it)	✅ Built-in Shields
Tracker blocking	❌	✅ On by default
Fingerprint protection	❌	✅ On by default
Third-party cookies	✅ Enabled (they reversed their own plan)	❌ Blocked by default
HTTPS forced upgrade	❌	✅ Always
Sell your data	✅ That's the business	❌ No data collected
uBlock Origin support	❌ Removed	✅ Works fine

Google confirmed in April 2025 that third-party cookies will remain enabled by default in Chrome — reversing their own privacy plans. Brave has blocked third-party cookies by default since its launch in 2016.

Nine years of blocking what Chrome just gave up trying to fix.

Privacy That Goes Deeper Than Ad Blocking

HTTPS Everywhere — By Default

Every connection upgraded to HTTPS automatically. No extension needed. No thinking required. Brave just does it.

Fingerprint Protection

Your browser has a unique "fingerprint" — screen size, fonts, GPU info, language settings — that trackers use to identify you even without cookies. Brave randomizes this fingerprint per session, making you look like a different user every time. PCMag and PrivacyTests rate Brave among the top-scoring private browsers on fingerprinting and tracking metrics.

Tor Private Windows

Open a Private Window with Tor and your traffic routes through three encrypted nodes before reaching the destination. Not a VPN — actual onion routing. Built in. No extension. No Tor Browser download.

Microsoft Recall — Blocked

Starting in version 1.81 for Windows users, Brave browser blocks Microsoft Recall from automatically taking screenshots of your browsing activity. Microsoft built a feature that takes screenshots of everything you do on your PC. Brave blocks it in the browser. That's the kind of protection you don't know you needed until someone tells you it exists.

The Features Others Don't Have

Brave Search — Independent Index

Brave Search features an independent index — it crawls the web and stores its own results instead of using Google or Bing. That differs from DuckDuckGo, which uses the Bing API to populate search results.

When you search on Brave Search, no one is watching. Not Google. Not Bing. Not anyone.

Leo AI — Private by Design

Brave has a built-in AI assistant called Leo. Unlike asking ChatGPT or using Google's Gemini sidebar in Chrome, Brave Leo offers zero server storage and BYOM (bring your own model) support — your conversations aren't stored, not linked to your identity, not used to train anything.

Brave Wallet — Built-In, No Extension

Brave Wallet is a built-in crypto wallet that's more secure than other browsers that require third-party extensions for similar features. If you use crypto or Web3, having the wallet inside the browser itself (not a third-party extension with its own permissions and attack surface) is meaningfully safer.

Brave Rewards — Optional, Your Choice

Brave has an optional program where you can choose to see privacy-respecting ads in exchange for BAT (Basic Attention Token). This is completely opt-in. Turn it on if you want a small passive income from browsing. Ignore it if you don't. It has zero effect on the core privacy protections.

The Numbers

Brave has grown to over 97 million active monthly users, with an average of over 41 million daily active users as of September 2025.

In real-world usage, Brave loads pages 21% faster on Android because it blocks ads and trackers before they load. This also results in 14% less data usage and 40% better battery life on mobile.

Faster. Less data. Longer battery. Because it's not downloading the tracking infrastructure Chrome loads on every page.

"But My Extensions / Google Services..."

Fair question. Brave is Chromium-based, so the UI, extension compatibility, and general feature set feel familiar to Chrome users. Your Chrome extensions install directly from the Chrome Web Store. Your bookmarks, passwords, and history import in one click from Settings → Import.

The only thing you lose is Google's ability to watch you.

Available Everywhere

Windows, macOS, Linux — desktop
Android, iOS — mobile
On Linux: sudo apt install brave-browser via the official repo. One command. No snap. No flatpak headaches.

The Honest Bit

No browser is a magic shield. Your IP is still visible to websites and your ISP unless you use a VPN or Tor window. Fingerprinting can still be done at a level no browser fully defeats. Brave had some past trust issues (a 2020 affiliate link controversy, a 2021 Tor DNS leak — both fixed). They're more transparent now, with public privacy update posts and a SOC 2 Type II audit on Brave Search.

But compared to the alternative — a browser built by an advertising company, whose entire revenue model depends on knowing what you're doing online — Brave isn't just better. It's a different philosophy entirely.

Your browser is the window through which you access the entire internet. Who owns that window matters.

Switch. Today.

Download: brave.com

Import your Chrome data in 60 seconds. Use it for a week. You won't go back.

The web loads faster. The ads are gone. Your data stays yours. And you can still run every Chrome extension you already use.

There is no good reason to stay on Chrome in 2026. There's just habit. Break it.

Using something else? Tell me why in the comments — genuinely curious what keeps people on Chrome after all this.

by md8-habibullah

Run Oracle SQL on Any PC Without the Nightmare (Docker + Linux Way)

MD. HABIBULLAH SHARIF — Tue, 17 Mar 2026 18:53:06 +0000

Every semester, the same thing happens.

The university assignment drops. It says: "Use Oracle SQL. No PostgreSQL. No MySQL. Oracle specifically." And then half the class spends their first week not learning SQL — they spend it fighting a broken installer, corrupted Oracle setup files, missing Java dependencies, and a setup guide written in 2009.

I've been there. I work with databases professionally and even I found the native Oracle installer on Windows annoying. For a first-year student touching SQL for the first time? It's a genuine nightmare.

So here's what actually works: Docker. You run Oracle in a container, connect with a proper GUI tool, and you're writing real SQL in 5 minutes. No broken installation. No corrupted registry. Nothing permanently burned into your PC.

But before the setup — a small note.

A Word About Your OS Choice

I run Linux. Have been for years. And every time I help a classmate debug an Oracle installation failure at 2am, that failure is always on Windows.

Linux just works differently. Package managers are open. The terminal is a first-class citizen. Docker runs natively without a translation layer. When something breaks, you understand it and fix it — you don't reinstall and pray.

I'm not here to force you to switch today. But if you've been curious about Linux — Ubuntu, Fedora, Arch, whatever calls to you — this is exactly the kind of workflow where you'll feel the difference. Every Docker command in this guide runs cleaner on Linux. Every terminal shortcut. Every file path. It's a different experience.

The tools we're using — Docker, DBeaver, Beekeeper Studio — are all open source or open core. They don't lock you in. They don't require a license. They don't phone home. They work on any OS. That's intentional. That's the value of building on open foundations.

If this guide converts even one person to trying Linux alongside their studies — worth it.

Now. Let's get Oracle running.

What You'll Need

1. Docker — docker.com

Runs Oracle in an isolated container. Think of it as a lightweight virtual machine that starts in seconds.

Linux: Install Docker Engine directly — no "Desktop" wrapper needed, runs natively
Windows / Mac: Install Docker Desktop — handles everything for you

🐧 Linux one-liner:
# Ubuntu / Debian
sudo apt install docker.io

# Fedora
sudo dnf install docker
No 1.5 GB installer. Just a package. That's the Linux flex right there.

2. A database GUI — pick one:

Beekeeper Studio → beekeeperstudio.io — Clean, fast, beginner-friendly. Free community edition. Recommended.
DBeaver → dbeaver.io — Heavier but works on everything. If Beekeeper won't open on your machine (it happens on some PCs), use this.

Both are free and open source. No trial period. No "sign in to continue." Just install and go.

Step 1 — Launch Oracle with One Command

Make sure Docker is running, then open your terminal and run:

Linux / Mac (multi-line, easier to read):

docker run -d \
  -p 1521:1521 \
  -e ORACLE_PASSWORD=password \
  -v oracle-volume:/opt/oracle/oradata \
  --name oracle-free \
  --restart unless-stopped \
  gvenzl/oracle-free

Windows CMD / PowerShell (Run with Administrator mode) — paste as a single line (backslash continuation doesn't work on Windows):

docker run -d -p 1521:1521 -e ORACLE_PASSWORD=password -v oracle-volume:/opt/oracle/oradata --name oracle-free --restart unless-stopped gvenzl/oracle-free

Same command. Same result. Two formats.

What each part means:

docker run                        → create and start a new container
  -d                              → detached: run in background, get terminal back
  -p 1521:1521                    → port mapping: your-machine:inside-container
  -e ORACLE_PASSWORD=password     → set the database password
  -v oracle-volume:/opt/...       → named volume: data survives container restarts
  --name oracle-free              → give it a name you can reference later
  --restart unless-stopped        → auto-start Oracle when your PC reboots
  gvenzl/oracle-free              → the Docker image (lean, well-maintained Oracle Free)

First run downloads the image (~1–2 GB depending on your internet). Go make tea. After that, future starts are instant.

Step 2 — Wait for Oracle to Be Ready

The container starts immediately, but Oracle itself needs 60–90 seconds to fully initialize inside.

Watch the logs:

docker logs -f oracle-free

You'll see a wall of output. Wait for this:

#########################
DATABASE IS READY TO USE!
#########################

Once you see it, Oracle is fully up. Press Ctrl+C to exit the log view — Oracle keeps running in the background.

Step 3 — Enter Oracle Directly from the Terminal

Before we open any GUI, let me show you the powerful way.

You can open a live SQL session inside the container with:

docker exec -it oracle-free sqlplus system/password@FREEPDB1

Breaking this down:

docker exec          → run a command inside an already-running container
  -i                 → interactive: keep stdin open so you can type
  -t                 → tty: allocate a terminal so it feels like a real shell
  oracle-free        → name of the container to enter
  sqlplus            → Oracle's command-line SQL client (already inside the container)
  system/password    → username / password
  @FREEPDB1          → the Oracle service/pluggable database to connect to

Your prompt changes to:

SQL>

You're now inside Oracle. Type SQL directly and press Enter:

SQL> SELECT 'Hello from inside Oracle!' AS msg FROM dual;

MSG
-------------------------
Hello from inside Oracle!

SQL> EXIT

Type EXIT to leave. You're back to your normal terminal. Oracle is still running.

You can also drop into a full bash shell inside the container:

docker exec -it oracle-free bash

This gives you a Linux shell inside the container — you can explore the Oracle file system, check configs, run any Linux command. Type exit to come back out.

[oracle@abc123 ~]$    ← you're inside the container now
[oracle@abc123 ~]$ exit
$                     ← back to your machine

This is how real server administration works. You SSH (or exec) into a machine and run things. Docker gives you that same model locally.

Step 4 — Connect with Beekeeper Studio or DBeaver

For your assignment work — writing, testing, running SQL with a proper editor — the GUI is your home.

Connection details — use these exactly:

Field	Value
Database type	Oracle
Host	`localhost`
Port	`1521`
Username	`SYSTEM`
Password	`password`
Service Name	`FREEPDB1`

⚠️ Service Name must be FREEPDB1 — not blank, not XE, not FREE. Exactly FREEPDB1.

Beekeeper Studio: New Connection → Oracle → fill in the fields → Test → Save & Connect.

DBeaver: New Database Connection → search Oracle → fill in fields → Test Connection (it will auto-download the Oracle JDBC driver if needed — allow it) → Finish.

You'll see the database tree on the left. You're in.

Step 5 — Basic SQL for Your Assignment

Here's the essential SQL you'll need. This covers 90% of university assignments.

Create a table

CREATE TABLE students (
    id       NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name     VARCHAR2(100) NOT NULL,
    roll_no  VARCHAR2(20)  UNIQUE,
    dept     VARCHAR2(50),
    cgpa     NUMBER(3,2)
);

📝 Oracle uses VARCHAR2, not VARCHAR. NUMBER, not INT. Oracle-specific data types — this is exactly why assignments require Oracle.

Insert data

INSERT INTO students (name, roll_no, dept, cgpa)
VALUES ('Habibullah', 'CSE-2201', 'Computer Science', 3.85);

INSERT INTO students (name, roll_no, dept, cgpa)
VALUES ('Motiur Rahman', 'CSE-2202', 'Computer Science', 3.70);

INSERT INTO students (name, roll_no, dept, cgpa)
VALUES ('Fatima Begum', 'EEE-2201', 'Electrical Engineering', 3.90);

COMMIT;

⚠️ COMMIT is required in Oracle to save your changes permanently. Without it, changes only exist in your current session.

SELECT — retrieve data

-- All rows, all columns
SELECT * FROM students;

-- Specific columns only
SELECT name, roll_no, cgpa FROM students;

-- Filter with WHERE
SELECT name, cgpa
FROM students
WHERE dept = 'Computer Science';

-- Sort results
SELECT name, cgpa
FROM students
ORDER BY cgpa DESC;

-- Multiple conditions
SELECT name, cgpa
FROM students
WHERE dept = 'Computer Science'
  AND cgpa >= 3.80;

UPDATE and DELETE

-- Update a specific row
UPDATE students
SET cgpa = 3.95
WHERE roll_no = 'CSE-2201';
COMMIT;

-- Delete a row
DELETE FROM students
WHERE roll_no = 'EEE-2201';
COMMIT;

Create a second table and JOIN

CREATE TABLE courses (
    course_id   NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    course_name VARCHAR2(100),
    dept        VARCHAR2(50),
    credits     NUMBER
);

INSERT INTO courses (course_name, dept, credits) VALUES ('Database Systems', 'Computer Science', 3);
INSERT INTO courses (course_name, dept, credits) VALUES ('Data Structures', 'Computer Science', 3);
INSERT INTO courses (course_name, dept, credits) VALUES ('Circuit Analysis', 'Electrical Engineering', 3);
COMMIT;

-- JOIN students to their department's courses
SELECT s.name, s.roll_no, c.course_name, c.credits
FROM students s
JOIN courses c ON s.dept = c.dept
ORDER BY s.name;

Aggregates — GROUP BY, COUNT, AVG

-- Count students per department
SELECT dept, COUNT(*) AS total_students
FROM students
GROUP BY dept;

-- Average CGPA per department, only show above 3.5
SELECT dept, ROUND(AVG(cgpa), 2) AS avg_cgpa
FROM students
GROUP BY dept
HAVING AVG(cgpa) > 3.5;

Oracle-specific utilities

-- DUAL: Oracle's special dummy table for single-row expressions
SELECT SYSDATE FROM dual;            -- current date and time
SELECT UPPER('hello world') FROM dual;
SELECT 100 * 3.14 FROM dual;

-- See what tables you've created
SELECT table_name FROM user_tables;

-- Describe a table's structure
DESCRIBE students;

The Complete Docker Command Reference

Every Docker command you'll need for managing your Oracle container:

┌─────────────────────────────────────────────────────────────────┐
│                   CONTAINER LIFECYCLE                           │
├─────────────────────────────┬───────────────────────────────────┤
│ Create + start Oracle       │ docker run -d ... (Step 1 cmd)   │
│ Start an existing container │ docker start oracle-free          │
│ Stop Oracle                 │ docker stop oracle-free           │
│ Restart Oracle              │ docker restart oracle-free        │
│ Delete the container        │ docker rm oracle-free             │
│   (stop it first!)          │   → data in volume is kept safe  │
└─────────────────────────────┴───────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                   STATUS & MONITORING                           │
├─────────────────────────────┬───────────────────────────────────┤
│ See running containers      │ docker ps                         │
│ See ALL containers          │ docker ps -a                      │
│ Live log stream             │ docker logs -f oracle-free        │
│ Last N lines of logs        │ docker logs --tail 50 oracle-free │
│ Full container info         │ docker inspect oracle-free        │
│ Resource usage              │ docker stats oracle-free          │
└─────────────────────────────┴───────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                   TERMINAL ACCESS                               │
├─────────────────────────────┬───────────────────────────────────┤
│ SQL*Plus session            │ docker exec -it oracle-free \     │
│                             │   sqlplus system/password@FREEPDB1│
│                             │                                   │
│ Bash shell inside           │ docker exec -it oracle-free bash  │
│                             │                                   │
│ Quick one-off SQL           │ docker exec oracle-free sqlplus \ │
│ (non-interactive)           │   -S system/password@FREEPDB1 \   │
│                             │   <<< "SELECT SYSDATE FROM dual;" │
└─────────────────────────────┴───────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                   DATA & VOLUMES                                │
├─────────────────────────────┬───────────────────────────────────┤
│ List all volumes            │ docker volume ls                  │
│ Inspect data volume         │ docker volume inspect oracle-volume│
│ Delete data volume          │ docker volume rm oracle-volume    │
│   ⛔ THIS DELETES ALL DATA  │   Only do this to fully reset     │
└─────────────────────────────┴───────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│                   IMAGES                                        │
├─────────────────────────────┬───────────────────────────────────┤
│ List downloaded images      │ docker images                     │
│ Pull latest Oracle image    │ docker pull gvenzl/oracle-free    │
│ Remove image from disk      │ docker rmi gvenzl/oracle-free     │
└─────────────────────────────┴───────────────────────────────────┘

The full workflow, from zero to SQL:

                        ┌──────────────────────┐
                        │  docker pull          │   ← first time only
                        │  gvenzl/oracle-free   │     (~1-2 GB download)
                        └──────────┬───────────┘
                                   │
                                   ▼
                        ┌──────────────────────┐
                        │  docker run -d ...    │   ← creates + starts container
                        │  --name oracle-free   │
                        └──────────┬───────────┘
                                   │
                                   ▼
                        ┌──────────────────────┐
                        │  docker logs -f       │   ← wait for:
                        │  oracle-free          │     DATABASE IS READY TO USE!
                        └──────────┬───────────┘
                                   │
                    ┌──────────────┴──────────────┐
                    │                             │
                    ▼                             ▼
         ┌──────────────────┐         ┌──────────────────────┐
         │  docker exec -it │         │  Beekeeper Studio    │
         │  oracle-free     │         │      or              │
         │  sqlplus ...     │         │  DBeaver             │
         └────────┬─────────┘         └──────────┬───────────┘
                  │                              │
                  ▼                              ▼
              SQL>  prompt                  SQL editor tab
           (terminal / CLI)              (visual / GUI)
                  │                              │
                  └──────────────┬───────────────┘
                                 │
                                 ▼
                    ┌────────────────────────┐
                    │   Write and run SQL    │
                    │  CREATE TABLE ...      │
                    │  INSERT INTO ...       │
                    │  SELECT * FROM ...     │
                    └────────────────────────┘
                                 │
                     ┌───────────┴──────────┐
                     │   When done today:   │
                     ▼                      ▼
             docker stop           docker start
             oracle-free           oracle-free
                                   (next session)

Common Issues & Fixes

"Port 1521 is already in use"
Something else is occupying that port. Change -p 1521:1521 to -p 1522:1521 in your run command, and update the port field to 1522 in your GUI connection.

Beekeeper Studio won't launch on my PC
Use DBeaver. It's heavier but runs on everything.

ORA-12514: listener does not know of service FREEPDB1
Oracle isn't fully initialized yet. Run docker logs -f oracle-free and wait until you see DATABASE IS READY TO USE.

ORA-01017: invalid username/password
Username: SYSTEM (all caps). Password: password. Service: FREEPDB1. Check for typos.

docker: command not found on Linux
Docker isn't installed or the service isn't running:

sudo systemctl start docker
sudo systemctl enable docker   # auto-start on boot
sudo usermod -aG docker $USER  # run docker without sudo
# → log out and back in for the group change to apply

Container disappeared after PC restart
The --restart unless-stopped flag handles auto-start. If you removed it manually, re-run the Step 1 command. Your data is safe in the oracle-volume volume unless you explicitly deleted it.

Why Docker Beats the Native Installer

The official Oracle installer:

4–8 GB download
Requires specific Visual C++ redistributables on Windows
Conflicts with existing Java installations sometimes
Occasionally fails silently with no clear error
Permanently modifies your system files
Doesn't fully uninstall

Docker:

First download ~1–2 GB, then instant starts forever after
Fully isolated — zero changes to your actual system
Full wipe and reinstall takes 30 seconds
Identical behavior on Windows, Mac, and Linux
Cleanup: docker rm oracle-free && docker volume rm oracle-volume — completely gone

And on Linux? Docker runs natively. No Desktop app. No virtualization layer. Just a container running directly on the kernel. Faster. Cleaner. The way it's meant to run.

One Last Thing

You just set up Oracle using Docker — an open-source container runtime. Connected with Beekeeper Studio or DBeaver — open-source tools. On a workflow that runs best on a free, open-source operating system.

You paid nothing. You need no Windows license to run a database. You waited 5 minutes, not 5 hours.

That's the open-source stack. That's what Linux gives you daily. The tools that professional developers use aren't locked behind expensive licenses — they're free, community-maintained, and they run better on open systems.

If this guide saved you an afternoon of installation frustration — share it with your classmates. Alhamdulillah, that's the whole point.

Got stuck at any step? Drop the exact error message in the comments — I'll help you through it.

by md8-habibullah

Auth in 2026: From Drop-In to Full Control — Pick Your Poison

MD. HABIBULLAH SHARIF — Tue, 17 Mar 2026 16:57:21 +0000

I've touched a lot of auth solutions over the years. Clerk for a quick SaaS MVP, Auth0 when the enterprise client needed SSO, Supabase Auth when I was too deep into their ecosystem to care, and recently Better Auth when I finally decided I was tired of paying per monthly active user forever.

Every time someone asks me "what auth should I use?", I end up explaining the same spectrum. Because there isn't one best answer — there's a best answer for where you are right now.

This guide covers that spectrum: from plug-in-and-ship managed solutions all the way to fully self-hosted systems you own 100%. No hype, just honest picks.

The Spectrum, Visualized

Easiest                                                        Most Control
   |                                                                  |
Clerk → Firebase → Kinde → Auth0 → Supabase → Better Auth → NextAuth → Keycloak

Each step to the right means: more code, more responsibility, more ownership, less monthly bill at scale.

1. Clerk — Just Works, No Questions Asked

Best for: SaaS MVPs, early-stage products, teams who want auth done in a day

Clerk is the most developer-friendly managed auth you can find right now. Pre-built <SignIn />, <SignUp />, <UserButton /> components — you drop them in, it works. No designing login pages, no thinking about session handling.

// That's literally it for Next.js
import { SignIn } from "@clerk/nextjs";

export default function Page() {
  return <SignIn />;
}

The tradeoff: you're paying per MAU (Monthly Active User). Fine at 0–10k users, but starts to sting when you scale. You also have zero control over the underlying infrastructure — your users live on Clerk's servers.

The honest verdict: Best DX in this list. Use it for your MVP. Watch the pricing as you grow.


Pricing	Free up to 10k MAUs, then per-user
Self-hostable	❌ No
TypeScript	✅ First-class
Social login	✅ All major providers

2. Firebase Authentication — Where Most of Us Actually Started

Best for: Mobile apps, rapid prototyping, Google Cloud users, beginners who want auth without touching a backend

Let me be honest — Firebase Auth is where I started. Most developers I know did too. You're building your first real app, you need users to log in, and Google hands you this:

import { getAuth, signInWithPopup, GoogleAuthProvider } from "firebase/auth";

const auth = getAuth();
const provider = new GoogleAuthProvider();

signInWithPopup(auth, provider).then((result) => {
  const user = result.user;
  console.log("Logged in:", user.displayName);
});

That's literally it. Three lines and your users can sign in with Google. No server. No JWT handling. No sessions to manage. For a beginner building something real for the first time, that feeling is genuinely magic.

Firebase Auth handles email/password, all major social providers, phone/SMS, anonymous auth (try-before-signup flows), and custom tokens. It's backed by Google's infrastructure and the free Spark plan covers most serious side projects comfortably.

The reality check comes later. Firebase Auth is deeply coupled to the Firebase ecosystem — Firestore, Cloud Functions, security rules all talk to each other through the same auth token. Powerful inside Firebase, but the moment you want to move to Postgres or a different backend, untangling auth is painful work. The B2B feature ceiling is also real — no RBAC, no organizations, no multi-tenancy. Just users.

But it taught a lot of us what auth actually is. That counts.

// The pattern you'll memorize
onAuthStateChanged(auth, (user) => {
  if (user) { /* signed in */ }
  else { /* signed out */ }
});

The honest verdict: The best way to understand auth for the first time. The wrong choice if you outgrow Firebase. Use it to learn, then graduate.


Pricing	Free Spark plan, then Blaze pay-as-you-go
Self-hostable	❌ No
Pre-built UI	✅ FirebaseUI (basic)
Platform lock-in	⚠️ Deep Google/Firebase coupling

3. Kinde — Clerk with Superpowers (and a Better Free Tier)

Best for: SaaS products, B2B apps, teams that want auth + RBAC + billing in one place, anyone who hit Clerk's pricing wall

Kinde is the option I wish I'd known about earlier. On the surface it looks like Clerk — managed cloud auth, great DX, quick setup. But it ships with things that would cost you extra (or custom-built time) elsewhere: organizations, RBAC, feature flags, and a billing engine — all in one platform.

The free tier supports up to 10,500 monthly active users with no credit card required, and users on your paid subscription plans don't count toward that MAU allowance. That's a meaningfully better starting deal than Clerk.

// Next.js — about as fast as Clerk to set up
import { getKindeServerSession } from "@kinde-oss/kinde-auth-nextjs/server";

export default async function Dashboard() {
  const { getUser } = getKindeServerSession();
  const user = await getUser();

  return <p>Hello, {user?.given_name}</p>;
}

The SDK collection spans 21+ languages and frameworks, with particularly strong support for React, Next.js, Vue, and mobile platforms. The migration toolkit is genuinely practical too — it handles imports from Auth0, Firebase, and custom systems with password hash support, meaning your users don't have to reset passwords.

The feature flags baked into the auth layer are something I haven't seen done as cleanly elsewhere. You can gate features by user role, organization, or plan — all without adding a separate service.

Kinde is compliant with ISO 27001, SOC 2 Type 2, GDPR, HIPAA, and PCI-DSS — so it handles the compliance checklist without needing Auth0's price tag.

The honest verdict: If Clerk is your default managed auth pick, give Kinde a serious look. More generous free tier, built-in multi-tenancy, and an integrated billing engine that can replace a whole extra service.


Pricing	Free up to 10,500 MAUs, transparent paid tiers
Self-hostable	❌ No
RBAC + Organizations	✅ Built-in, not an add-on
Feature Flags	✅ Native, tied to auth context
Compliance	✅ SOC2, HIPAA, GDPR

4. Auth0 (by Okta) — The Enterprise Standard

Best for: Enterprise clients, teams needing SSO, apps with serious compliance requirements

Auth0 has been around long enough that it's basically the expected choice when a large client says "we need SSO with our Azure AD." The SDK coverage is extensive — React, Next.js, Vue, Node, iOS, Android — and the documentation is the best in the managed auth space.

// Express setup
const { auth } = require('express-openid-connect');

app.use(auth({
  issuerBaseURL: process.env.ISSUER_BASE_URL,
  baseURL: process.env.BASE_URL,
  clientID: process.env.CLIENT_ID,
  secret: process.env.SECRET,
}));

The problem: Auth0's free tier got a lot less generous after the Okta acquisition. Pricing can get painful fast for B2C apps with lots of users. And the dashboard, while powerful, can feel like navigating a small city.

The honest verdict: Gold standard for enterprise. Overkill and expensive for indie projects.


Pricing	Free to 7,500 MAUs, then per-user
Self-hostable	❌ No
SSO / SAML	✅ Full enterprise
Compliance	✅ SOC2, HIPAA, GDPR

5. Supabase Auth — Auth That Comes With a Backend

Best for: Developers already on Supabase, full-stack apps that want auth + DB in one place

If you're using Supabase for your database and storage, using their Auth makes complete sense. Everything integrates natively — row-level security policies, JWT auto-passed to your Postgres queries, real-time subscriptions scoped per user. It just fits.

const { data, error } = await supabase.auth.signInWithPassword({
  email: 'user@example.com',
  password: 'password',
});

The catch is platform coupling. Supabase Auth and Supabase DB are deeply intertwined. Switching away later involves untangling a lot of wires. Also — no pre-built UI components, so you're building your own login forms.

The honest verdict: Perfect inside the Supabase ecosystem. A compromise if you're not already there.


Pricing	Free tier available, pay as you scale
Self-hostable	✅ Yes (via Docker)
Pre-built UI	❌ Build your own
Platform lock-in	⚠️ Tight Supabase coupling

6. Better Auth — The Modern Open-Source Contender ⭐

Best for: TypeScript stacks (Next.js, Nuxt, SvelteKit, Astro, Hono), teams who want full ownership without full complexity

This is the one that caught my attention recently. Better Auth is a relatively new open-source auth framework — TypeScript-first, framework-agnostic, plugin-based. It recently got backed by YC and is already the recommended auth library by Next.js, Nuxt, and Astro. The creator is a self-taught Ethiopian dev building in public, which is a great story — and the GitHub stars agree.

What makes it different: instead of a giant config file you fight with, you get a clean API where you turn on exactly what you need.

// lib/auth.ts
import { betterAuth } from "better-auth";
import { Pool } from "pg";

export const auth = betterAuth({
  database: new Pool({ connectionString: process.env.DATABASE_URL }),
  emailAndPassword: { enabled: true },
  socialProviders: {
    github: {
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    },
  },
});

The plugin system is genuinely impressive — 2FA, passkeys, magic links, multi-tenancy, organization management, RBAC, API keys — each as a plugin you opt into. No bloat you didn't ask for. Automatic database schema generation means no manual SQL for auth tables.

The one caveat: it's newer, so the ecosystem is smaller. If you hit an edge case, you might be first to document it. But with 5K+ Discord members and active development, the community is catching up fast.

The honest verdict: The strongest open-source option I've used in a while. If you're building a TypeScript app and want to own your auth without building it from scratch, start here.


Pricing	Free, MIT open source
Self-hostable	✅ You own everything
Plugin system	✅ 2FA, passkeys, multi-tenant, org roles
TypeScript	✅ Written in TS, fully typed

7. NextAuth / Auth.js — The Community Classic

Best for: Next.js apps, developers who want battle-tested open source

NextAuth (now rebranded Auth.js) is what most developers reach for when they hear "open-source auth for Next.js." It's been around long enough to have Stack Overflow answers for almost every problem. The providers list is enormous, adapters exist for every database, and the v5 (Auth.js) rewrite made it framework-agnostic.

// auth.ts
import NextAuth from "next-auth";
import GitHub from "next-auth/providers/github";

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [GitHub],
});

The limitation is mostly around authorization. NextAuth does authentication well but expects you to build your own RBAC layer, permissions logic, and organization management. It's also config-heavy when you go beyond basic social login.

The honest verdict: Solid, widely understood, great for simpler use cases. Reaches its limits when your auth logic gets complex.


Pricing	Free, MIT open source
Self-hostable	✅ Yes
Authorization (RBAC)	⚠️ Build it yourself
Ecosystem	✅ Huge, well-documented

8. Keycloak — Full Self-Managed, Full Control

Best for: Enterprise, government, compliance-heavy apps, organizations that can't let user data leave their infrastructure

Keycloak is the nuclear option. Full open-source identity server — you run it yourself, on your servers, behind your firewall. SSO, MFA, LDAP/Active Directory federation, fine-grained authorization, SAML, OIDC, user management admin UI, audit logs — the whole picture.

# docker-compose.yml
services:
  keycloak:
    image: quay.io/keycloak/keycloak:latest
    environment:
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: admin
    command: start-dev
    ports:
      - "8080:8080"

The tradeoff is real: Keycloak is complex. The admin console has depth that takes time to understand. Running it in production means maintaining a Java service, handling upgrades carefully, and knowing what you're doing with realms, clients, and flows. This is not a weekend project — it's infrastructure.

But: zero licensing cost regardless of user count. If you have 10 million users, you pay the same $0. That changes the economics at scale.

The honest verdict: The right call for large enterprises, regulated industries, or anyone who cannot hand user data to a third party. For indie devs — probably overkill.


Pricing	Free, Apache 2.0
Self-hostable	✅ Fully
Enterprise features	✅ Full SSO, LDAP, SAML
Complexity	⚠️ High — plan for it

Quick Comparison Table

Solution	Managed?	Price Model	Best For	Complexity
Clerk	✅ Cloud	Per MAU (free to 10k)	MVP, SaaS	🟢 Low
Firebase Auth	✅ Cloud	Free / pay-as-you-go	Mobile, beginners	🟢 Low
Kinde	✅ Cloud	Free to 10.5k MAU	SaaS, B2B, multi-tenant	🟢 Low
Auth0	✅ Cloud	Per MAU	Enterprise, SSO	🟡 Medium
Supabase Auth	Hybrid	Platform tier	Supabase apps	🟢 Low
Better Auth	❌ Self-host	Free / OSS	TS apps, full ownership	🟡 Medium
NextAuth	❌ Self-host	Free / OSS	Next.js, simple flows	🟡 Medium
Keycloak	❌ Self-host	Free / OSS	Enterprise, regulated	🔴 High

How to Actually Choose

Just starting out and want to understand auth?
└── Firebase Auth. Learn the basics. Graduate when you're ready.

Need auth done this week, MVP in progress?
├── Clerk — best DX, ships fast
└── Kinde — if you know you'll need orgs, RBAC, or billing later

Enterprise client requiring SSO with Azure/Okta/Google Workspace?
└── Auth0. It's what they expect and it handles it natively.

Already on Supabase?
└── Supabase Auth. Obvious choice inside that ecosystem.

Building a TypeScript app and want full ownership without starting from scratch?
└── Better Auth. Seriously — try it once.

Need open-source, well-documented, community-solved edge cases?
└── NextAuth / Auth.js. Especially for simpler flows.

Users can never leave your infrastructure (HIPAA, government, regulated data)?
└── Keycloak. Accept the complexity. It's worth it.

The Real Talk

Authentication is one of those areas where picking the wrong abstraction level costs you later. Too managed = expensive at scale or missing features. Too low-level = you're now a security engineer who also writes features.

My honest journey: Firebase to understand the basics → Clerk for my first real SaaS → Better Auth when I wanted ownership without the complexity tax. Kinde would have saved me a migration if I'd known about it earlier — that 10,500 MAU free tier plus built-in billing is a genuinely strong package.

Better Auth is still what lives rent-free in my head for TypeScript projects. But Kinde is the managed option I'd reach for today over Clerk, and Firebase will always have a soft spot for being the first auth that clicked.

Clerk wins on day-zero DX. Kinde wins when you need multi-tenancy day one. Keycloak wins when the lawyers are involved. Firebase wins when you're learning. That's just the honest map.

Which one are you currently using? Drop it in the comments — and tell me if you've switched away from something and regret it (or don't).

by md8-habibullah

I Lost 2 Days to a Deployment Error That Had a 5-Line Fix

MD. HABIBULLAH SHARIF — Mon, 09 Mar 2026 05:15:42 +0000

A full-stack developer's honest confession about TypeScript, Node.js, and the rabbit hole nobody warns you about.

It was supposed to be a simple task.

Deploy the backend. Maybe 30 minutes. Grab a coffee, call it done.

That was Monday morning. By Tuesday night, I was debugging at midnight, staring at a 500: FUNCTION_INVOCATION_FAILED error on Vercel, wondering where my life went wrong.

The Setup (That Looked Totally Fine)

I was finishing up MediStore — a full-stack medicine management system. Express, TypeScript, Prisma, PostgreSQL. Modern stack, clean code, everything felt solid during development.

For dev mode, I had a nice little setup:

tsx watch src/server.ts

Hot reload, TypeScript support out of the box. Bliss. I was flying.

Then came deployment day.

The First Wall: `tsc` and Node Don't Get Along Like You Think

My first instinct was obvious — compile with tsc, then run with node.

tsc && node dist/server.js

Simple. Logical. Completely broken.

The error? Node couldn't find packages. Imports were failing. ESM vs CJS was exploding. I tried Node v24. Tried v25. Same thing, different error messages mocking me in different fonts.

Here's the thing nobody puts in a bold warning box anywhere: Node.js cannot natively run TypeScript. tsc compiles it, sure — but the output can still fail spectacularly depending on your module system, how your imports are written, and what phase of the moon it is.

My tsconfig.json had "module": "esnext" and "type": "module" in package.json. Sounds right. Felt right. Was a nightmare.

The Second Wall: Vercel Wanted Something Specific

While fighting the local build, I pushed what I had to Vercel anyway. Optimism. You know how it is.

500: INTERNAL_SERVER_ERROR
Code: FUNCTION_INVOCATION_FAILED

Then I tried a different deployment strategy. Different URL, same pain:

404: NOT_FOUND
Code: NOT_FOUND

At some point I wasn't even reading the errors anymore. I was just refreshing and hoping.

The Turning Point: My Instructor Said "Use tsup"

I'd heard of tsup before. Never used it. Didn't think I needed it.

My instructor sent over a PDF with the fix. I almost didn't read it — I was convinced the problem was something deeper, something architectural, something that required a complete rethink.

It wasn't. It was this:

"build": "prisma generate && tsup src/server.ts --format esm --platform node --target node20 --outDir api"

That's it. That's the tweet.

tsup is a zero-config bundler built on top of esbuild. It bundles your TypeScript correctly, handles ESM output, tree-shakes, minifies — and critically, it actually works when Node tries to run the output.

What Was Actually Going Wrong

Looking back, the chain of failures made sense:

tsc output preserves your import paths as-is. If you wrote import { something } from './utils' without the .js extension, the compiled output breaks in ESM mode — because Node expects explicit extensions.
The ERR_MODULE_NOT_FOUND: Cannot find package 'test' error (visible in my terminal screenshot) was a ghost dependency issue — something in the build referencing a package that wasn't bundled correctly.
Vercel's serverless functions need a specific entry point. My vercel.json was pointing at dist/server.js when my actual output was going to api/server.js. A typo in a JSON file cost me hours.

The Fix, All in One Place

package.json scripts:

"scripts": {
  "dev": "tsx watch src/server.ts",
  "build": "prisma generate && tsup src/server.ts --format esm --clean --minify --outDir api",
  "start": "node api/server.js"
}

vercel.json:

{
  "version": 2,
  "builds": [
    { "src": "api/server.js", "use": "@vercel/node" }
  ],
  "routes": [
    { "src": "/(.*)", "dest": "api/server.js" }
  ]
}

server.ts entry point — export your app as default:

import app from './app'
export default app

Run pnpm build locally first. Watch the /api folder appear. Check the filename. Put that exact filename in vercel.json. Then deploy.

What I Actually Learned

1. tsx is for development. It's not a build tool.
It's magical for hot-reloading TypeScript, but it's not meant to produce deployable output. Reach for tsup or esbuild when you need to ship.

2. ESM in Node.js is still a minefield.
"type": "module" in package.json changes everything. Bundlers like tsup handle the edge cases so you don't have to become an expert in Node module resolution at 1am.

3. Check your output directory before touching vercel.json.
This sounds embarrassing to type. I'm typing it anyway. The file Vercel deploys has to actually exist.

4. Your instructor's boring PDF might be the answer.
Read it first. Then go exploring. Not the other way around.

In Hindsight

Two days for a 5-line fix. Classic.

But I came out the other side actually understanding why it works now — not just copying config from Stack Overflow and hoping for the best. That's worth something.

If you're building a TypeScript backend and thinking "I'll just use tsc" — maybe reach for tsup from the start. Future-you will be grateful. Future-you has a coffee to drink instead of an error log to read.

Building MediStore as part of a full-stack development course. More posts on the way — probably also born from pain.

If this saved you a day, drop a clap. If you've been through something similar, I'd love to hear it in the comments.

Distro Wars 2026: Which Linux Should You Actually Use?

MD. HABIBULLAH SHARIF — Sun, 22 Feb 2026 08:50:04 +0000

Everyone has an opinion about Linux distros. Ask on Reddit and you'll get 40 different answers, three flame wars, and someone telling you to use Arch BTW.

This guide isn't that.

This is a practical breakdown — who each distro is actually for, what it's genuinely good at, and which one you should install today based on what you're trying to do. No gatekeeping. No "real Linux users only use X." Just honest picks.

First: What Actually Separates Distros?

Before picking, understand what actually differs between them — because it's not just the wallpaper.

Package Manager — How you install software. apt (Debian/Ubuntu), dnf (Fedora), pacman (Arch), zypper (openSUSE). This affects what's available and how fresh the software is.

Release Model — Fixed release (Ubuntu, Fedora) ships stable versions on a schedule. Rolling release (Arch, openSUSE Tumbleweed) continuously updates — you always have the latest, but occasionally something breaks.

Desktop Environment — GNOME, KDE Plasma, XFCE, Cinnamon, etc. Most distros let you choose, but each has a "flagship" DE that's most polished.

Target Audience — Some distros are built for beginners (Ubuntu, Mint), some for developers (Fedora, Arch), some for servers (Debian, RHEL), some for privacy (Tails, Whonix).

Got it? Good. Let's get into the actual contenders.

1. Ubuntu — The Reliable Default

Best for: Beginners, developers new to Linux, anyone who wants things to just work

Ubuntu is the most documented Linux distro on the planet. Every tutorial, Stack Overflow answer, and blog post that says "on Linux, do this..." means Ubuntu. That's genuinely valuable.

What makes it great:

APT package manager with the largest software repository
Snap packages for easy app installs (controversial but convenient)
LTS releases supported for 5 years — stable, predictable
Best driver support out of the box
Ubuntu Server is the default for cloud VMs (AWS, DigitalOcean, etc.)

What to watch out for:
Canonical (Ubuntu's maker) makes decisions that annoy power users — Snap being the main one. Some packages are aggressively Snapped and run noticeably slower. The GNOME implementation has historically been slightly behind upstream.

Package manager speed: apt install <package> — familiar, reliable, not the fastest
Release: LTS every 2 years (22.04, 24.04...) — predictable and safe

# The command Ubuntu users know by heart
sudo apt update && sudo apt upgrade -y

Pick Ubuntu if: You're switching from Windows, you need maximum compatibility with tutorials and tools, or you're deploying servers.

2. Linux Mint — Ubuntu But Actually Pleasant

Best for: Windows switchers, people who want a familiar desktop, anyone who hated Ubuntu's GNOME

Mint is built on Ubuntu (same packages, same compatibility) but makes very different UI decisions. The Cinnamon desktop feels close to Windows — taskbar at the bottom, Start-menu-style app launcher, system tray. No learning curve for the layout.

It also ships without Snap by default and blocks Canonical from installing it silently. Software installs from traditional APT repos instead.

What makes it great:

Cinnamon desktop is genuinely polished and intuitive
Extremely stable — Mint doesn't rush updates
Update Manager lets you choose how aggressively to update (brilliant for cautious users)
Better multimedia support out of the box (codecs included)

What to watch out for:
Mint is conservative — which is a feature for stability but means you might be waiting on newer software versions. Not ideal if you're chasing the latest everything.

Pick Mint if: You're migrating from Windows and want the least adjustment, or you want Ubuntu compatibility without Snap.

3. Zorin OS — Windows, But Linux

Best for: Absolute beginners, Windows migrants who want the smoothest possible transition, non-technical users

If Linux Mint is "familiar," Zorin OS is "identical." It's built specifically to look and feel like Windows — Start menu, taskbar, system tray, right-click behavior — to the point where you can hand it to someone who's never touched Linux and they'll find their way around in minutes.

Zorin is Ubuntu-based, so it inherits full APT compatibility and Ubuntu's enormous software library. But where Mint stays neutral on looks, Zorin actively mimics Windows 11's design language. There's even a "Zorin Appearance" panel where you can switch the desktop layout between Windows-style, macOS-style, or a traditional GNOME-style — without installing anything extra.

What makes it great:

The most Windows-like Linux experience available — bar none
Zorin Appearance panel lets you switch desktop layouts in one click
Ships with a good default app selection — LibreOffice, media players, browser — ready to use
Zorin Connect (like KDE Connect) — sync your phone notifications, files, and clipboard with your PC
Ubuntu base means maximum software compatibility and tutorial coverage
Zorin OS Lite edition runs well on older hardware (4GB RAM, older CPUs)

What to watch out for:
Zorin has a free Core edition and a paid Pro edition (~$47 one-time). The Pro version unlocks extra desktop layouts (macOS-style, touchscreen-optimized), professional app bundles, and priority support. The free version is genuinely complete — you're not missing core features, just cosmetic extras. Some users feel the Pro upsell is prominent for an open-source distro.

# Same Ubuntu/Debian commands — fully familiar
sudo apt update && sudo apt upgrade -y
sudo apt install <package>

Pick Zorin if: You're helping a family member switch from Windows, you want zero learning curve on the desktop, or you need a distro that works well on older hardware with a lightweight edition.

4. Fedora — The Developer's Daily Driver

Best for: Developers, people who want cutting-edge without full rolling release chaos

Fedora is Red Hat's "community upstream" — meaning new features land in Fedora first, get stabilized, then go into RHEL (the enterprise version). This makes Fedora consistently 6-12 months ahead of Ubuntu on kernel versions, toolchains, and desktop features.

It ships pure upstream GNOME — no patches, no modifications. If GNOME released it, Fedora has it.

What makes it great:

DNF package manager is fast and excellent
Ships the newest stable kernel — better hardware support for recent machines
Flatpak is the default extra-app format (better than Snap — sandboxed, fast, universal)
Fedora Workstation, Silverblue (immutable), and Server editions each solve different needs
If you learn Linux on Fedora, you understand RHEL/CentOS — hugely valuable professionally

What to watch out for:
Fedora releases every ~6 months and is only supported for ~13 months. You will upgrade. Also, some proprietary drivers (Nvidia especially) require a third-party repo (RPM Fusion).

# Fedora's DNF is genuinely great
sudo dnf update -y
sudo dnf install <package>

Pick Fedora if: You're a developer who wants modern tools, you care about GNOME being excellent, or you want skills transferable to enterprise Linux.

5. Arch Linux — Maximum Control, Maximum Effort

Best for: Developers who want to understand every layer of their system, power users, people who want the absolute latest software

Arch is a rolling release distro where you build your own system from scratch. No graphical installer. No pre-installed desktop. You choose every component.

This sounds painful. It kind of is the first time. But the result is a system with zero bloat — only exactly what you installed, configured exactly how you want it.

The AUR (Arch User Repository) is the real killer feature — a community-maintained collection of basically every piece of Linux software ever. If it exists, it's probably in the AUR.

What makes it great:

Always the absolute latest software (rolling release)
The Arch Wiki is the best Linux documentation resource on the internet — useful even if you don't use Arch
Pacman is fast and elegant
AUR gives you access to almost any software imaginable
Deep understanding of Linux comes naturally because you built it yourself

What to watch out for:
Rolling release means occasional breakage. This is manageable with care (paru -Syu before a big presentation is not advised). Also: the install process is genuinely manual.

# Arch users install everything themselves
pacman -S <package>       # official repos
paru -S <package>         # AUR helper for community packages

Pick Arch if: You want to learn how Linux actually works, you need bleeding-edge software, or you want maximum customization.

6. Manjaro — Arch Without the Headache

Best for: People who want Arch's power with an actual installer, intermediate users ready to leave Ubuntu

Manjaro is Arch underneath — same AUR access, same rolling release, same pacman — but ships with a polished graphical installer, pre-configured desktop environments (KDE, GNOME, XFCE), and hardware detection that just works out of the box.

The key difference: Manjaro holds packages back from Arch's repos for 2 extra weeks of testing before pushing to users. You're still rolling, still fresh, but with a small safety buffer baked in. For most people stepping up from Ubuntu, this is exactly the right trade-off.

What makes it great:

Full AUR access — same massive software library as Arch
Graphical installer — no manual partitioning commands
Excellent hardware detection, especially Nvidia and WiFi cards
Multiple official desktop flavors — the KDE Plasma edition is particularly polished
Skills transfer directly to Arch if you ever want to go deeper

What to watch out for:
The 2-week delay occasionally causes AUR package conflicts — some AUR packages assume you have the very latest Arch libs. Rare, but worth knowing. Manjaro also had some past community trust issues (expired SSL certs) though it's been solid since.

# Same pacman as Arch — your skills transfer perfectly
sudo pacman -Syu            # update everything
sudo pacman -S <package>    # install from repos
pamac install <package>     # Manjaro's friendly package manager CLI

Pick Manjaro if: You want AUR access and rolling release freshness but aren't ready to install an OS manually from scratch. It's the best Arch on-ramp available.

7. Debian — The Bedrock

Best for: Servers, stability-critical systems, sysadmins, people who want software that never breaks

Debian is what Ubuntu is built on. It prioritizes stability above everything — packages are tested exhaustively before entering the stable release, which means they can be 1-2 years behind the latest version.

On a server, this is perfect. You don't want your database server running experimental kernel builds.

What makes it great:

Exceptional stability — Debian Stable is battle-tested
Huge package repository
Runs on almost any hardware (x86, ARM, MIPS, RISC-V...)
The standard base for containers and VPS images worldwide
Free of corporate influence — community-driven

What to watch out for:
Debian Stable is old by design. Newer hardware sometimes needs backport packages. Not a great desktop experience out of the box — it's a server OS that also runs desktops.

Pick Debian if: You're running servers, you prioritize stability over new features, or you want the most principled free software distro.

8. openSUSE — The Underrated Gem

Best for: Developers wanting rolling release with safety nets, sysadmins, KDE fans

openSUSE comes in two flavors: Leap (stable, RHEL-based) and Tumbleweed (rolling release). Tumbleweed is what makes it interesting — it's a rolling release but with an automated testing pipeline that means updates are validated before they land on your machine. You get freshness without the breakage risk of raw Arch.

YaST is openSUSE's control center — a graphical tool for configuring nearly everything (network, services, users, firewall, packages) that makes system administration approachable.

# Tumbleweed keeps you rolling safely
sudo zypper refresh && sudo zypper update    # update everything
sudo zypper install <package>               # install software
yast2                                        # launch the graphical control center

Pick openSUSE Tumbleweed if: You want rolling release stability, KDE Plasma as a polished desktop, or you're a sysadmin who values good tooling.

The Quick Comparison

Distro	Stability	Freshness	Beginner-Friendly	Best Use
Ubuntu	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	General, servers, cloud
Linux Mint	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	Windows migrants, beginners
Zorin OS	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	Windows/Mac look-alikes, family PCs
Fedora	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	Developers, workstations
Arch	⭐⭐	⭐⭐⭐⭐⭐	⭐	Power users, learners
Manjaro	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	Arch on-ramp, rolling + friendly
Debian	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐	Servers, stability
openSUSE TW	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	Developers, KDE fans

The Honest Decision Tree

Are you new to Linux?
├── Yes → Coming from Windows?   → Zorin OS (closest to Windows)
│         Want familiar but free? → Linux Mint
│         Coming from Mac?        → Ubuntu or Fedora
└── No  → Keep going

Are you setting up a server or VPS?
├── Yes → Ubuntu LTS or Debian
└── No  → Keep going

Do you want the absolute latest software?
├── Yes → Want full control?  → Arch Linux
│         Want a safety net?  → Manjaro or openSUSE Tumbleweed
└── No  → Keep going

Are you a developer who wants modern tools without chaos?
└── Fedora (the sweet spot answer)

What About Niche Picks?

Pop!_OS — Ubuntu base, but with an excellent GNOME customization and best-in-class Nvidia driver support out of the box. Great for gaming.

Kali Linux — Security and penetration testing tooling pre-installed. Not a daily driver. Use it for its specific purpose.

Tails — Runs entirely in RAM, leaves no trace, routes everything through Tor. For maximum privacy situations.

NixOS — Declarative configuration — your entire OS config lives in one file, reproducible anywhere. Steep learning curve but beloved by the people who get it.

The Real Answer

There's no "best" distro. There's only the best distro for your situation right now.

If you're just starting — Zorin OS or Mint. Familiar desktop, no friction, same Ubuntu compatibility underneath.
If you're developing daily — Fedora. Fresh toolchains, excellent GNOME, professionally relevant.
If you run servers — Ubuntu LTS or Debian. Stable, documented, industry standard.
If you want rolling release without the risk — Manjaro. Arch underneath, sane updates, great hardware support.
If you want to understand Linux — Arch. Do it once. Even if you go back to Fedora afterward, you'll understand everything you're running.

The distro matters less than you think once you're past the basics. They're all Linux. The terminal commands are the same. The concepts are the same. Pick one and go deep.

What distro are you running? Drop it in the comments — and tell us why. This is always the most interesting thread.

by md8-habibullah
Tags: linux beginners devops webdev opensource

Stop Setting Up Servers. Start Shipping Code. (Supabase, Appwrite & The BaaS Revolution)

MD. HABIBULLAH SHARIF — Sun, 22 Feb 2026 08:01:26 +0000

There's a version of backend development where you spend two days setting up authentication before writing a single line of business logic.

You configure a database. You wire up JWT tokens. You write password reset flows. You manage file upload endpoints. You handle CORS. You set up email verification. You configure environment variables in three different places.

And then — finally — you start building the thing you actually wanted to build.

This is the problem Backend-as-a-Service (BaaS) platforms exist to solve. And in 2024–2026, two names come up constantly: Supabase and Appwrite.

What Is a BaaS and Why Does It Change Everything?

A Backend-as-a-Service gives you the infrastructure primitives every app needs — already built, already secured, already scalable — so you can skip straight to your actual product.

Think of it like this: instead of building a kitchen from scratch every time you cook, someone hands you a fully equipped one. You just... cook.

The core primitives every BaaS provides:

Database — store and query your data
Authentication — user sign-up, login, OAuth, sessions
Storage — files, images, documents
Realtime — live updates pushed to clients
Functions/API — custom backend logic without managing servers

That's the foundation. Now let's look at who does it best.

Supabase — The Open-Source Firebase (But With Postgres)

Supabase positions itself simply: "Build in a weekend. Scale to millions."

The magic is that underneath everything, it's just Postgres — the most trusted relational database in the world. Not a proprietary format. Not a document store with weird query limitations. Real SQL, real joins, real indexes. You're not locked in — your data is always yours.

What Supabase Gives You Out of the Box

Database — Full PostgreSQL. Use the visual table editor or write raw SQL. Includes views, materialized views, foreign tables, partitioned tables, stored procedures — the entire Postgres feature set.

Auth — Email/password, magic links, OAuth (Google, GitHub, Twitter, Apple, etc.), phone auth via SMS. Plugs directly into your app with pre-built components or their SDK.

Row Level Security (RLS) — This is Supabase's superpower and its biggest learning curve. You write Postgres policies that control which rows each user can read or modify. Incredibly powerful. Takes a day to really understand.

-- Only show users their own data
create policy "Users can view own profile"
  on profiles for select
  using (auth.uid() = user_id);

Storage — File uploads with S3-compatible storage, image transformations, CDN delivery, and access policies that respect your auth rules.

Realtime — Subscribe to database changes and push updates to connected clients live. Multiplayer features, live dashboards, chat — all without polling.

Edge Functions — Deploy TypeScript functions globally, close to your users. Deno-based runtime.

Instant APIs — Every table gets auto-generated REST and GraphQL endpoints the moment you create it. No controller code required.

MCP Support — Supabase now has MCP integration, meaning AI tools like Claude Code or Cursor can directly inspect your schema, suggest RLS policies, and write migrations. Genuinely changes the workflow.

The Honest Trade-offs

RLS policies are powerful but they're not beginner-friendly. Getting auth + policies + storage all talking together correctly has a learning curve. The community is helpful, but expect to spend time on it.

Edge Functions run on Deno, not Node — small adjustment if you're coming from a pure Node background.

Self-hosting Supabase is possible but involves running many Docker containers together (Postgres, PostgREST, GoTrue, Realtime, Kong, etc.). It works, but it's a lot of moving pieces to manage yourself.

Appwrite — The "Bring Any Framework" BaaS

Where Supabase is Postgres-first, Appwrite is developer-experience-first. It's built for teams that work across platforms — web, mobile (React Native, Flutter, iOS, Android), and server-side — and want everything under one SDK.

What Appwrite Gives You

Auth — All the standard flows plus one nice extra: Anonymous users that convert to real accounts when they sign up. Phone/SMS auth. Teams and memberships built in.

Databases — Document-model with collections and attributes. Not pure SQL, but it has relationships and indexing. The visual console is excellent for non-technical teammates managing data.

Storage — File buckets with permissions, image transformation (resize, crop, format), and virus scanning built in.

Functions — 30+ runtimes across 13 languages: Node, Python, PHP, Ruby, Go, Dart, .NET, Kotlin, Java, Bun, and more. You're not limited to TypeScript/Deno.

Messaging — This is an Appwrite exclusive in this tier: built-in push notifications, email, and SMS under one API. You're not stitching together Twilio + SendGrid + FCM separately.

Realtime — Subscribe to any Appwrite event — not just database changes but auth events, storage events, function completions.

Sites — Appwrite can also host your frontend. Git-connected deployments, preview URLs per branch. The full-stack in one place.

Security built-in — DDoS protection, encryption at rest and in transit, GDPR compliance, SOC-2, HIPAA. Not bolt-ons — defaults.

The Honest Trade-offs

Appwrite's database is document-based (like a more structured MongoDB), not relational SQL. If you need complex joins, reporting queries, or a relational data model — Supabase's Postgres is the better fit.

The self-hosted version requires Docker and some server management knowledge. Appwrite Cloud makes it seamless, but if budget matters, self-hosting is doable with some effort.

Supabase vs Appwrite — The Direct Comparison

Feature	Supabase	Appwrite
Database	PostgreSQL (full SQL)	Document DB (NoSQL-ish)
Auth	✅ Excellent	✅ Excellent
Storage	✅ S3-backed	✅ Built-in
Realtime	✅ DB change streams	✅ All events
Functions	TypeScript/Deno	13 languages, 30+ runtimes
Messaging	❌ Not included	✅ Push, Email, SMS
Frontend Hosting	❌ Not included	✅ Sites included
Self-hosting	✅ Complex (many containers)	✅ Easier (Docker)
Best for	SQL lovers, complex queries, AI apps	Multi-platform teams, mobile, polyglot stacks

Rule of thumb: If your team thinks in SQL and relations — Supabase. If your team builds across multiple platforms or languages — Appwrite.

The Alternatives Worth Knowing

Firebase — The Veteran

Google's platform. Battle-tested, enormous SDK ecosystem, excellent offline support. But it's NoSQL (Firestore), vendor-locked to Google Cloud, and pricing can surprise you at scale. The "Firebase Data Connect" feature now adds Postgres + GraphQL, which narrows the gap with Supabase.

Best for: Mobile-first apps, teams already in Google Cloud, real-time experiences.

PocketBase — The Minimalist's Dream

A single Go binary. Drop it on a server, it runs. Includes database (SQLite), auth, file storage, real-time, and a REST API — with a built-in admin UI. MIT licensed. Completely free.

./pocketbase serve
# That's it. Your backend is running.

The catch: SQLite means it's not for massive multi-tenant SaaS. But for side projects, internal tools, prototypes, or anything that doesn't need horizontal database scaling — it's extraordinary.

Best for: Solo developers, prototypes, internal tools, small apps.

Nhost — GraphQL-First

Same idea as Supabase (Postgres under the hood) but everything goes through GraphQL via Hasura. If your team is GraphQL-native and wants real-time subscriptions in that workflow, Nhost feels very natural.

Best for: GraphQL-first teams, JAMstack apps with real-time needs.

Convex — The TypeScript-Native Backend

Convex is a different mental model. Your backend logic lives in TypeScript functions that react to data changes automatically. No SQL policies, no REST endpoints to design. Just reactive TypeScript functions. It's genuinely elegant if you're TypeScript-first.

Best for: TypeScript-heavy teams who want reactive patterns without policy-based auth complexity.

Neon — Just Postgres, Nothing Else

Sometimes you just want serverless Postgres with branching, auto-suspend when idle, and scale-to-zero pricing. Neon does exactly that — nothing more, nothing less. You bring your own auth (Clerk, Auth.js, etc.) and storage.

Best for: Teams who know what they need and want to assemble it themselves without a full BaaS bundle.

Quick Decision Guide

Do you need complex relational queries / SQL?
├── Yes → Supabase
└── No  → Keep going

Are you building for mobile + web + possibly other platforms?
├── Yes → Appwrite (best multi-platform SDK support)
└── No  → Keep going

Is this a small app, tool, or prototype?
├── Yes → PocketBase (zero cost, zero ops)
└── No  → Keep going

Is your team GraphQL-first?
├── Yes → Nhost
└── No  → Keep going

Is your team TypeScript-first and wants reactive patterns?
├── Yes → Convex
└── No  → Supabase or Appwrite — pick based on DB preference

What This Actually Means for Your Workflow

Before BaaS: You write auth. You design token systems. You write password reset flows. You configure email. You set up file upload. You write access control middleware. You do all of this before building your actual product.

After BaaS: You call supabase.auth.signUp() or account.create() and move on.

The hours you save on infrastructure plumbing get redirected to the actual user-facing features that make your product good. That's the real argument for this category — not that it's easier (though it is), but that it radically changes what you spend your time on.

Bottom Line

Supabase if you want the power of Postgres with auth, storage, realtime, and edge functions bundled together — and you're comfortable with a bit of SQL policy writing.

Appwrite if you want the widest platform support (especially mobile), messaging included, frontend hosting, and a more flexible function runtime.

PocketBase if you want to move fast on a smaller project without any monthly bill.

The best BaaS is the one that removes friction for your specific stack and team. All three of these do it well — the differences are in the details.

What are you currently using for your backend? Curious what the dev.to community has landed on — drop it in the comments.

by md8-habibullah
Tags: supabase appwrite webdev backend beginners

You Just Bought a VPS — Now What? A Modern Developer's Setup Guide

MD. HABIBULLAH SHARIF — Sat, 21 Feb 2026 15:17:20 +0000

You bought the VPS. You got the IP address in your email. Now you're staring at an SSH prompt wondering what to do next — and whether you're about to do it wrong.

This guide is the one I wish existed when I started. We'll go from zero to a production-ready server with proper security, a real CI/CD pipeline, monitoring, and a modern management interface — without it turning into a 3-day rabbit hole.

Step 1: First Login — Lock It Down Immediately

The moment your VPS is live, bots are already trying to log in. Seriously — check /var/log/auth.log after 10 minutes. You'll see hundreds of attempts.

ssh root@YOUR_IP

Do these five things before anything else:

# 1. Update everything
apt update && apt upgrade -y or dnf update

# 2. Create a non-root user
adduser deploy
usermod -aG sudo deploy

# 3. Copy your SSH key to the new user
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

# 4. Disable root SSH login
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

# 5. Set up a basic firewall
ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw enable

Now install Fail2ban — it automatically bans IPs with repeated failed login attempts:

WARN : IPs will be ban (automatically) / can skip it
apt install fail2ban -y
systemctl enable --now fail2ban

That's your baseline. Your server is no longer an open door.

Step 2: Cockpit — A Browser-Based Control Room for Your Server

Most guides stop at the terminal and never look back. That's fine if you live in SSH, but for monitoring, managing services, updates, and getting a visual overview — Cockpit is genuinely excellent and wildly underrated.

apt install cockpit -y
systemctl enable --now cockpit.socket
ufw allow 9090

Now visit https://YOUR_IP:9090 — log in with your system user.

What Cockpit gives you:

Real-time CPU, RAM, disk, and network graphs
Start/stop/restart any systemd service with a click
Manage users and SSH keys through a UI
View and filter system logs (journald) visually
Terminal access right inside the browser — no separate SSH needed
Container management via the Cockpit Podman extension
Storage and network interface management

Cockpit vs alternatives:

Tool	Best For	UI Quality	Cost
Cockpit	Linux system management, services	Clean, minimal	Free
Webmin	Full server admin, legacy setups	Dated but powerful	Free
Netdata	Deep metrics & alerting	Beautiful	Free/Paid
Portainer	Docker/container management	Excellent	Free/Paid

Cockpit isn't trying to be a hosting panel — it's a system manager. That's exactly why it belongs on every VPS you run.

Step 3: Coolify — Your Self-Hosted Heroku

This is where the fun starts. Coolify handles everything above the OS layer — deployments, databases, SSL, environment variables, reverse proxy, and more.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

That single command installs Coolify along with Docker, Nginx/Caddy for the proxy, and everything it needs. Then visit http://YOUR_IP:8000 to set it up.

What Coolify manages for you:

Apps — connect a GitHub/GitLab repo, pick a runtime (Node, PHP, Python, static, Docker), and it builds + deploys automatically on push
Databases — spin up PostgreSQL, MySQL, MariaDB, Redis, MongoDB with one click. Automatic backups to S3 or local
Services — one-click deploys for Plausible, Ghost, Uptime Kuma, Meilisearch, n8n, and 60+ more
SSL — Let's Encrypt, automatic, zero config
Preview deployments — auto-deploy every PR to its own URL
Teams — multiple users, role-based access

Coolify vs alternatives:

Tool	Model	Strengths	Weaknesses
Coolify	Self-hosted	Full-featured, free, open source	Self-managed infra
Render	Cloud SaaS	Zero ops, great DX	Gets expensive fast
Railway	Cloud SaaS	Easiest for small projects	Limited customization
Dokku	Self-hosted	Heroku-compatible, lightweight	CLI-only, steeper curve
Caprover	Self-hosted	App store, good UI	Less active development

Coolify hits the sweet spot: full control, modern UI, no monthly SaaS bill.

Step 4: CI/CD — Push to Deploy Like a Professional

Coolify handles the deployment side. For CI/CD — running tests, linters, builds — you want a pipeline that triggers before Coolify deploys.

The simplest stack: GitHub Actions + Coolify webhook

Create .github/workflows/deploy.yml in your repo:

name: Test & Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          npm install
          npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Coolify Deploy
        run: |
          curl -X POST "${{ secrets.COOLIFY_WEBHOOK }}" \
            -H "Authorization: Bearer ${{ secrets.COOLIFY_TOKEN }}"

Your COOLIFY_WEBHOOK and COOLIFY_TOKEN live in GitHub Secrets. That's it — push to main, tests run, if they pass, Coolify deploys. Full lifecycle, zero babysitting.

CI/CD tool options:

Tool	Hosting	Best For
GitHub Actions	Cloud	Most teams — free tier is generous
Gitea + Woodpecker CI	Self-hosted	Full self-hosted Git + CI stack
GitLab CI	Cloud or Self-hosted	Monorepos, enterprise pipelines
Drone CI	Self-hosted	Docker-native, YAML pipelines

If you want to go fully self-hosted, Gitea (lightweight GitHub alternative) + Woodpecker CI is a beautiful combo that runs comfortably on a small VPS.

Step 5: Monitoring — Know Before Users Tell You

Your pipeline is live. Now make sure you know when something breaks before your users do.

Uptime Kuma — Self-Hosted Status Page + Alerting

Deploy it via Coolify in two clicks (it's in the service catalog). Uptime Kuma monitors your URLs, TCP ports, databases, and Docker containers, and alerts you via Telegram, Slack, email, Discord, and more.

It also generates a public status page — the kind you'd pay $30/month for from a SaaS tool.

Netdata — Real-Time System Metrics

Where Cockpit gives you a system overview, Netdata goes deep. Per-process CPU and memory, disk I/O breakdowns, network packet analysis, and anomaly detection — all in real time, with a gorgeous UI.

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh

Runs on port 19999. Keep it behind a firewall or add basic auth — don't expose it publicly.

Loki + Grafana — Logs That Actually Make Sense

For production apps, structured log aggregation is worth it. Grafana Loki collects logs, Grafana visualizes them alongside metrics. Coolify can deploy the Grafana stack for you.

Monitoring quick-reference:

Tool	What It Covers	Effort
Uptime Kuma	Uptime, SSL expiry, status page	⭐ Very easy
Cockpit	System resources, services	⭐ Very easy
Netdata	Deep system metrics, anomalies	⭐⭐ Easy
Grafana + Loki	Logs, dashboards, alerting	⭐⭐⭐ Moderate
Prometheus + Grafana	Full observability stack	⭐⭐⭐⭐ Advanced

Start with Uptime Kuma and Cockpit. Add Netdata when you want more visibility. Add Grafana when you're running real production load.

The Full Stack, Summarized

Here's what your VPS looks like after following this guide:

OS Layer      → Ubuntu 24.04, hardened SSH, UFW, Fail2ban
System UI     → Cockpit (browser-based management + monitoring)
App Platform  → Coolify (deployments, databases, SSL, services)
CI/CD         → GitHub Actions (tests + webhook trigger)
Uptime        → Uptime Kuma (monitoring + status page)
Metrics       → Netdata (deep real-time system metrics)
Logs          → Grafana + Loki (when you're ready)

You went from a blank VPS to a modern, self-hosted platform that handles deployments, rollbacks, SSL, monitoring, and alerting — with a UI for everything that doesn't require you to live in the terminal.

That's not DevOps complexity. That's just good infrastructure.

What's your current VPS stack? Drop your setup in the comments — always curious what people are running in production.

by md8-habibullah

cPanel: The Server Control Panels Developers Actually Love

MD. HABIBULLAH SHARIF — Sat, 21 Feb 2026 14:39:05 +0000

cPanel is everywhere. If you've ever managed shared hosting, you've clicked through its slightly-dated-but-familiar interface. It works. But ever since they revised their pricing model a few years back, a lot of developers — especially those running their own VPS or small business servers — started asking: do I actually need this?

The answer, most of the time, is no. And some of the alternatives are genuinely better for developers.

Let's break this down practically — what 80% of people actually use cPanel for, what's available elsewhere, where cPanel is still pulling ahead (hello, PostgreSQL!), and which power tools most people sleep on.

What People Actually Use cPanel For (The 80%)

Be honest — most people use cPanel for:

Email management (creating mailboxes, forwarders, spam filters)
File management (the built-in file manager, FTP accounts)
Database creation (MySQL/MariaDB via phpMyAdmin)
Domain & subdomain management
SSL certificate installation
One-click app installs (WordPress, Joomla — via Softaculous)
Cron jobs
DNS zone editing

If that's your list, you have many solid alternatives.

The Real Alternatives Worth Knowing

🟦 Coolify — The One Getting All the Hype Right Now

Best for: Self-hosted PaaS, modern app deployments

Coolify is what you get if Heroku, Netlify, and cPanel had a baby and it grew up writing TypeScript. You connect your server, point it at a GitHub repo, and it handles builds, deployments, SSL, reverse proxy (Caddy under the hood), and environment variables.

What it does really well:

One-click deploy for Docker-based apps, Laravel, Node, static sites
Automatic HTTPS via Let's Encrypt
Preview deployments per branch
Built-in database provisioning (MySQL, PostgreSQL, Redis, MongoDB)
Teams & multi-server support

What it doesn't do: traditional email hosting, cPanel-style file manager, or shared hosting management. It's a developer tool, not a hosting tool.

Free & open source. Self-hosted. coolify.io

🟩 Hestia CP — Closest to cPanel Without the Price Tag

Best for: Web hosts, agencies, resellers managing multiple client sites

Hestia is a fork of VestaCP, cleaned up and actively maintained. It covers the full traditional stack — email, DNS, FTP, databases, web server config (Nginx + Apache or just Nginx), Let's Encrypt SSL, cron jobs, and a clean two-panel UI.

If someone asks "I just want cPanel but free," Hestia is usually the answer. It supports multiple users, has templates for WordPress, and even has a basic backup system.

Caveats: No Softaculous equivalent. You install apps manually or via WP-CLI. That's fine for developers, less so for clients.

Free & open source. hestiacp.com

🟥 Plesk — The Enterprise cPanel Alternative

Best for: Agencies, managed hosting providers, Windows servers

Plesk is the one tool that actually goes toe to toe with cPanel feature-for-feature. It supports both Linux and Windows, has a proper extension marketplace, Docker integration, Git deployment, staging environments, and solid WordPress tooling (WP Toolkit is genuinely excellent).

The licensing model is similar to cPanel — you pay per server or per domain tier. It's not cheap, but if you're managing client sites at scale and need something polished, Plesk earns its keep.

Commercial, with a free trial. plesk.com

🟨 CloudPanel — The Speed-Optimized Minimalist

Best for: Developers who want lean, fast, Nginx-based setups

CloudPanel is opinionated and fast. It's built around Nginx, PHP-FPM, and MySQL, and it ships with a clean UI that handles vhosts, SSL, databases, cron, user management, and basic file access. It's noticeably lighter than cPanel.

It added AWS/GCP/DigitalOcean cloud integration so you can spin it up via marketplace images. Great for PHP apps, Laravel especially. Less suited for polyglot or containerized workflows.

Free. cloudpanel.io

⬛ Webmin/Virtualmin — The Veteran

Best for: Linux power users who want full control

Webmin has been around since the late 90s. It's essentially a web UI for your entire Linux system — you can manage services, firewalls, users, packages, and everything in between. Virtualmin extends it for virtual hosting (multiple domains, email, databases).

It's not pretty. The UI feels like it's from a different era (because parts of it are). But it's incredibly comprehensive, battle-tested, and free. If you know your way around Linux, Webmin exposes everything without hiding it behind abstraction.

Free & open source. webmin.com

cPanel's Surprise Move: PostgreSQL Support

For years, one of cPanel's most cited developer frustrations was: MySQL only. phpMyAdmin, MySQL, MariaDB — that was the world.

cPanel recently added native PostgreSQL database management, including phpPgAdmin integration. You can now create and manage PostgreSQL databases directly from WHM/cPanel without SSH gymnastics.

This matters because:

Apps built on PostgreSQL (Django, Rails, many Node stacks) no longer need workarounds on cPanel servers
Shared hosting environments can now officially support Postgres tenants
It closes a real gap that pushed developers toward VPS + custom setups

It's still newer than the MySQL support and not every host has enabled it, but it's a meaningful step. If your host runs cPanel and you need Postgres — ask them to enable it.

The Tools Developers Skip (But Shouldn't)

Regardless of which panel you use, these are the things most people ignore that will save you real time:

WP-CLI — If you manage WordPress sites and you're not using WP-CLI, you're doing extra work. Update plugins, search-replace database URLs, manage users, run imports — all from the command line. Most panels give you SSH access; use it.

Caddy as a reverse proxy — Coolify uses it, but you can set it up yourself. Caddy auto-renews SSL, handles HTTP/2, and has a dead-simple config syntax. If you're hand-rolling a VPS setup, Caddy makes the "HTTPS with Let's Encrypt" step trivial.

Restic for backups — Most panel backup systems are either basic or locked behind premium tiers. Restic is a modern backup tool that deduplicates, encrypts, and can push to S3, B2, or any rclone-compatible remote. Set up a cron, forget about it, sleep better.

Fail2ban — Every server open to the internet is getting hit by bots. Fail2ban watches your logs and auto-bans IPs with repeated failed login attempts. Takes 10 minutes to configure, prevents a lot of headaches.

Mailpit (formerly MailHog) — If you're testing transactional email locally, Mailpit gives you a fake SMTP server with a web UI that catches all outgoing mail. No more accidentally emailing real users from dev environments.

How to Actually Choose

You want...	Go with...
Free cPanel replacement for client sites	Hestia CP
Modern app deployments (Docker, Git)	Coolify
Full-featured commercial alternative	Plesk
Lightweight PHP/Laravel hosting	CloudPanel
Maximum Linux control, no polish required	Webmin/Virtualmin
Staying on cPanel, but need Postgres	Ask your host to enable it — it's there now

The hosting control panel space is more interesting than it's been in years. cPanel is no longer the obvious default, and for developers especially, tools like Coolify are genuinely changing how we think about self-hosting. The gap between "managed hosting" and "DIY VPS" is narrowing fast.

What panel are you running in production right now? Drop it in the comments — curious to see what the dev.to crowd has landed on.

by md8-habibullah

SSH Mastery 2026: From Zero to Hero - The Developer's Complete Guide

MD. HABIBULLAH SHARIF — Sun, 08 Feb 2026 12:16:36 +0000

In 2026, SSH (Secure Shell) remains the backbone of secure remote system administration, development workflows, and DevOps operations. Whether you're a complete beginner setting up your first remote server, a mid-level developer automating deployment pipelines, or an advanced security professional implementing zero-trust architectures, mastering SSH is non-negotiable.

This comprehensive guide takes you from fundamental concepts to advanced tunneling techniques, security hardening, and real-world penetration testing scenarios. We'll adopt a developer mindset throughout, understanding not just the "how" but the "why" behind each technique.

What You'll Learn:

SSH fundamentals and architecture for beginners
Key-based authentication and secure key management
Advanced SSH configuration and hardening techniques
Port forwarding and tunneling for all skill levels
ProxyJump, multiplexing, and escape sequences
Real-world security scenarios and penetration testing techniques
SSH certificates and enterprise-scale key management
Troubleshooting and debugging SSH connections

Understanding SSH: The Foundation
For Beginners: Getting Started with SSH
For Mid-Range Users: Authentication & Configuration
For Advanced Users: Security Hardening
Advanced Deep Dive: SSH Tunneling & Port Forwarding
Developer Workflows: SSH in Modern Development
Enterprise SSH: Certificates & Key Management
Troubleshooting & Debugging
Security Best Practices 2026
Resources & Further Learning

Understanding SSH: The Foundation

What is SSH?

SSH (Secure Shell) is a cryptographic network protocol that provides a secure channel over an unsecured network. Created in 1995 by Tatu Ylönen as a replacement for insecure protocols like Telnet and rlogin, SSH has become the de facto standard for remote system access.

Key Features:

Encryption: All traffic (passwords, commands, data) is encrypted
Authentication: Multiple methods, including passwords and public keys
Integrity: Ensures data hasn't been tampered with during transmission
Confidentiality: Protects against eavesdropping and man-in-the-middle attacks

How SSH Works: The Architecture

┌─────────────┐                              ┌─────────────┐
│             │      Encrypted Channel       │             │
│  SSH Client │◄────────────────────────────►│  SSH Server │
│ (Your PC)   │      Port 22 (default)       │ (Remote)    │
│             │                              │             │
└─────────────┘                              └─────────────┘
      │                                             │
      │ 1. Client initiates connection             │
      │────────────────────────────────────────────►│
      │                                             │
      │ 2. Server sends public host key            │
      │◄────────────────────────────────────────────│
      │                                             │
      │ 3. Secure connection established           │
      │ 4. User authentication (key/password)      │
      │────────────────────────────────────────────►│
      │                                             │
      │ 5. Encrypted session begins                │
      │◄────────────────────────────────────────────│

The Three-Layer Architecture:

Transport Layer: Establishes an encrypted connection, handles key exchange
Authentication Layer: Verifies client identity (password, public key, certificates)
Connection Layer: Multiplexes encrypted tunnel into logical channels

SSH Protocol Versions

Protocol 1 (Deprecated): Legacy version with known security vulnerabilities. Never use in 2026.

Protocol 2 (Current Standard):

Improved security algorithms
Better key exchange mechanisms
Support for multiple authentication methods
Standard since 2006, mandatory in 2026

For Beginners: Getting Started with SSH

Installing SSH

Linux/macOS (Usually pre-installed):

# Check if SSH client is installed
which ssh

# Check if SSH server is installed (Linux)
which sshd

# Install OpenSSH client (Ubuntu/Debian)
sudo apt update
sudo apt install openssh-client

# Install OpenSSH server (Ubuntu/Debian)
sudo apt install openssh-server

# Install on macOS (if needed)
brew install openssh

Windows:

Windows 10/11: OpenSSH client included by default
Enable via Settings: Apps → Optional Features → OpenSSH Client
Alternative: PuTTY, Windows Subsystem for Linux (WSL)

Your First SSH Connection

Basic Connection Syntax:

ssh username@hostname_or_ip

# Examples
ssh rafi@192.168.1.100
ssh admin@example.com
ssh [email protected]

First Connection - Trust On First Use (TOFU):

$ ssh user@remote-server.com

The authenticity of host 'remote-server.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:Xk1pJ7+3vYr6...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

Warning: Permanently added 'remote-server.com' (ED25519) to the list of known hosts.
user@remote-server.com's password:

What Just Happened?

SSH client connected to the server
Server sent its public host key
You verified the fingerprint (ideally compare with server admin)
Key saved to ~/.ssh/known_hosts
Future connections verify against this saved key

Understanding Known Hosts

The ~/.ssh/known_hosts file stores server fingerprints to prevent man-in-the-middle attacks:

# View your known hosts
cat ~/.ssh/known_hosts

# Remove a specific host (if key changed legitimately)
ssh-keygen -R hostname_or_ip

# Example
ssh-keygen -R 192.168.1.100

Basic SSH Commands

# Connect with specific username
ssh user@host

# Connect with custom port
ssh -p 2222 user@host

# Execute single command remotely
ssh user@host 'ls -la /var/log'

# Copy files (SCP - Secure Copy)
scp file.txt user@host:/path/to/destination
scp user@host:/remote/file.txt /local/path/

# Copy directories recursively
scp -r directory/ user@host:/path/

# Modern alternative to SCP (faster, resumable)
rsync -avz -e ssh directory/ user@host:/path/

Your First Configuration File

Create ~/.ssh/config to simplify connections:

# Create config file
touch ~/.ssh/config
chmod 600 ~/.ssh/config

# Edit with your favorite editor
nano ~/.ssh/config

Basic Configuration Example:

# Personal Server
Host myserver
    HostName 192.168.1.100
    User rafi
    Port 22

# Work VPS
Host work
    HostName work.example.com
    User admin
    Port 2222

Usage:

# Instead of: ssh -p 2222 admin@work.example.com
# Simply use:
ssh work

Developer Tip: Think of the SSH config file as your connection shortcuts. It's like bookmarks for remote servers, but way more powerful.

For Mid-Range Users: Authentication & Configuration

Understanding SSH Key Authentication

Password authentication is vulnerable to brute-force attacks. Key-based authentication uses cryptographic key pairs for superior security.

How Key Authentication Works:

┌──────────────────┐                    ┌──────────────────┐
│   SSH Client     │                    │   SSH Server     │
├──────────────────┤                    ├──────────────────┤
│  Private Key     │                    │  Public Key      │
│  (id_ed25519)    │                    │  (authorized_    │
│  KEEP SECRET!    │                    │   keys)          │
└────────┬─────────┘                    └────────┬─────────┘
         │                                       │
         │  1. Client: "I want to connect"      │
         │──────────────────────────────────────►│
         │                                       │
         │  2. Server: "Prove you have the key" │
         │◄──────────────────────────────────────│
         │                                       │
         │  3. Client signs challenge with      │
         │     private key                       │
         │──────────────────────────────────────►│
         │                                       │
         │  4. Server verifies with public key  │
         │  5. Connection granted! ✓            │
         │◄──────────────────────────────────────│

Generating SSH Keys: 2026 Best Practices

Recommended Algorithm: Ed25519

Ed25519 is the gold standard in 2026:

Fast and secure
Shorter keys (256-bit security)
Resistant to timing attacks
Recommended by NIST, IETF, and security experts

# Generate Ed25519 key (RECOMMENDED)
ssh-keygen -t ed25519 -a 100 -C "[email protected]"

# Explanation:
# -t ed25519       : Key type (Ed25519 algorithm)
# -a 100           : Number of KDF rounds (key derivation, more = slower brute force)
# -C "comment"     : Meaningful comment (identifies key purpose/owner)

# You'll be prompted for:
# 1. File location (default: ~/.ssh/id_ed25519)
# 2. Passphrase (HIGHLY RECOMMENDED - adds encryption layer)

Alternative: RSA Keys (for compatibility)

Some legacy systems don't support Ed25519:

# Generate RSA key (minimum 3072-bit, 4096 recommended)
ssh-keygen -t rsa -b 4096 -C "[email protected]"

# NEVER use RSA keys smaller than 3072 bits in 2026

Advanced Key Generation with Date Embedding:

Smart developers embed creation dates in key comments for rotation tracking:

# Ed25519 with year embedding
ssh-keygen -t ed25519 -a 100 -C "rafi@company-2026-01" \
    -f ~/.ssh/id_ed25519_2026

# When 2028 comes, rotate to new key:
ssh-keygen -t ed25519 -a 100 -C "rafi@company-2028-01" \
    -f ~/.ssh/id_ed25519_2028

Why Date Embedding?

Visual reminder of key age
Signals security consciousness to recipients
Facilitates rotation schedules (recommended every 1-2 years)

Key File Structure

# List your SSH keys
ls -la ~/.ssh/

# Typical structure:
~/.ssh/
├── id_ed25519          # Private key (NEVER SHARE!)
├── id_ed25519.pub      # Public key (share freely)
├── config              # Connection configurations
├── known_hosts         # Server fingerprints
└── authorized_keys     # Public keys allowed to connect (on servers)

Critical Permissions:

# Correct permissions (REQUIRED for security)
chmod 700 ~/.ssh                    # Directory
chmod 600 ~/.ssh/id_ed25519         # Private keys
chmod 644 ~/.ssh/id_ed25519.pub     # Public keys
chmod 600 ~/.ssh/config             # Config file
chmod 600 ~/.ssh/authorized_keys    # Authorized keys

# Why? SSH refuses to work with incorrect permissions as a security measure!

Deploying Your Public Key

Method 1: ssh-copy-id (Easiest)

# Copy public key to remote server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-server

# For custom port
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 user@remote-server

# What it does:
# 1. Connects to remote server (requires password this once)
# 2. Appends public key to ~/.ssh/authorized_keys
# 3. Sets correct permissions

Method 2: Manual Copy

# Display your public key
cat ~/.ssh/id_ed25519.pub

# Example output:
# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBr... rafi@company-2026-01

# On remote server, append to authorized_keys:
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBr... rafi@company-2026-01" \
    >> ~/.ssh/authorized_keys

# Set permissions
chmod 600 ~/.ssh/authorized_keys

Method 3: One-Liner Remote Copy

cat ~/.ssh/id_ed25519.pub | ssh user@remote \
    'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

Testing Key Authentication

# Test connection (should NOT ask for password)
ssh user@remote-server

# Verify which key is being used
ssh -v user@remote-server 2>&1 | grep "identity file"

# Output shows:
# debug1: identity file /home/user/.ssh/id_ed25519 type 4

SSH Agent: Managing Multiple Keys

SSH Agent stores decrypted private keys in memory, so you don't enter passphrases repeatedly.

# Start SSH agent
eval "$(ssh-agent -s)"

# Add key to agent
ssh-add ~/.ssh/id_ed25519

# Enter passphrase once - agent remembers for session

# List loaded keys
ssh-add -l

# Remove all keys from agent
ssh-add -D

# Auto-load keys on login (add to ~/.bashrc or ~/.zshrc)
if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/id_ed25519
fi

macOS Keychain Integration:

# Add key to macOS Keychain (survives reboots)
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# Auto-load from Keychain (add to ~/.ssh/config)
Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

Advanced SSH Configuration

Expand your ~/.ssh/config with powerful options:

# Global defaults for all hosts
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    Compression yes
    ControlMaster auto
    ControlPath ~/.ssh/control-%r@%h:%p
    ControlPersist 10m

# Production server with specific key
Host prod
    HostName prod.example.com
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    ForwardAgent no

# Development server with agent forwarding
Host dev
    HostName dev.example.com
    User developer
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent yes

# Bastion/Jump host configuration
Host internal-server
    HostName 10.0.1.100
    User admin
    ProxyJump bastion

Host bastion
    HostName bastion.example.com
    User admin
    Port 2222

# AWS EC2 instance
Host aws-web
    HostName ec2-54-123-45-67.compute.amazonaws.com
    User ec2-user
    IdentityFile ~/.ssh/aws-key.pem

# Multiple hostnames for same config
Host web1 web2 web3
    HostName %h.example.com
    User webadmin
    IdentityFile ~/.ssh/id_ed25519_web

# Wildcard matching
Host *.internal
    User admin
    IdentityFile ~/.ssh/id_ed25519_internal
    ProxyJump gateway

Configuration Parameters Explained:

ServerAliveInterval: Send keepalive every 60 seconds
ServerAliveCountMax: Disconnect after 3 missed keepalives
Compression: Enable data compression (useful for slow connections)
ControlMaster/ControlPath/ControlPersist: SSH multiplexing (reuse connections)
ForwardAgent: Allow remote servers to use your local SSH agent
ProxyJump: Jump through intermediate hosts (replaces ProxyCommand)

SSH Multiplexing: Speed Up Connections

Multiplexing reuses existing SSH connections for new sessions:

# First connection establishes control socket
ssh server1

# Subsequent connections (instant, no re-authentication!)
ssh server1  # Uses existing connection
scp file.txt server1:/path/  # Uses existing connection

Manual Multiplexing Setup:

Host speedyserver
    HostName example.com
    User admin
    ControlMaster auto
    ControlPath ~/.ssh/control-%r@%h:%p
    ControlPersist 10m

Benefits:

Faster subsequent connections (no key exchange)
Reduced server load (single TCP connection)
Fewer authentication attempts (better for rate-limited servers)

For Advanced Users: Security Hardening

SSH Server Hardening: The 2026 Security Baseline

Critical Configuration File: /etc/ssh/sshd_config

Always backup before editing:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup
sudo nano /etc/ssh/sshd_config

Recommended Security Configuration:

# /etc/ssh/sshd_config - 2026 Security Hardened Configuration

# === Basic Settings ===
Port 2222                              # Change from default 22 (reduces automated attacks)
Protocol 2                             # Only use Protocol 2 (Protocol 1 is deprecated)
PermitRootLogin no                     # NEVER allow direct root login
MaxAuthTries 3                         # Limit authentication attempts
MaxSessions 5                          # Limit concurrent sessions

# === Authentication ===
PubkeyAuthentication yes               # Enable public key authentication
PasswordAuthentication no              # Disable password authentication (KEY-BASED ONLY)
PermitEmptyPasswords no                # Never allow empty passwords
ChallengeResponseAuthentication no     # Disable challenge-response
UsePAM no                              # Disable PAM if using key-only auth

# === Authorized Keys ===
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

# === Restrict Users/Groups ===
AllowUsers deploy webadmin admin       # Only these users can SSH
# AllowGroups sshusers                 # Alternative: restrict by group
# DenyUsers baduser                    # Explicitly deny users
# DenyGroups nogroupssh                # Explicitly deny groups

# === Timeout & Keepalive ===
ClientAliveInterval 300                # Send keepalive every 5 minutes
ClientAliveCountMax 0                  # Disconnect if client unresponsive
LoginGraceTime 60                      # 60 seconds to complete authentication

# === Logging ===
SyslogFacility AUTH                    # Use AUTH facility for logging
LogLevel VERBOSE                       # Detailed logging for security auditing

# === Cryptographic Settings (2026 Hardened) ===
# Only allow modern, secure algorithms

# Key Exchange Algorithms (KEX)
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

# Host Key Algorithms
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Ciphers (Encryption)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# MACs (Message Authentication Codes)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# === Disable Unnecessary Features ===
X11Forwarding no                       # Disable X11 forwarding (unless needed)
PermitUserEnvironment no               # Don't allow users to set environment options
AllowAgentForwarding no                # Disable agent forwarding (enable per-user if needed)
AllowTcpForwarding no                  # Disable TCP forwarding (enable if needed for tunneling)
PermitTunnel no                        # Disable TUN/TAP device forwarding
GatewayPorts no                        # Don't allow remote hosts to connect to forwarded ports

# === Banner (Optional) ===
Banner /etc/ssh/banner.txt             # Display warning banner (legal notice)

# === Subsystems ===
Subsystem sftp /usr/lib/openssh/sftp-server  # SFTP subsystem (for file transfers)

# === Additional Security ===
PrintMotd no                           # Don't print message of the day
PrintLastLog yes                       # Show last login info
TCPKeepAlive no                        # Don't use TCP keepalive (use ClientAlive instead)
Compression no                         # Disable compression (prevents CRIME-style attacks)

After Configuration Changes:

# Test configuration syntax
sudo sshd -t

# If no errors, restart SSH service
sudo systemctl restart sshd

# Check service status
sudo systemctl status sshd

# IMPORTANT: Keep your current SSH session open while testing!
# Open a NEW terminal to test connection before closing original session

Two-Factor Authentication (2FA)

Add an extra security layer with time-based one-time passwords (TOTP):

Install Google Authenticator PAM Module:

# Ubuntu/Debian
sudo apt install libpam-google-authenticator

# CentOS/RHEL
sudo yum install google-authenticator

Configure 2FA for User:

# As the user who needs 2FA
google-authenticator

# Answer the prompts:
# 1. Time-based tokens? Yes
# 2. Update .google_authenticator file? Yes
# 3. Disallow multiple uses? Yes
# 4. Increase time window? No
# 5. Enable rate-limiting? Yes

# Scan QR code with authenticator app (Google Authenticator, Authy, 1Password)

Enable 2FA in SSH Configuration:

# Edit PAM configuration
sudo nano /etc/pam.d/sshd

# Add this line at the top:
auth required pam_google_authenticator.so

# Edit SSH configuration
sudo nano /etc/ssh/sshd_config

# Set these options:
ChallengeResponseAuthentication yes
UsePAM yes

# For key + 2FA (most secure):
AuthenticationMethods publickey,keyboard-interactive

# Restart SSH
sudo systemctl restart sshd

Now Login Requires:

SSH private key
Google Authenticator code

Firewall Configuration

Using UFW (Ubuntu/Debian):

# Enable UFW
sudo ufw enable

# Allow SSH on custom port from specific IP
sudo ufw allow from 203.0.113.10 to any port 2222

# Allow from subnet
sudo ufw allow from 192.168.1.0/24 to any port 2222

# Check rules
sudo ufw status numbered

# Delete rule by number
sudo ufw delete 2

Using firewalld (CentOS/RHEL):

# Add custom SSH port
sudo firewall-cmd --permanent --add-port=2222/tcp

# Allow from specific IP
sudo firewall-cmd --permanent --add-rich-rule='
  rule family="ipv4"
  source address="203.0.113.10"
  port protocol="tcp" port="2222" accept'

# Reload firewall
sudo firewall-cmd --reload

# List rules
sudo firewall-cmd --list-all

Fail2Ban: Automated Intrusion Prevention

Fail2Ban monitors logs and bans IPs with suspicious activity:

# Install Fail2Ban
sudo apt install fail2ban

# Create local configuration
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Fail2Ban SSH Configuration:

[sshd]
enabled = true
port = 2222              # Your custom SSH port
filter = sshd
logpath = /var/log/auth.log
maxretry = 3             # Ban after 3 failed attempts
bantime = 3600           # Ban for 1 hour
findtime = 600           # Within 10 minutes

# Start and enable Fail2Ban
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

# Check status
sudo fail2ban-client status sshd

# Unban IP
sudo fail2ban-client set sshd unbanip 203.0.113.10

SSH Key Rotation Best Practices

Annual Key Rotation Schedule:

# Generate new key with year identifier
ssh-keygen -t ed25519 -a 100 -C "rafi@company-2026" \
    -f ~/.ssh/id_ed25519_2026

# Deploy new key to all servers
for server in prod1 prod2 dev1 dev2; do
    ssh-copy-id -i ~/.ssh/id_ed25519_2026.pub $server
done

# Test new key on all servers
for server in prod1 prod2 dev1 dev2; do
    ssh -i ~/.ssh/id_ed25519_2026 $server "echo Connected to \$(hostname)"
done

# Update SSH config to use new key
sed -i 's/id_ed25519_2025/id_ed25519_2026/g' ~/.ssh/config

# After verification period (1 week), remove old keys from servers
for server in prod1 prod2 dev1 dev2; do
    ssh $server "sed -i '/rafi@company-2025/d' ~/.ssh/authorized_keys"
done

# Archive old key (don't delete immediately - keep for recovery)
mv ~/.ssh/id_ed25519_2025 ~/.ssh/archive/
mv ~/.ssh/id_ed25519_2025.pub ~/.ssh/archive/

Monitoring and Auditing

Monitor SSH Login Attempts:

# Recent successful logins
sudo last -a | head -20

# Failed login attempts (Debian/Ubuntu)
sudo grep "Failed password" /var/log/auth.log | tail -20

# Failed login attempts (CentOS/RHEL)
sudo grep "Failed password" /var/log/secure | tail -20

# Current SSH sessions
who
w

# Active SSH connections
sudo ss -tnp | grep sshd

SSH Audit Tool:

# Install ssh-audit
pip install ssh-audit --break-system-packages

# Audit your SSH server
ssh-audit localhost

# Audit remote server
ssh-audit example.com -p 2222

# Output shows:
# - Weak algorithms
# - Recommended configurations
# - CVE vulnerabilities

Advanced Deep Dive: SSH Tunneling & Port Forwarding

SSH tunneling is where SSH truly shines as a Swiss Army knife of network security. This section covers local, remote, and dynamic port forwarding with real-world scenarios.

Understanding Port Forwarding Fundamentals

Port forwarding creates encrypted tunnels through SSH connections to:

Access internal services securely
Bypass firewalls and network restrictions
Expose local services to remote networks
Create SOCKS proxies for application traffic
Pivot through compromised systems (pentesting)

Local Port Forwarding (-L): Bring Remote Services Local

Concept: Forward traffic from your local machine to a remote server.

Syntax:

ssh -L [local_address:]local_port:destination_address:destination_port user@ssh_server

Visual Diagram:

┌─────────────────┐         SSH Tunnel          ┌─────────────┐
│   Your Laptop   │──────────────────────────────►│ SSH Server  │
│  (Client)       │  Encrypted Connection        │             │
└────────┬────────┘                              └──────┬──────┘
         │                                              │
         │ localhost:5432                               │
         │ ▼                                            │ 10.0.1.50:5432
    ┌────▼─────┐                                   ┌────▼─────┐
    │ Local    │  Traffic forwarded through   ────►│ Database │
    │ App      │  encrypted SSH tunnel              │ Server   │
    └──────────┘                                   └──────────┘

Real-World Use Cases:

1. Access Remote Database Securely:

# Forward local port 5432 to remote PostgreSQL server
ssh -L 5432:localhost:5432 user@database-server

# Now connect locally
psql -h localhost -p 5432 -U dbuser

# The connection is encrypted and travels through SSH tunnel

2. Access Internal Web Application:

# Access internal web app on port 80
ssh -L 8080:internal-web.company.local:80 user@bastion-host

# Open browser to http://localhost:8080
# You're now accessing internal-web.company.local securely!

3. Multiple Port Forwards in One Command:

# Forward multiple services simultaneously
ssh -L 5432:db.internal:5432 \
    -L 6379:redis.internal:6379 \
    -L 9200:elasticsearch.internal:9200 \
    user@jump-server

# Access:
# - PostgreSQL: localhost:5432
# - Redis: localhost:6379
# - Elasticsearch: localhost:9200

4. Forward to Third-Party Service:

# SSH server acts as intermediary to reach external service
ssh -L 3306:external-db.example.com:3306 user@proxy-server

# Useful when direct access is blocked but proxy-server can reach it

Remote Port Forwarding (-R): Expose Local Services Remotely

Concept: Forward traffic from remote server to your local machine (reverse tunnel).

Syntax:

ssh -R [remote_address:]remote_port:local_address:local_port user@ssh_server

Visual Diagram:

┌─────────────────┐         SSH Tunnel          ┌─────────────┐
│   Your Laptop   │◄─────────────────────────────│ SSH Server  │
│  (Client)       │  Encrypted Connection        │             │
└────────┬────────┘                              └──────┬──────┘
         │                                              │
         │ localhost:8000                               │ 0.0.0.0:8080
    ┌────▼─────┐                                   ┌────▼─────┐
    │ Local    │  ◄──── Traffic forwarded ─────────│ External │
    │ Web App  │        through tunnel             │ Clients  │
    └──────────┘                                   └──────────┘

Real-World Use Cases:

1. Expose Local Development Server:

# Share your local dev server with team
ssh -R 8080:localhost:3000 user@public-server

# Team accesses: http://public-server:8080
# Traffic reaches your localhost:3000

2. Webhook Testing (Payment Processors, GitHub Webhooks):

# Stripe/PayPal needs to send webhooks to your app
ssh -R 9000:localhost:8000 user@my-public-vps.com

# Configure webhook URL: http://my-public-vps.com:9000/webhook
# Webhooks now reach your local development server!

3. Remote Access to Home Network:

# Access home server from anywhere
ssh -R 2222:home-server:22 user@public-vps

# From anywhere:
ssh -p 2222 user@public-vps
# You're now connected to your home server!

4. Allow Remote Access to Internal Service:

# Expose internal Jenkins to external contractors
ssh -R 0.0.0.0:8080:jenkins.internal:8080 user@public-server

# Contractors access: http://public-server:8080
# 0.0.0.0 allows all interfaces (default is localhost only)

Security Warning: Remote port forwarding can expose internal services. Only use with trusted servers and consider:

# Server configuration to allow GatewayPorts
# /etc/ssh/sshd_config
GatewayPorts yes  # Allow binding to non-localhost addresses

# Or restrict to specific interfaces:
GatewayPorts clientspecified

Dynamic Port Forwarding (-D): SOCKS Proxy

Concept: Create a SOCKS5 proxy that routes multiple applications through SSH tunnel.

Syntax:

ssh -D [local_address:]local_port user@ssh_server

Visual Diagram:

┌─────────────────┐         SSH Tunnel          ┌─────────────┐
│   Your Laptop   │──────────────────────────────►│ SSH Server  │
│                 │  SOCKS5 Proxy Protocol       │             │
└────────┬────────┘                              └──────┬──────┘
         │                                              │
    localhost:1080                                      │
         │                                              │
    ┌────▼──────────────────┐                          │
    │  SOCKS-aware Apps:    │                          │
    │  - Firefox            │    All traffic routed────┼──►Internet
    │  - Chrome             │    through SSH server    │
    │  - curl --socks5      │                          │
    │  - proxychains        │                          │
    └───────────────────────┘                          │

Real-World Use Cases:

1. Secure Browsing on Untrusted Networks:

# Create SOCKS proxy through trusted server
ssh -D 1080 user@trusted-server

# Configure browser:
# Firefox: Settings → Network → SOCKS Host: localhost, Port: 1080
# All browser traffic now encrypted through SSH tunnel

2. Bypass Geographic Restrictions:

# SSH to server in different country
ssh -D 1080 user@server-in-target-country

# Browser traffic appears to originate from that country

3. Penetration Testing - Network Reconnaissance:

# Establish SOCKS proxy through compromised host
ssh -D 1080 user@compromised-internal-host

# Use proxychains to scan internal network
proxychains nmap -sT 10.0.1.0/24

# All Nmap traffic routes through compromised host

4. Secure Multiple Applications:

# Start SOCKS proxy
ssh -D 1080 -C -N user@ssh-server

# Flags:
# -C: Enable compression
# -N: Don't execute remote command (just forwarding)

# Use with various applications:
curl --socks5 localhost:1080 https://api.example.com
git clone --config http.proxy=socks5://localhost:1080 https://github.com/user/repo

Configure Proxychains:

# Edit /etc/proxychains.conf or ~/.proxychains/proxychains.conf
sudo nano /etc/proxychains.conf

# Add at end:
[ProxyList]
socks5 127.0.0.1 1080

# Use with any application:
proxychains firefox
proxychains nmap -sT target-network
proxychains ssh user@internal-server

Advanced Tunneling Techniques

1. ProxyJump (Jump Hosts):

Modern alternative to ProxyCommand for accessing servers behind bastions:

# Old way (ProxyCommand):
ssh -o ProxyCommand="ssh -W %h:%p user@bastion" user@internal-server

# New way (ProxyJump):
ssh -J user@bastion user@internal-server

# Multiple jumps:
ssh -J user@bastion1,user@bastion2 user@final-destination

# In ~/.ssh/config:
Host internal
    HostName 10.0.1.100
    User admin
    ProxyJump bastion

Host bastion
    HostName bastion.company.com
    User admin

# Usage:
ssh internal  # Automatically jumps through bastion

2. Reverse SSH Tunnel with AutoSSH (Persistent):

Keep reverse tunnels alive automatically:

# Install autossh
sudo apt install autossh

# Create persistent reverse tunnel
autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \
    -R 2222:localhost:22 user@public-server

# -M 0: Disable monitoring port (rely on ServerAlive)
# Tunnel reconnects automatically if connection drops

# Run as systemd service:
sudo nano /etc/systemd/system/reverse-tunnel.service

Systemd Service Example:

[Unit]
Description=Reverse SSH Tunnel
After=network.target

[Service]
Type=simple
User=tunneluser
ExecStart=/usr/bin/autossh -M 0 -N -o "ServerAliveInterval 30" \
    -o "ServerAliveCountMax 3" -R 2222:localhost:22 user@public-server
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

# Enable and start
sudo systemctl enable reverse-tunnel
sudo systemctl start reverse-tunnel
sudo systemctl status reverse-tunnel

3. SSH VPN (Layer 3 Tunneling):

Create full network tunnel using TUN/TAP devices:

# Requires root on both sides and PermitTunnel yes in sshd_config

# Server configuration (/etc/ssh/sshd_config):
PermitTunnel yes

# Create TUN devices:
# Server:
sudo ssh -w 0:0 root@remote-server

# Assign IP addresses:
# On client:
sudo ip addr add 10.0.0.1/24 dev tun0
sudo ip link set tun0 up

# On server:
sudo ip addr add 10.0.0.2/24 dev tun0
sudo ip link set tun0 up

# Now you have a point-to-point VPN!
# Route traffic through tunnel:
sudo ip route add 10.0.1.0/24 via 10.0.0.2

4. Chaining Tunnels (The "Impossible" Tunnel):

Navigate through multiple network segments:

[Laptop] → [Jump1] → [Jump2] → [Jump3] → [Target]

# Establish tunnel through Jump1
ssh -L 2222:jump2:22 user@jump1

# In new terminal, tunnel through Jump2 (via local port 2222)
ssh -p 2222 -L 3333:jump3:22 user@localhost

# In third terminal, tunnel through Jump3 (via local port 3333)
ssh -p 3333 -L 4444:target:22 user@localhost

# Finally, access target (via local port 4444)
ssh -p 4444 user@localhost

# Or use ProxyJump (much easier!):
ssh -J user@jump1,user@jump2,user@jump3 user@target

5. Multiplexing Port Forwards:

Combine connection sharing with port forwarding:

# In ~/.ssh/config:
Host devserver
    HostName dev.example.com
    User developer
    LocalForward 5432 db.internal:5432
    LocalForward 6379 redis.internal:6379
    LocalForward 9200 es.internal:9200
    ControlMaster auto
    ControlPath ~/.ssh/control-%r@%h:%p
    ControlPersist 10m

# First connection establishes tunnels:
ssh devserver

# All subsequent connections reuse the same tunnel instantly!

Security Considerations for Tunneling

1. Disable Port Forwarding When Not Needed:

# /etc/ssh/sshd_config
AllowTcpForwarding no        # Disable all port forwarding
PermitTunnel no              # Disable TUN/TAP tunneling
GatewayPorts no              # Prevent remote hosts from connecting

2. Restrict Port Forwarding by User:

# /etc/ssh/sshd_config
Match User developer
    AllowTcpForwarding yes

Match User contractor
    AllowTcpForwarding no

3. Monitor Active Tunnels:

# List active SSH connections and tunnels
sudo ss -tnp | grep sshd

# Check for suspicious port forwards
sudo netstat -tulpn | grep sshd

4. Use Dedicated Keys for Tunneling:

# Generate tunnel-specific key
ssh-keygen -t ed25519 -C "tunnel-only-key" -f ~/.ssh/id_tunnel

# Restrict key usage in authorized_keys:
# On server:
nano ~/.ssh/authorized_keys

# Add restrictions before key:
no-pty,no-X11-forwarding,permitopen="localhost:5432",permitopen="localhost:6379" ssh-ed25519 AAAAC3...

Developer Workflows: SSH in Modern Development

Git Over SSH

Configure Git to Use SSH:

# Check remote URL
git remote -v

# Change from HTTPS to SSH
git remote set-url origin [email protected]:user/repo.git

# Or when cloning:
git clone [email protected]:user/repo.git

Multiple GitHub Accounts:

# ~/.ssh/config
Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal

Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work

# Clone work repo:
git clone [email protected]:company/project.git

# Clone personal repo:
git clone github-personal:username/personal-project.git

Remote Development with SSH

VS Code Remote-SSH:

Install "Remote - SSH" extension
Press F1 → "Remote-SSH: Connect to Host"
Enter host from ~/.ssh/config
Develop directly on remote server with local VS Code interface

JetBrains IDEs (PyCharm, IntelliJ, etc.):

Tools → Deployment → Configuration
→ Add SFTP connection using SSH credentials

Docker Over SSH

# Connect to remote Docker daemon
export DOCKER_HOST=ssh://user@remote-docker-host

# Or specify in command:
docker -H ssh://user@remote-docker-host ps

# In ~/.ssh/config for convenience:
Host docker-remote
    HostName docker.example.com
    User docker

# Then:
export DOCKER_HOST=ssh://docker-remote
docker ps

SSH in CI/CD Pipelines

GitHub Actions Example:

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup SSH
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          ssh-keyscan -H ${{ secrets.SERVER_IP }} >> ~/.ssh/known_hosts

      - name: Deploy
        run: |
          ssh -i ~/.ssh/deploy_key user@${{ secrets.SERVER_IP }} '
            cd /var/www/app &&
            git pull origin main &&
            npm install &&
            pm2 restart app
          '

SSH File Transfer Best Practices

SCP (Secure Copy):

# Copy file to remote
scp file.txt user@remote:/path/

# Copy directory recursively
scp -r directory/ user@remote:/path/

# Copy from remote to local
scp user@remote:/path/file.txt ./

# Copy between two remote hosts (via your machine)
scp user1@host1:/path/file.txt user2@host2:/path/

SFTP (SSH File Transfer Protocol):

# Interactive SFTP session
sftp user@remote

# SFTP commands:
sftp> ls                    # List remote directory
sftp> lls                   # List local directory
sftp> cd /path              # Change remote directory
sftp> lcd /local/path       # Change local directory
sftp> put local.txt         # Upload file
sftp> get remote.txt        # Download file
sftp> put -r directory/     # Upload directory
sftp> get -r directory/     # Download directory
sftp> exit                  # Exit SFTP

Rsync Over SSH (Recommended for Large Transfers):

# Sync directory to remote (with progress)
rsync -avz --progress /local/dir/ user@remote:/remote/dir/

# Flags:
# -a: Archive mode (recursive, preserve permissions/timestamps)
# -v: Verbose
# -z: Compression
# --progress: Show transfer progress

# Sync from remote to local
rsync -avz user@remote:/remote/dir/ /local/dir/

# Exclude files
rsync -avz --exclude='*.log' --exclude='node_modules/' \
    /local/dir/ user@remote:/remote/dir/

# Dry run (see what would be transferred)
rsync -avzn /local/dir/ user@remote:/remote/dir/

# Delete files on destination not in source
rsync -avz --delete /local/dir/ user@remote:/remote/dir/

# Bandwidth limit (KB/s)
rsync -avz --bwlimit=1000 /local/dir/ user@remote:/remote/dir/

Enterprise SSH: Certificates & Key Management

SSH Certificates vs. Traditional Keys

Problem with Traditional Keys:

Each user needs their key on every server
Revocation requires manual removal from all servers
No expiration dates
Management effort: O(Users × Servers)

SSH Certificates Solution:

Certificate Authority (CA) signs user and host keys
One CA public key on all servers
Certificates have expiration dates
Easy revocation via Certificate Revocation List (CRL)
Management effort: O(Users + Servers)

Setting Up SSH Certificate Authority

1. Create CA Key Pair:

# Generate CA key (store securely!)
ssh-keygen -t ed25519 -f ~/.ssh/ssh_ca -C "SSH Certificate Authority"

# This creates:
# ~/.ssh/ssh_ca       (CA private key - EXTREMELY SENSITIVE!)
# ~/.ssh/ssh_ca.pub   (CA public key)

2. Deploy CA Public Key to Servers:

# /etc/ssh/sshd_config on all servers:
TrustedUserCAKeys /etc/ssh/ssh_ca.pub

# Copy CA public key to servers:
sudo scp ~/.ssh/ssh_ca.pub root@server:/etc/ssh/ssh_ca.pub

# Restart SSH:
sudo systemctl restart sshd

3. Sign User Keys:

# User generates their key pair
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "rafi@company"

# Send public key to CA admin
scp ~/.ssh/id_ed25519.pub ca-admin@ca-server:~/keys/rafi.pub

# CA admin signs the key (creates certificate)
ssh-keygen -s ~/.ssh/ssh_ca \
    -I rafi@company \
    -n rafi,admin \
    -V +52w \
    ~/keys/rafi.pub

# Explanation:
# -s: CA private key
# -I: Certificate identity (for logging/auditing)
# -n: Principals (usernames user can log in as)
# -V: Validity period (+52w = 52 weeks)

# This creates: rafi-cert.pub (SSH certificate)

# Send certificate back to user
scp ~/keys/rafi-cert.pub rafi@workstation:~/.ssh/id_ed25519-cert.pub

4. User Connects with Certificate:

# Certificate must be named: <private_key_name>-cert.pub
# Example: id_ed25519 → id_ed25519-cert.pub

# Connect normally (SSH automatically uses certificate)
ssh rafi@server

# Verify certificate is being used:
ssh -v rafi@server 2>&1 | grep certificate
# Output: debug1: Server accepts key: user-cert-v01@openssh.com

Host Certificates (Eliminates TOFU Problem)

Problem: First connection requires trusting unknown host key.

Solution: CA-signed host certificates.

# Server generates host key
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

# CA signs host key
ssh-keygen -s ~/.ssh/ssh_ca \
    -I server.company.com \
    -h \
    -n server.company.com,10.0.1.100 \
    -V +520w \
    /etc/ssh/ssh_host_ed25519_key.pub

# -h: Host certificate (not user certificate)
# -n: Valid hostnames/IPs for this certificate

# Install certificate on server
sudo scp ssh_host_ed25519_key-cert.pub root@server:/etc/ssh/

# Configure server to use certificate
# /etc/ssh/sshd_config:
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

sudo systemctl restart sshd

# Clients add CA public key:
# ~/.ssh/known_hosts:
@cert-authority *.company.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... SSH-CA

# Now connections are trusted immediately (no TOFU prompt!)

Certificate Revocation

Create Certificate Revocation List (CRL):

# Revoke certificate by serial number
ssh-keygen -k -f revoked_keys -s ~/.ssh/ssh_ca \
    -z <serial_number>

# Or by key ID:
ssh-keygen -k -f revoked_keys -I rafi@company

# Deploy CRL to servers:
sudo scp revoked_keys root@server:/etc/ssh/revoked_keys

# Configure servers to check CRL:
# /etc/ssh/sshd_config:
RevokedKeys /etc/ssh/revoked_keys

sudo systemctl restart sshd

# Revoked certificates are immediately denied access!

Troubleshooting & Debugging

SSH Verbose Mode

# Verbose output (single -v)
ssh -v user@server

# Very verbose (double -v)
ssh -vv user@server

# Extremely verbose (triple -v)
ssh -vvv user@server

# What to look for:
# - Which key files are being tried
# - Authentication method used
# - Connection failures and why
# - Key exchange algorithms
# - Host key verification

Common SSH Issues & Solutions

1. Permission Denied (Public Key)

# Check verbose output
ssh -v user@server

# Common causes:
# - Wrong key being used
# - Key not in authorized_keys
# - Incorrect permissions

# Fix permissions on client:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

# Fix permissions on server:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Verify key is in authorized_keys:
ssh user@server "cat ~/.ssh/authorized_keys | grep '$(cat ~/.ssh/id_ed25519.pub)'"

2. Host Key Verification Failed

# Error message:
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
# IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

# Causes:
# - Server reinstalled (new host key)
# - Man-in-the-middle attack (VERIFY!)
# - Server IP reassigned

# Remove old host key:
ssh-keygen -R hostname_or_ip

# Verify new key with server admin before connecting!

3. Connection Timed Out

# Test connectivity:
ping server-hostname

# Test SSH port:
telnet server-hostname 22
# Or:
nc -zv server-hostname 22

# Common causes:
# - Firewall blocking port
# - SSH service not running
# - Wrong port number

# Check SSH service on server:
sudo systemctl status sshd

# Check firewall:
sudo ufw status
sudo iptables -L -n

4. Too Many Authentication Failures

# Error: Received disconnect from host: 2: Too many authentication failures

# Cause: SSH client trying too many keys

# Solution: Specify exact key:
ssh -i ~/.ssh/specific_key user@server

# Or in ~/.ssh/config:
Host problematic-server
    HostName server.com
    User admin
    IdentityFile ~/.ssh/specific_key
    IdentitiesOnly yes  # Don't try other keys

5. Slow SSH Connection

# Causes:
# - DNS lookup slow/failing
# - GSSAPI authentication timeout

# Disable DNS lookup (server-side):
# /etc/ssh/sshd_config:
UseDNS no

# Disable GSSAPI (client-side):
ssh -o GSSAPIAuthentication=no user@server

# Or permanently in ~/.ssh/config:
Host *
    GSSAPIAuthentication no

Escape Sequences

SSH escape sequences allow control during active sessions:

# Press ~? to see help (on new line after Enter)

~.  - Terminate connection
~^Z - Suspend SSH session (bring back with 'fg')
~#  - List forwarded connections
~&  - Background SSH at logout when waiting for connections to terminate
~?  - Display escape sequence help
~C  - Open command line (for adding port forwards mid-session)
~R  - Request connection rekeying

Example - Add Port Forward Mid-Session:

# During active SSH session, press Enter then ~C
ssh> -L 5432:db.internal:5432
Forwarding port.

# Port forward now active without disconnecting!

Security Best Practices 2026

The 10 Commandments of SSH Security

Always Use Key-Based Authentication
- Never rely solely on passwords in 2026
- Minimum 3072-bit RSA or Ed25519
- Protect private keys with strong passphrases
Disable Root Login
- PermitRootLogin no
- Use sudo for administrative tasks
- Audit all privileged commands
Change Default Port (Security Through Obscurity)
- Move SSH from port 22 to custom port
- Reduces automated attack surface by 90%+
- Not a primary defense, but helpful
Implement Firewall Rules
- Restrict SSH access to known IP ranges
- Use UFW, firewalld, or cloud security groups
- Apply principle of least privilege
Enable Two-Factor Authentication
- Google Authenticator, Duo, Yubikey
- Combines "something you have" + "something you know"
- Critical for administrative access
Rotate Keys Regularly
- Annual rotation minimum
- Embed year in key comments
- Archive old keys securely
Use SSH Certificates for Scale
- Eliminates key distribution headaches
- Built-in expiration and revocation
- Essential for organizations with 10+ servers
Monitor and Audit SSH Access
- Review auth.log daily
- Implement Fail2Ban or similar IDS
- Alert on suspicious patterns
Harden Cryptographic Settings
- Only modern algorithms (Ed25519, ChaCha20, AES-GCM)
- Disable weak ciphers and MACs
- Follow NIST/IETF recommendations
Limit User Access
- AllowUsers and AllowGroups
- Implement role-based access control
- Regular access reviews

Zero Trust SSH Architecture

┌────────────────────────────────────────────────────┐
│         Zero Trust SSH Access Model                │
├────────────────────────────────────────────────────┤
│                                                    │
│  1. Identity Verification (MFA)                    │
│     └─► Certificate-based authentication           │
│                                                    │
│  2. Device Trust                                   │
│     └─► Verify client device security posture      │
│                                                    │
│  3. Least Privilege Access                         │
│     └─► Grant minimum required permissions         │
│                                                    │
│  4. Session Recording                              │
│     └─► Audit all SSH sessions                     │
│                                                    │
│  5. Just-In-Time Access                            │
│     └─► Short-lived certificates (1-8 hours)       │
│                                                    │
│  6. Continuous Monitoring                          │
│     └─► Real-time anomaly detection                │
│                                                    │
└────────────────────────────────────────────────────┘

Compliance Checklist

PCI-DSS Requirements:

[ ] Multi-factor authentication for all administrative access
[ ] Encrypted communication channels (SSH meets this)
[ ] Unique user IDs (no shared SSH keys)
[ ] Audit trails of all access

HIPAA Requirements:

[ ] Encrypted data transmission
[ ] User authentication and access controls
[ ] Audit controls and monitoring
[ ] Automatic logoff (idle timeout)

SOC 2 Requirements:

[ ] Logical access controls
[ ] Encryption of data in transit
[ ] Monitoring and logging
[ ] Periodic access reviews

Resources & Further Learning

Official Documentation

OpenSSH Manual Pages: https://www.openssh.com/manual.html
SSH Protocol RFCs: RFC 4251-4254
NIST Guidelines: NIST SP 800-52 Rev. 2

Essential Tools

ssh-audit: Test SSH server security configurations
Fail2Ban: Intrusion prevention system
AuthSSH: Automatic reconnection for persistent tunnels
Mosh: Mobile Shell (SSH alternative for unstable connections)
Eternal Terminal (et): SSH alternative with better connection resilience
Teleport: Modern SSH server with access controls and auditing

Learning Resources

SSH Mastery (2nd Edition) by Michael W. Lucas
SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett
Practical SSH: https://www.practicals.sh/
SSH Academy: https://www.ssh.com/academy/ssh

Security Standards & Frameworks

CIS Benchmarks for SSH: https://www.cisecurity.org/
SANS SSH Security Checklist: https://www.sans.org/
OWASP Transport Layer Protection: https://owasp.org/

Penetration Testing Resources

SSH Tunneling Cheat Sheet: https://github.com/swisskyrepo/PayloadsAllTheThings
HackTricks SSH: https://book.hacktricks.xyz/network-services-pentesting/pentesting-ssh
GTFOBins SSH: https://gtfobins.github.io/

Community & Support

r/sysadmin: https://reddit.com/r/sysadmin
r/netsec: https://reddit.com/r/netsec
Server Fault: https://serverfault.com/
OpenSSH Mailing List: https://www.openssh.com/list.html

Conclusion: Your SSH Journey

Mastering SSH is a journey, not a destination. Whether you're just starting with basic remote connections or implementing enterprise-scale certificate authorities, SSH remains one of the most powerful tools in modern computing.

Key Takeaways:

🔑 For Beginners: Start with key-based authentication, create a config file, and practice basic connections daily.

⚙️ For Mid-Range Users: Master SSH config, implement multiplexing, and explore port forwarding for development workflows.

🛡️ For Advanced Users: Harden SSH servers, implement 2FA, use certificates at scale, and integrate SSH into security frameworks.

🚀 For Everyone: SSH is more than remote access—it's tunneling, file transfer, proxy creation, and the foundation of secure DevOps.

The Developer Mindset:

SSH is infrastructure as code. Treat your ~/.ssh/config like a codebase:

Version control it (without private keys!)
Document your configurations
Automate key rotation
Test security configurations regularly
Share knowledge with your team

Final Advice:

Security is a practice, not a product. Review your SSH configuration quarterly, rotate keys annually, monitor access logs weekly, and stay informed about new vulnerabilities and best practices.

The time you invest in mastering SSH pays dividends throughout your entire career. Whether you're deploying production code, managing infrastructure, conducting security assessments, or building the next generation of cloud-native applications, SSH will be there—silent, powerful, and absolutely essential.

Stay secure, keep learning, and may your tunnels always be encrypted. 🔐

Quick Reference Cheat Sheet

# === Basic Commands ===
ssh user@host                          # Connect to remote host
ssh -p 2222 user@host                  # Connect on custom port
ssh user@host 'command'                # Execute remote command
scp file user@host:/path               # Copy file to remote
sftp user@host                         # Interactive file transfer

# === Key Generation ===
ssh-keygen -t ed25519 -C "comment"     # Generate Ed25519 key
ssh-keygen -t rsa -b 4096              # Generate RSA 4096-bit key
ssh-copy-id user@host                  # Copy public key to server

# === Port Forwarding ===
ssh -L 8080:localhost:80 user@host     # Local port forward
ssh -R 8080:localhost:80 user@host     # Remote port forward
ssh -D 1080 user@host                  # Dynamic SOCKS proxy

# === Advanced Options ===
ssh -J jump1,jump2 user@final          # ProxyJump through hosts
ssh -N -f user@host                    # Background tunnel (no shell)
ssh -C user@host                       # Enable compression
ssh -v user@host                       # Verbose output (debug)

# === Config File Example ===
# ~/.ssh/config
Host shortname
    HostName full.hostname.com
    User username
    Port 2222
    IdentityFile ~/.ssh/specific_key
    LocalForward 5432 db:5432
    ProxyJump bastion

# === Security Hardening ===
# /etc/ssh/sshd_config
Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers user1 user2

Remember: With great power comes great responsibility. Use SSH wisely and securely!

by HABIBULLAH

DEV Community: MD. HABIBULLAH SHARIF

Cut the Noise: The 10 Web Frameworks That Actually Matter in 2026

Before You Pick Anything - Answer These Three

1. React - The Undisputed King of Frontend

2. Next.js - React's More Serious Sibling

3. Express.js - The Minimal Backend Standard

4. ASP.NET Core - Enterprise's Favorite

5. Angular - Enterprise's Complete Toolkit

6. Django - Python's Fastest Path to Production

7. Laravel - PHP Done Right

8. Flutter - One Codebase, Native Everywhere

9. Vue.js - React's Friendlier Competitor

10. Spring Boot - The Java Enterprise Standard

Quick Decision Table

The Honest Rule

Code Never Runs First - The Lexer and Parser Do

Your code doesn't run the way you wrote it.

What Is a Lexer?

What Is a Parser?

Why Are They Two Separate Things?

Where You've Already Seen This

6‑Hour Hackathon Rescue: Dying API, rm -rf, and a Last‑Minute Win 🏆

🧠 Why This Matters Before I Even Start

👥 The Team That Shouldn't Have Won

💡 What We Built: NagrikAI

⚙️ Tech Stack — And Why Each Choice Was a Hackathon Decision

🔥 The Three Disasters (In Brutal Order)

Disaster #1 — The API That Lied to Us

Disaster #2 — The rm That Shouldn't Have Happened

Disaster #3 — $18 Over Budget, Then rm -rf

🎤 The Demo That Changed Everything

🏆 The Result

📰 It Made the News

🧩 What I Actually Learned

⚡ Before the hackathon:

🔧 During the hackathon:

🎯 For your pitch and demo:

🧭 On purpose:

🔗 The Project

💬 A Note to Every Developer Who's Been in That Moment

🤝 Connect With Me

Brave Browser Is the King in 2025–2026. There Is No Second Option

First — What Chrome Did and Why It Matters

Brave Shields — The Built-In Blocker That Extensions Can't Match

Want uBlock Origin Anyway? Add It.

What Google Never Gave You — What Brave Does by Default

Privacy That Goes Deeper Than Ad Blocking

HTTPS Everywhere — By Default

Fingerprint Protection

Tor Private Windows

Microsoft Recall — Blocked

The Features Others Don't Have

Brave Search — Independent Index

Leo AI — Private by Design

Brave Wallet — Built-In, No Extension

Brave Rewards — Optional, Your Choice

The Numbers

"But My Extensions / Google Services..."

Available Everywhere

The Honest Bit

Switch. Today.

Run Oracle SQL on Any PC Without the Nightmare (Docker + Linux Way)

A Word About Your OS Choice

What You'll Need

Step 1 — Launch Oracle with One Command

Step 2 — Wait for Oracle to Be Ready

Step 3 — Enter Oracle Directly from the Terminal

Step 4 — Connect with Beekeeper Studio or DBeaver

Step 5 — Basic SQL for Your Assignment

Create a table

Insert data

SELECT — retrieve data

UPDATE and DELETE

Create a second table and JOIN

Aggregates — GROUP BY, COUNT, AVG

Oracle-specific utilities

The Complete Docker Command Reference

The full workflow, from zero to SQL:

Common Issues & Fixes

Why Docker Beats the Native Installer

Disaster #2 — The `rm` That Shouldn't Have Happened

Disaster #3 — $18 Over Budget, Then `rm -rf`

The First Wall: `tsc` and Node Don't Get Along Like You Think