DEV Community: Sospeter Mong'are

Getting Started with Dagster: A Beginner's Guide

Sospeter Mong'are — Wed, 09 Sep 2026 14:17:58 +0000

Welcome! Let's create a simple Dagster project step by step. 🎉

Step 1: Scaffold a New Dagster Project

Open your WSL terminal and run:

pip install create-dagster
create-dagster project my-first-dagster-project

Then navigate into your project:

cd my-first-dagster-project

Step 2: Set Up Your Virtual Environment

python -m venv .venv
source .venv/bin/activate
pip install --editable .

Step 3: Your Project Structure

Your project should look like this:

.
├── pyproject.toml
├── README.md
├── src
│   └── my_first_dagster_project
│       ├── __init__.py
│       ├── definitions.py
│       └── defs
│           └── __init__.py
└── tests
    └── __init__.py

Step 4: Create Your First Asset

Inside src/my_first_dagster_project/defs/, create a file called assets.py and add this simple code:

import dagster as dg

@dg.asset
def my_first_asset():
    print("Hello from my first Dagster asset!")
    return [1, 2, 3, 4, 5]

@dg.asset
def my_second_asset(my_first_asset):
    total = sum(my_first_asset)
    print(f"The sum is: {total}")
    return total

Step 5: Register Your Assets in `definitions.py`

Open src/my_first_dagster_project/definitions.py and update it:

import dagster as dg
from my_first_dagster_project.defs.assets import my_first_asset, my_second_asset

defs = dg.Definitions(
    assets=[my_first_asset, my_second_asset],
)

Step 6: Launch the Dagster UI

Run the following command:

dg dev

Then open your browser and go to:
👉 http://127.0.0.1:3000

Step 7: Materialize Your Assets

In the Dagster UI, click on Assets in the top navigation
You should see my_first_asset and my_second_asset
Click Materialize All to run them
Watch them execute and check the logs! ✅

What Just Happened? 🤔

my_first_asset runs first and returns a list of numbers
my_second_asset depends on my_first_asset and calculates the sum
Dagster automatically figures out the execution order based on dependencies!

Question: Should I be running this everytime, Even though I installed Dagster?

Great question! No, you don't need to run those commands every time. Here's what each command does and when you need it:

One-Time Commands (Run Only Once)

These are setup commands you only run when creating a new project:

pip install create-dagster                        # Installs the create-dagster tool
create-dagster project my-first-dagster-project   # Creates your project folder

Think of it like creating a new folder/workspace — you only do it once! 1

Every Time You Work on Your Project

These are the commands you run each time you open a new terminal session:

# 1. Navigate to your project
cd my-first-dagster-project

# 2. Activate your virtual environment (REQUIRED every new terminal session)
source .venv/bin/activate

# 3. Start the Dagster UI
dg dev

Quick Summary Table

Command	When to Run
`pip install create-dagster`	✅ Once ever
`create-dagster project my-project`	✅ Once per new project
`python -m venv .venv`	✅ Once per new project
`source .venv/bin/activate`	🔁 Every new terminal session
`dg dev`	🔁 Every time you want to use the UI

Pro Tip 💡

Since you're on WSL (Windows), every time you open a new terminal, just run:

cd my-first-dagster-project
source .venv/bin/activate
dg dev

And you're good to go! 🚀

You're now running your first Dagster pipeline! Feel free to ask if you have any questions. 🚀

How to Install Dagster: WSL & Native Windows Guide for Beginners (Using pip)

Sospeter Mong'are — Wed, 09 Sep 2026 14:16:18 +0000

Introduction

Dagster is a modern data orchestration platform that helps you build, schedule, and monitor data pipelines. In this guide, we'll walk through two ways to install Dagster on a Windows machine using pip:

Via WSL (Windows Subsystem for Linux) - Recommended
Directly on Native Windows - Without WSL

Prerequisites

Before we begin, make sure you have:

Python 3.10 or higher installed (Python 3.13 is recommended) 1
A stable internet connection
Basic familiarity with the terminal/command prompt

Method 1: Installing Dagster via WSL (Recommended) 🐧

WSL (Windows Subsystem for Linux) lets you run a Linux environment directly on Windows. This is the recommended approach because Dagster works best in a Linux-like environment.

Step 1: Install WSL

Open PowerShell as Administrator and run:

wsl --install

This will install WSL with Ubuntu by default. Restart your computer when prompted.

Step 2: Set Up Ubuntu

After restarting:

Open Ubuntu from the Start Menu
Create a username and password when prompted
Update your packages:

sudo apt update && sudo apt upgrade -y

Step 3: Install Python

Check if Python is already installed:

python3 --version

If not installed or version is below 3.10, run:

sudo apt install python3 python3-pip python3-venv -y

Step 4: Create Your Dagster Project Folder

Create and navigate into a project folder:

mkdir my-dagster-project
cd my-dagster-project

Step 5: Create a Virtual Environment

python3 -m venv .venv

Step 6: Activate the Virtual Environment

source .venv/bin/activate

You should see (.venv) appear at the beginning of your terminal line. ✅

Step 7: Install Dagster Using pip

Now install Dagster and its dependencies: 2

pip install dagster dagster-webserver dagster-dg-cli

This installs:

dagster - The core Dagster library
dagster-webserver - The Dagster UI
dagster-dg-cli - The dg command line tool

Step 8: Scaffold a Dagster Project

Use the create-dagster CLI to scaffold a new project: 3

create-dagster project my-project
cd my-project

Step 9: Install Project Dependencies

pip install --editable . --group dev

Note: The --group argument requires pip 25.1 or higher. If you have an older version, upgrade pip first: 4

pip install --upgrade pip

Step 10: Verify the Installation

dg --version

You should see the version number printed in your terminal. 5

Step 11: Launch Dagster

dg dev

Open your browser and go to 👉 http://127.0.0.1:3000

Every Time You Return (WSL) 🔁

cd my-dagster-project/my-project
source .venv/bin/activate
dg dev

Method 2: Installing Dagster on Native Windows (Without WSL) 🪟

If you prefer not to use WSL, you can install Dagster directly on Windows using Command Prompt or PowerShell.

Step 1: Install Python

Go to python.org/downloads
Download Python 3.13 (recommended) 6
Run the installer
✅ Important: Check "Add Python to PATH" during installation

Verify the installation:

python --version

Step 2: Upgrade pip

Make sure you have the latest version of pip: 7

pip install --upgrade pip

Step 3: Create Your Dagster Project Folder

mkdir my-dagster-project
cd my-dagster-project

Step 4: Create a Virtual Environment

python -m venv .venv

Step 5: Activate the Virtual Environment

.venv\Scripts\activate

You should see (.venv) appear at the beginning of your terminal line. ✅

Step 6: Install Dagster Using pip

pip install dagster dagster-webserver dagster-dg-cli

Step 7: Scaffold a Dagster Project

create-dagster project my-project
cd my-project

Step 8: Install Project Dependencies

pip install --editable . --group dev

Note: The --group argument requires pip 25.1 or higher. If you have an older version, omit --group dev and install the CLI separately: 9

pip install dagster-dg-cli

Step 9: Verify the Installation

dg --version

You should see the version number of dg printed. 10

Step 10: Launch Dagster

dg dev

Open your browser and go to 👉 http://127.0.0.1:3000

Every Time You Return (Native Windows) 🔁

cd my-dagster-project\my-project
.venv\Scripts\activate
dg dev

WSL vs Native Windows: Which Should You Choose?

Factor	WSL 🐧	Native Windows 🪟
Recommended by Dagster	✅ Yes	⚠️ Works but less common
Ease of Setup	Moderate	Easy
Performance	Better	Good
Linux Commands	✅ Supported	❌ Not supported
Community Support	✅ More resources	⚠️ Limited
Best For	Developers & Data Engineers	Beginners on Windows

Troubleshooting Common Issues 🔧

❌ `dg` command not found

Make sure your virtual environment is activated:

WSL: source .venv/bin/activate
Windows: .venv\Scripts\activate

❌ Python version too old

Make sure you have Python 3.10+ installed. 11

❌ pip version too old

Upgrade pip with:

pip install --upgrade pip

❌ Port 3000 already in use

Run Dagster on a different port:

dg dev -p 8080

❌ Still stuck?

Reach out to the Dagster community for help at dagster.io/community 12

Summary

Step	WSL 🐧	Native Windows 🪟
Install Python	`sudo apt install python3`	Download from python.org
Create venv	`python3 -m venv .venv`	`python -m venv .venv`
Activate venv	`source .venv/bin/activate`	`.venv\Scripts\activate`
Install Dagster	`pip install dagster dagster-webserver dagster-dg-cli`	`pip install dagster dagster-webserver dagster-dg-cli`
Launch UI	`dg dev`	`dg dev`

You are now ready to start building amazing data pipelines with Dagster! 🚀

Happy orchestrating! 🎉

Running AI Models Locally on Windows

Sospeter Mong'are — Sat, 05 Sep 2026 04:39:25 +0000

Introduction

What if you could run your own AI assistant - one that works without the internet, costs nothing per message, never shares your data with anyone, and is available any time you need it? No subscriptions. No monthly limits. No worrying about what happens to your conversations.

That is exactly what running AI models locally means. Thanks to a free tool called Ollama, you can download and run powerful AI language models directly on your Windows laptop or desktop - the same way you would install any other application.

This guide will walk you through everything from scratch. No prior experience required. By the end, you will have your own AI assistant running on your machine, accessible both from the terminal and from a full browser-based chat interface that looks and feels just like ChatGPT.

Why Would You Want to Do This?

If ChatGPT and Claude already exist, why bother running something locally? Here are the real reasons people do it.

1. Complete Privacy
When you type into ChatGPT or Claude, your messages are sent to servers owned by OpenAI or Anthropic. Those companies may use your conversations to improve their models, and your data lives on their infrastructure. With a local model, your prompts never leave your computer. Not one word. This matters enormously when dealing with sensitive work documents, client data, medical information, or anything confidential.

2. Zero Cost
ChatGPT Plus costs around $20 per month. Claude Pro is similar. API usage costs money per request. Local models cost absolutely nothing after the initial download. You can run millions of messages and the bill stays at zero.

3. Works Completely Offline
Flying with no Wi-Fi? In a location with poor internet? Your local model does not care. Once downloaded, it runs entirely from your machine. No network required.

4. No Rate Limits or Message Caps
Cloud AI services throttle heavy users. You hit a limit, you wait. Local models have no such restriction. Run them as hard as you want for as long as you want.

5. Always Available
No service outages, no maintenance windows, no "ChatGPT is at capacity right now." Your model is there whenever you open your terminal.

6. Learning and Experimentation
Developers, researchers, and curious professionals use local models to experiment with AI, test prompts, build applications, and understand how these systems work - all without racking up API costs.

What You Need Before Starting

You do not need a powerful gaming machine. Here is what matters:

Operating System: Windows 10 or Windows 11
RAM: 8 GB minimum, 16 GB recommended
Free Disk Space: At least 5 GB, ideally 15 GB or more
GPU: Not required - models run on your CPU
Internet: Only needed for the initial download

RAM is the most important factor. The more you have, the better the model you can run:

8 GB RAM - run 1B to 2B models. Fast but basic.
16 GB RAM - run 2B to 4B models. Good balance of speed and quality.
32 GB RAM - run 7B to 13B models. Noticeably more capable.
48 GB RAM or more - run 70B models. Closest to GPT-4 quality locally.

Understanding Model Sizes

When you see terms like "2B" or "7B", the B stands for billion parameters. Parameters are the internal numbers that make up the model's knowledge and reasoning ability. More parameters generally means more capable responses, larger file size, more RAM required, and slower responses on CPU.

Think of it like engine size in a car. A 2B model is a small efficient engine - fast and economical. A 70B model is a high-performance engine - far more powerful but needs much more fuel (RAM) and takes longer to get going. For most everyday tasks on a standard laptop, a 3B to 7B model hits the sweet spot perfectly.

The Models Available on Ollama and What They Are Best At

Models come in different sizes. The bigger the parameter count, the more capable but the more RAM and time required. Here is a full breakdown from smallest to largest.

Small Models - 1B to 4B Parameters

Best for: laptops with 8–16 GB RAM, everyday tasks, fast responses

gemma2:2b - Google Gemma 2 (2 Billion)
Size: ~1.6 GB | RAM needed: 4–6 GB

ollama pull gemma2:2b

Google's lightweight model. The fastest option on CPU. Ideal for quick questions, short summaries, and simple drafts. Not suited for complex reasoning but excellent when speed matters more than depth.

Best used for:

Quick factual questions
Summarising short pieces of text
Simple email drafting
When you need a fast answer and don't need deep reasoning

phi3:mini - Microsoft Phi-3 Mini (3.8 Billion)
Size: ~2.2 GB | RAM needed: 6–8 GB

ollama pull phi3:mini

Trained on high-quality textbook-style content. Punches well above its weight on structured tasks. Best small model for code, JSON output, and step-by-step reasoning. If you are a developer this should be your first download.

Best used for:

Coding questions and debugging
Structured outputs like JSON or formatted data
Step-by-step explanations
Maths and logic problems
Following detailed instructions precisely

llama3.2:3b - Meta Llama 3.2 (3 Billion)
Size: ~2.0 GB | RAM needed: 6–8 GB

ollama pull llama3.2:3b

Meta's latest small model and the best all-rounder in the 3B range. Handles a wide variety of tasks reliably. This is the model most people should start with.

Best used for:

General conversation and everyday questions
Writing assistance - emails, reports, summaries
Explaining complex topics in plain language
Brainstorming and idea generation
Basic coding help
Translation and language tasks

qwen2.5:3b - Alibaba Qwen 2.5 (3 Billion)
Size: ~1.9 GB | RAM needed: 6–8 GB

ollama pull qwen2.5:3b

Alibaba's small model with exceptional multilingual capability and reliable structured output. If you work in multiple languages or need consistent JSON and formatted data, this is your pick at the small end.

Best used for:

Structured data extraction
JSON and formatted output tasks
Multilingual tasks - works well in multiple languages including non-English ones
Data classification and categorisation
Anything where consistent output format matters

mistral:7b - Mistral AI (7 Billion)
Size: ~4.1 GB | RAM needed: 8–12 GB

ollama pull mistral:7b

One of the most popular open source models ever released. Mistral 7B outperforms many models twice its size. Excellent all-rounder that handles nuanced writing, reasoning, and coding far better than the 3B models. If your machine has 16 GB RAM, start here instead of the smaller models. The quality jump from 3B to 7B is very noticeable.

Best used for:

Everything llama3.2:3b does, but better
Nuanced writing with more depth and flow
Coding with fewer errors
Longer documents where context matters
When you want noticeably better quality and have the RAM

Medium Models - 7B to 13B Parameters

Best for: machines with 16 GB RAM, more complex tasks, better reasoning

llama3.1:8b - Meta Llama 3.1 (8 Billion)
Size: ~4.7 GB | RAM needed: 10–14 GB

ollama pull llama3.1:8b

One of Meta's strongest open source releases. At 8B parameters it handles complex instructions, long documents, nuanced writing, and multi-step reasoning much better than the 3B version. This is the sweet spot for most people with 16 GB RAM - capable enough for serious work, still manageable on CPU.

Best used for:

Complex multi-step tasks and analysis
Long document summarisation
Detailed writing with nuance
Research assistance
Technical explanations

gemma2:9b - Google Gemma 2 (9 Billion)
Size: ~5.4 GB | RAM needed: 12–16 GB

ollama pull gemma2:9b

The bigger sibling of gemma2:2b. Substantially more capable while still being efficient. Strong at instruction following, summarisation of long texts, and factual question answering. Google specifically optimised this size for local deployment.

Best used for:

Summarising long reports and documents
Factual question answering with better accuracy
Instruction-following tasks requiring precision
When you want Google-quality output locally

deepseek-coder:6.7b - DeepSeek Coder (6.7 Billion)
Size: ~3.8 GB | RAM needed: 8–10 GB

ollama pull deepseek-coder:6.7b

A coding-specialised model that performs remarkably well for its size. Strong at Python, JavaScript, and SQL in particular. A practical alternative to CodeLlama if you want solid code assistance without large RAM requirements.

Best used for:

Python, JavaScript, SQL code generation
Debugging and error fixing
Code explanation and documentation
Writing unit tests

codellama:13b - Meta Code Llama (13 Billion)
Size: ~7.4 GB | RAM needed: 14–18 GB

ollama pull codellama:13b

Built specifically for code. If you are a developer and code assistance is your primary use case, CodeLlama at 13B is one of the best local options available. Handles Python, JavaScript, SQL, and many other languages. Can explain existing code, generate new code, and debug errors. Not designed for general conversation.

Best used for:

Serious code generation across many languages
Explaining and refactoring existing codebases
Generating tests and documentation
Complex debugging

phi3:medium - Microsoft Phi-3 Medium (14 Billion)
Size: ~7.9 GB | RAM needed: 14–18 GB

ollama pull phi3:medium

Microsoft's larger Phi-3 model. Takes everything phi3:mini does well - structured reasoning, code, precise instructions - and does it significantly better. Recommended for developers who need reliable code generation or anyone doing complex data tasks.

Best used for:

Advanced coding and structured output
Complex step-by-step reasoning
Data tasks requiring high precision
When phi3:mini is good but not quite good enough

mistral-nemo:12b - Mistral AI (12 Billion)
Size: ~7.1 GB | RAM needed: 14–18 GB

ollama pull mistral-nemo:12b

Mistral's newer medium model built in collaboration with NVIDIA. Very strong at instruction following, long context understanding, and technical writing. A step up from mistral:7b in quality while remaining practical on a 16 GB machine.

Best used for:

Long context tasks where the model needs to remember a lot
Technical documentation and writing
Detailed instruction following
Professional report drafting

llava:13b - LLaVA Multimodal (13 Billion)
Size: ~8.0 GB | RAM needed: 14–18 GB

ollama pull llava:13b

One of the very few local models that can look at images. Send it a photo, screenshot, diagram, or chart and ask questions about it. Not as capable as GPT-4 Vision but genuinely useful and completely private. If you need local image understanding, this is your only realistic option at this size.

Best used for:

Asking questions about screenshots or photos
Describing diagrams and charts
Reading text from images
Any task where you need to share a visual

Large Models - 27B to 70B Parameters

Best for: machines with 32 GB RAM or more, highest quality output, closest to cloud AI

gemma2:27b - Google Gemma 2 (27 Billion)
Size: ~16 GB | RAM needed: 20–28 GB

ollama pull gemma2:27b

Google's largest Gemma model. Strong across writing, reasoning, and instruction following. Well optimised for local inference compared to other models of similar size. A good first step into large models for anyone with 32 GB RAM.

Best used for:

High-quality long-form writing
Complex analysis and research assistance
Nuanced reasoning that smaller models struggle with
Professional-grade document drafting

deepseek-r1:32b - DeepSeek (32 Billion)
Size: ~19 GB | RAM needed: 24–32 GB

ollama pull deepseek-r1:32b

DeepSeek's reasoning-focused model that caused a stir when released for matching or beating much larger Western models on reasoning benchmarks. Exceptional at mathematical reasoning, logic problems, and complex analytical thinking.

Best used for:

Mathematical reasoning and problem solving
Logic and analytical tasks
Data interpretation
Step-by-step complex reasoning chains
Technical problem solving

codellama:34b - Meta Code Llama (34 Billion)
Size: ~20 GB | RAM needed: 24–32 GB

ollama pull codellama:34b

The large version of CodeLlama. For serious developers who need the highest quality local code assistance available. Handles complex codebases, generates tests, writes documentation, and debugs across many languages with significantly higher accuracy than the 13B version.

Best used for:

Enterprise-grade code generation
Complex multi-file code understanding
Architecture-level coding decisions
When codellama:13b is not good enough

mixtral:8x7b - Mistral AI Mixtral (47 Billion effective)
Size: ~26 GB | RAM needed: 32–48 GB

ollama pull mixtral:8x7b

A clever architecture called Mixture of Experts - it has 47 billion total parameters but only activates around 13 billion at a time, making it faster than a full 47B model. Excellent at complex reasoning, coding, and multilingual tasks. Delivers near GPT-4-level quality for many tasks.

Best used for:

Complex reasoning and analysis
High-quality multilingual work
Advanced coding tasks
When you want GPT-4-level quality locally and have the RAM

llama3.1:70b - Meta Llama 3.1 (70 Billion)
Size: ~40 GB | RAM needed: 48 GB or more

ollama pull llama3.1:70b

One of the most capable open source models in existence. Competitive with GPT-4 on many benchmarks. Handles complex legal analysis, long-form writing, advanced reasoning, and nuanced understanding at a level the smaller models simply cannot match. Not realistic on a standard laptop - best run on a high-RAM workstation or a machine with a dedicated GPU.

Best used for:

Tasks that currently require cloud AI quality
Complex legal, financial, or medical document analysis
High-quality long-form content creation
Advanced multi-step reasoning
Anything where you need the very best local model available

Specialised Models

nomic-embed-text - Nomic (Embedding Model)
Size: ~274 MB | RAM needed: Minimal

ollama pull nomic-embed-text

Not a chat model - an embedding model. Used by developers to convert text into numerical vectors for semantic search, document similarity, and RAG pipelines. Tiny and fast. Not for conversation but essential for many AI application development workflows.

Best used for:

Building semantic search systems
Document similarity comparison
RAG pipeline development
AI application development

Full Model Comparison Table

Model	Parameters	RAM Needed	Disk Size	Best For
gemma2:2b	2B	4–6 GB	1.6 GB	Fast answers, simple tasks
qwen2.5:3b	3B	6–8 GB	1.9 GB	Multilingual, structured data
llama3.2:3b	3B	6–8 GB	2.0 GB	General all-rounder
phi3:mini	3.8B	6–8 GB	2.2 GB	Code, JSON, structured output
mistral:7b	7B	8–12 GB	4.1 GB	Strong all-rounder, big quality jump
deepseek-coder:6.7b	6.7B	8–10 GB	3.8 GB	Coding, Python, JS, SQL
llama3.1:8b	8B	10–14 GB	4.7 GB	Complex tasks, long documents
gemma2:9b	9B	12–16 GB	5.4 GB	Summarisation, factual QA
mistral-nemo:12b	12B	14–18 GB	7.1 GB	Long context, technical writing
codellama:13b	13B	14–18 GB	7.4 GB	Code generation and debugging
llava:13b	13B	14–18 GB	8.0 GB	Image understanding
phi3:medium	14B	14–18 GB	7.9 GB	Advanced code and reasoning
gemma2:27b	27B	20–28 GB	16 GB	High quality general use
deepseek-r1:32b	32B	24–32 GB	19 GB	Math, logic, analytical reasoning
codellama:34b	34B	24–32 GB	20 GB	Enterprise-grade coding
mixtral:8x7b	47B eff.	32–48 GB	26 GB	Near GPT-4 quality
llama3.1:70b	70B	48 GB+	40 GB	Highest quality, needs workstation
nomic-embed-text	Small	Minimal	274 MB	Text embeddings for developers

Quick Reference - Which Model for Which Task

Task	Best Model
Quick everyday questions	gemma2:2b
Writing emails and reports	llama3.2:3b or mistral:7b
Coding and debugging	phi3:mini or deepseek-coder:6.7b
Serious code generation	codellama:13b or codellama:34b
Structured data and JSON	qwen2.5:3b
Multilingual tasks	qwen2.5:3b or mistral-nemo:12b
Long document analysis	llama3.1:8b or mistral-nemo:12b
Mathematical reasoning	deepseek-r1:32b
Image understanding	llava:13b
Fastest response	gemma2:2b
Best overall on 16 GB RAM	mistral:7b or llama3.1:8b
Best overall on 32 GB RAM	deepseek-r1:32b or gemma2:27b
Closest to GPT-4 quality	llama3.1:70b or mixtral:8x7b

What Should You Run Given Your Machine?

8 GB RAM:
Stick to gemma2:2b, llama3.2:3b, or phi3:mini. These run comfortably and handle most everyday tasks well.

16 GB RAM (most laptops):
Start with llama3.2:3b or mistral:7b. Add phi3:mini for code tasks and deepseek-coder:6.7b if you write a lot of code. You can also push to llama3.1:8b if you close other applications while running it.

32 GB RAM:
You can run llama3.1:8b, deepseek-r1:32b, or gemma2:27b comfortably. This is where local models start feeling genuinely close to cloud AI quality. The difference from 16 GB models is very noticeable.

32 GB RAM + GPU:
Ollama automatically uses your GPU if one is present. Models that took 30 seconds on CPU now respond in 2 to 3 seconds. At this point local AI becomes a serious daily driver that rivals cloud services on speed.

48 GB RAM or more:
You can run llama3.1:70b - one of the best open source models available anywhere. At this level you are genuinely competitive with GPT-4 for many tasks, running completely privately and at zero cost per message.

Advantages Over ChatGPT, Claude, and Other Cloud AI

Feature	Local (Ollama)	ChatGPT Plus	Claude Pro
Monthly Cost	Free	~$20/month	~$20/month
Privacy	100% local	Sent to OpenAI	Sent to Anthropic
Works Offline	Yes	No	No
Rate Limits	None	Yes	Yes
Response Speed	Moderate (CPU)	Very fast	Very fast
Image Input	llava only	Yes	Yes
Web Search	No (built-in)	Yes	Yes
Model Choice	Full control	Limited	Limited
Cost at Scale	Always free	Expensive	Expensive

Disadvantages - Being Honest

Local models are impressive but they are not a complete replacement for cloud AI in every situation. Here is what you should know:

They are slower. Cloud AI runs on massive GPU clusters. Your CPU takes longer to generate responses. Expect 5 to 30 seconds per paragraph depending on model size. Fine for most tasks, but slower than ChatGPT's near-instant replies.

Smaller models make more mistakes. The 2B to 4B models sometimes confidently state incorrect information. The larger the model the more reliable it becomes, but always verify important facts before acting on them.

No real-time information. These models were trained on data up to a certain date and cannot browse the internet. They cannot tell you today's news, current prices, or recent events.

Large models need large hardware. The most capable models require 32 GB or 48 GB RAM. These are not realistic on a standard laptop. If you only have 16 GB you are limited to the small and medium range.

First run is slow. The first time you run a model after starting Ollama, it loads from disk into RAM. This can take 10 to 30 seconds. After that, responses are faster.

Step 1 - Install Ollama on Windows

Open your browser and go to https://ollama.com/download and click Download for Windows.

Run the installer called OllamaSetup.exe. It installs quietly and starts a local server on your machine at http://localhost:11434. You will see the Ollama icon appear in your system tray.

Verify it installed correctly by opening PowerShell and running:

ollama --version

You should see a version number printed. If you see an error, close and reopen PowerShell and try again.

Step 2 - Download Your First Model

In PowerShell, run this to download the recommended all-rounder:

ollama pull llama3.2:3b

Then download others as needed. Each is around 2 to 8 GB:

ollama pull mistral:7b
ollama pull phi3:mini
ollama pull gemma2:2b
ollama pull qwen2.5:3b

See all downloaded models on your machine with:

ollama list

Step 3 - Chat via the Terminal

Start a conversation directly in PowerShell:

ollama run llama3.2:3b

You will see a >>> prompt. Just type your question and press Enter:

>>> What is the difference between RAM and storage?

The model responds. Ask follow-up questions just like ChatGPT. To exit:

>>> /bye

Try the other models the same way:

ollama run mistral:7b
ollama run phi3:mini
ollama run gemma2:2b

Useful terminal commands:

Command	What it does
`ollama list`	Show all downloaded models
`ollama run llama3.2:3b`	Start chatting with a model
`ollama pull mistral:7b`	Download a new model
`ollama rm gemma2:2b`	Delete a model to free disk space
`ollama serve`	Manually start the API if it stopped

Step 4 - Use a Proper Chat Interface in the Browser

The terminal works but a full browser-based interface is much more comfortable for everyday use. Open WebUI gives you a complete ChatGPT-style interface - model selector, conversation history, dark mode, everything - running entirely on your machine.

Install Open WebUI:

pip install open-webui

Start it:

open-webui serve

Leave this terminal window open. Then open your browser and go to:

http://localhost:8080

On your first visit you will be asked to create a local account. Use any username, email, and password you like - this account is stored entirely on your machine, nothing goes anywhere.

Once logged in you will see a full chat interface. Click the model dropdown at the top and select whichever model you want, then start chatting normally.

To stop Open WebUI, press Ctrl + C in the terminal window running it. To start it again next time, run open-webui serve and visit http://localhost:8080.

Tips for Getting Better Responses

Be specific about what you want.
Instead of "help me with this email" try "rewrite this email in a professional tone, keep it under 100 words, and make the call to action clear."

Tell it the format you want.
"Explain this in bullet points." "Give me a table comparing these options." "Respond in plain language for a non-technical audience."

Give it context.
"I am a software engineer working on a Python API. Explain this error message and suggest a fix."

Ask it to think step by step.
Simply adding "walk me through this step by step" significantly improves reasoning quality on smaller models.

Switch models for different tasks.
Use gemma2:2b for quick questions, phi3:mini or deepseek-coder for code, llama3.2:3b or mistral:7b for general writing, qwen2.5:3b for structured output, deepseek-r1:32b for analytical reasoning if your machine can handle it.

Upgrade your model when results disappoint.
If a response is not good enough, try the next size up. The quality difference between a 3B and 8B model on the same task is often significant.

Frequently Asked Questions

Does it use the internet after the models are downloaded?
No. Everything runs completely offline. Nothing you type leaves your machine.

Will it slow down my computer?
During inference your CPU usage will spike for a few seconds while generating a response. Other tasks may feel slightly sluggish during that time. Afterwards it returns to normal.

Can I use it for sensitive work documents?
Yes. Nothing leaves your machine, making it suitable for confidential documents, client data, and internal company information.

What if I want a more capable model than the ones listed?
Browse the full library at https://ollama.com/library. New models are added regularly as the open source AI community releases them.

How do I update a model when a newer version comes out?
Just pull it again: ollama pull llama3.2:3b. Ollama downloads the updated version automatically.

Can I run multiple models at the same time?
Yes, but each model loaded into RAM takes up its full allocation. On 16 GB RAM, running two 3B models simultaneously would use most of your available memory.

What if I have a GPU?
Ollama detects your GPU automatically and uses it. You do not need to configure anything. Response times drop dramatically - from 15 to 30 seconds down to 1 to 3 seconds on a mid-range GPU.

Summary

Running AI models locally on Windows is simpler than most people expect. Install one tool, download a model, and you are ready to go. The whole setup takes under 30 minutes.

You now have a private, free, offline AI assistant that runs on hardware you already own. It will not replace cloud AI for every task - complex reasoning and real-time information are still better handled by GPT-4 or Claude - but for the majority of everyday questions, writing assistance, coding help, and data tasks, your local model will serve you very well.

Start with llama3.2:3b for general use. Move to mistral:7b when you want better quality. Add phi3:mini for code. Explore the larger models as your needs grow. And enjoy having your own AI that answers to nobody but you.

Browse the full model library at https://ollama.com/library

KCB Funds Transfer API

Sospeter Mong'are — Mon, 31 Aug 2026 15:00:28 +0000

The KCB Funds Transfer API enables businesses and applications to securely initiate funds transfers programmatically without requiring manual intervention through the KCB banking platform (Mobile app and Web). This guide walks you through the API, request parameters, authentication, transaction flow, and how to successfully integrate and test a funds transfer.

What Is the KCB Funds Transfer API?

Banks have always let you move money through their apps or teller counters. The KCB Funds Transfer (FT) API lets you do that same thing from your own application - by writing code.

Instead of a human clicking "Send Money" in the KCB app, your system sends an HTTP request to KCB's servers, and the money moves. That's it at the core.

This is useful when you're building:

A business payment system (e.g. auto-paying suppliers)
A SaaS platform that needs to disburse funds to users
A financial dashboard that triggers bank transfers
Any system where money movement needs to be automated

What Can It Actually Do?

The KCB FT API supports four types of money movement:

Transfer Type	What It Means	Code
Internal Transfer	Between two KCB accounts	`IF`
RTGS	Large-value transfers to other banks	`RT`
EFT	Standard transfers to other banks	`EF`
Pesalink	Bank-to-bank transfers within Kenya's IPS	`PL`
Mobile Money	From KCB account to M-PESA wallet	`MO`

You pick the type that fits your use case and pass the right code in your request.

Before You Write Any Code

There are two environments: Sandbox (for testing) and Production (real money). Always start with Sandbox.

To Get Started on Sandbox

Register on the KCB Buni developer portal: sandbox.buni.kcbgroup.com
Create an application on the portal
Subscribe to the FT API - you'll get a Consumer Key and a Consumer Secret
Have a Callback URL ready (more on this below)
KCB will whitelist your Buni username and provide test account numbers

GOING LIVE (For Production (Real Money))

You'll additionally need:

A real KCB Bank account number
A signed Indemnity Form (KCB provides the template)
An FT Request Letter for integration approval

How the API Works - The Big Picture

The KCB FT API is asynchronous. This is the most important thing to understand as a beginner.

When you send a transfer request, you don't get back "success" or "failed" immediately. Instead:

You send the transfer request → KCB immediately replies: "Got it, we're processing"
KCB processes the transfer in their core banking system
KCB sends the result to your Callback URL via a POST request

This means your system needs to be able to receive incoming requests (a webhook endpoint), not just make outgoing ones. If you don't have a callback URL, you won't know whether transfers succeeded or failed.

Your App  ──POST──▶  KCB FT API  ──▶  Core Banking
                         │
                         └──POST──▶  Your Callback URL
                                      (result arrives here)

Step 1: Get an Auth Token

Every API call to KCB requires a Bearer Token. You get this by calling the token endpoint using your Consumer Key and Consumer Secret from the Buni portal.

POST https://uat.buni.kcbgroup.com/token?grant_type=client_credentials
Authorization: Basic <base64(consumerKey:consumerSecret)>

The response gives you an access token. Include it as a header in all subsequent requests:

Authorization: Bearer <your_token_here>

Tokens expire, so your application should handle token refresh - request a new one when the old one stops working.

Step 2: Send a Transfer Request

Once you have a token, you can initiate a funds transfer. Here's what the request body looks like:

{
  "beneficiaryDetails": "John Doe",
  "companyCode": "KE0010001",
  "creditAccountNumber": "1234567890",
  "currency": "KES",
  "debitAccountNumber": "9876543210",
  "debitAmount": 5000,
  "paymentDetails": "Invoice #1042 settlement",
  "transactionReference": "MYAPP20240831001",
  "transactionType": "IF",
  "beneficiaryBankCode": "01"
}

Let's break down each field:

Field	What It Is	Example
`beneficiaryDetails`	Full name of who receives the money	`"John Doe"`
`companyCode`	KCB's internal code for your bank branch	`"KE0010001"`
`creditAccountNumber`	Account that receives the money	`"1234567890"`
`currency`	Always `KES` for Kenyan Shillings	`"KES"`
`debitAccountNumber`	Your KCB account (the one being charged)	`"9876543210"`
`debitAmount`	Amount to transfer (in KES)	`5000`
`paymentDetails`	Short note about the transfer reason	`"Invoice settlement"`
`transactionReference`	Your unique ID for this transaction	`"MYAPP20240831001"`
`transactionType`	Type of transfer (see table above)	`"IF"`
`beneficiaryBankCode`	Bank code of the recipient's bank	`"01"` for KCB

The transactionReference field is critical. It must be unique per transaction - never reuse it. This is how you and KCB track the same transaction. A good pattern: prefix + date + sequential number, e.g. PAY20240831001.

Step 3: Handle the Response

When your request reaches KCB, they send back an immediate acknowledgement. Here's what success looks like:

{
  "statusCode": "0",
  "statusMessage": "Success",
  "statusDescription": "Request received for processing",
  "merchantID": "263eb626-3fe7-4662-813e-f6f2962219e1",
  "retrievalRefNumber": "PCI663RSS"
}

statusCode: "0" means KCB accepted your request. Save the merchantID - you can use it to reference this transaction later.

But this is not the final result. The transfer is still being processed.

Common Error Responses

Error	What It Means	Fix
`Missing Credentials`	Token is missing or wrong	Re-check your Bearer token
`Validation failed: Invalid crucial param`	A field is missing or wrong value	Review your request body
`Retrieval RefNumber already exist`	You reused a `transactionReference`	Generate a new unique reference
`Transaction failed due to limit rule`	Amount exceeds your daily/transaction limit	Adjust amount or check limits on FT portal

Step 4: Handle the Callback (The Real Result)

When KCB finishes processing, they POST to your Callback URL. This is what a successful notification looks like:

{
  "ftReference": "FT22060GXZGY",
  "transactionDate": "2022-07-06T11:08:40.019Z",
  "amount": "5000",
  "transactionStatus": "SUCCESS",
  "transactionMessage": "Processed Successfully",
  "beneficiaryAccountNumber": "1234567890",
  "beneficiaryName": "JOHN DOE",
  "transactionReference": "MYAPP20240831001",
  "merchantId": "1d2b13f8-ea62-465c-9fda-e18353579880",
  "debitAccountNumber": "9876543210"
}

Your callback endpoint should:

Check transactionStatus - it'll be SUCCESS or FAILED
Match transactionReference to the transfer you initiated
Update your database accordingly
Return an HTTP 200 OK so KCB knows you received the notification

Tip: Always match incoming callbacks to your own records using transactionReference. Never trust a callback blindly - verify the amount and accounts match what you sent.

Sending Money to M-PESA

To transfer from a KCB account to an M-PESA wallet, use transaction type MO and set beneficiaryBankCode to MPESA:

{
  "transactionType": "MO",
  "beneficiaryBankCode": "MPESA",
  "creditAccountNumber": "2547XXXXXXXX",
  "beneficiaryDetails": "Jane Wanjiku",
  ...
}

The creditAccountNumber in this case should be the recipient's phone number in the format 2547XXXXXXXX.

Sending to Other Banks

For inter-bank transfers (EFT, RTGS, Pesalink), you need the correct bank code for the recipient's bank. Here are the most common ones:

Bank	Code
KCB	01
Equity Bank	68
Co-op Bank	11
NCBA	07
Stanbic Bank	31
I&M Bank	57
DTB	63
Family Bank	70
Absa	03
M-PESA	MPESA

The full list is available in the API documentation appendix.

A Minimal Node.js Example

Here's a simple end-to-end example to get you oriented:

const axios = require('axios');

// Step 1: Get a token
async function getToken(consumerKey, consumerSecret) {
  const credentials = Buffer.from(`${consumerKey}:${consumerSecret}`).toString('base64');
  const response = await axios.post(
    'https://uat.buni.kcbgroup.com/token?grant_type=client_credentials',
    {},
    { headers: { Authorization: `Basic ${credentials}` } }
  );
  return response.data.access_token;
}

// Step 2: Initiate a transfer
async function sendTransfer(token) {
  const payload = {
    beneficiaryDetails: "John Doe",
    companyCode: "KE0010001",
    creditAccountNumber: "1234567890",
    currency: "KES",
    debitAccountNumber: "9876543210",
    debitAmount: 1000,
    paymentDetails: "Test payment",
    transactionReference: `PAY${Date.now()}`,  // unique reference
    transactionType: "IF",
    beneficiaryBankCode: "01"
  };

  const response = await axios.post(
    'https://uat.buni.kcbgroup.com/ft/transfer',  // confirm exact endpoint from KCB
    payload,
    { headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' } }
  );

  return response.data;
}

// Step 3: Callback handler (Express example)
app.post('/kcb/callback', (req, res) => {
  const { transactionReference, transactionStatus, amount } = req.body;

  if (transactionStatus === 'SUCCESS') {
    console.log(`Transfer ${transactionReference} succeeded - KES ${amount}`);
    // update your DB here
  } else {
    console.log(`Transfer ${transactionReference} FAILED`);
    // handle failure - notify user, reverse any internal state
  }

  res.status(200).send('OK');  // always acknowledge
});

Common Beginner Mistakes to Avoid

1. Not saving the transactionReference
If you don't store it, you can't match the callback to your original request.

2. Confusing "Success" response with a completed transfer
A statusCode: "0" means accepted, not completed. Wait for the callback.

3. Not handling duplicate callbacks
KCB may retry sending the callback if your server returns a non-200 response. Make your callback handler idempotent - processing the same transactionReference twice should not double-credit or double-update.

4. Using production credentials in development
Always use Sandbox for testing. Real money moves in Production.

5. Hardcoding the transactionReference
It must be unique per request. Generate it dynamically.

Quick Reference

Item	Detail
Sandbox Portal	sandbox.buni.kcbgroup.com
Token Endpoint	`POST /token?grant_type=client_credentials`
Auth Method	OAuth 2.0 (Basic Auth with Consumer Key + Secret)
Request Type	Async (result comes via callback)
Result Delivery	POST to your Callback URL
Support Email	buni@kcbgroup.com

Next Steps

Register on the KCB Buni portal
Create an application and subscribe to the FT API
Set up a test callback URL (tools like Webhook.site or ngrok are useful here)
Run a test internal transfer between the sandbox accounts KCB provides
Inspect the callback payload your server receives
Once confident, apply for Production access

For questions or integration support, reach out to the KCB Buni team at buni@kcbgroup.com or Whatsapp Me here

Cron Expressions in Airflow: Understanding `00 3 * * 1-7`

Sospeter Mong'are — Wed, 26 Aug 2026 07:49:29 +0000

If you are working with Apache Airflow, Linux, automation, or data pipelines, you will eventually encounter cron expressions.

At first, something like this can look confusing:

00 3 * * 1-7

But once you understand what each part represents, cron schedules become very easy to read and create.

In this article, we will break down the cron expression 00 3 * * 1-7, explain each component, and show how it is used in Airflow.

What Is a Cron Expression?

A cron expression is a format used to define when a scheduled task should run.

Cron is commonly used in:

Linux and Unix systems
Apache Airflow
Data engineering pipelines
Database jobs
ETL and ELT processes
Backup automation
Application maintenance
Server monitoring

A traditional cron expression contains five fields:

┌───── Minute
│ ┌─── Hour
│ │ ┌─ Day of month
│ │ │ ┌─ Month
│ │ │ │ ┌─ Day of week
│ │ │ │ │
00  3  *  *  1-7

Each field tells the scheduler a different part of the schedule.

Understanding `00 3 * * 1-7`

Let's break it down:

00 3 * * 1-7

Field	Value	Meaning
Minute	`00`	At minute 0
Hour	`3`	At 3 AM
Day of month	`*`	Every day
Month	`*`	Every month
Day of week	`1-7`	Monday through Sunday

Therefore:

00 3 * * 1-7 means run the task every day at 3:00 AM.

1. The Minute Field - `00`

The first field represents the minute.

This means the task runs at minute zero.

For example:

3:00 AM
4:00 AM
5:00 AM

If you used:

instead, the task would run at:

3:30 AM

So:

00 3

means:

At exactly 3:00.

2. The Hour Field - `3`

The second field represents the hour.

This means 3 AM.

Combined with the first field:

00 3

we get:

3:00 AM.

For example:

00 1

means 1:00 AM.

00 6

means 6:00 AM.

30 18

means 6:30 PM.

Cron generally uses the 24-hour clock, so:

3  = 3 AM
12 = 12 PM
15 = 3 PM
18 = 6 PM
23 = 11 PM

3. Day of Month - `*`

The third field represents the day of the month.

The asterisk means:

Every possible value.

Therefore:

in this position means every day of the month:

1
2
3
4
...
31

This means there is no restriction based on the date.

4. Month - `*`

The fourth field represents the month.

Again, we have:

This means:

Every month.

Therefore, the schedule applies to:

January
February
March
April
...
December

There is no restriction on the month.

5. Day of Week - `1-7`

The final field represents the day of the week.

1-7

The range means Monday through Sunday.

Typically:

1 = Monday
2 = Tuesday
3 = Wednesday
4 = Thursday
5 = Friday
6 = Saturday
7 = Sunday

Therefore:

1-7

means:

Every day of the week.

So the entire expression:

00 3 * * 1-7

means:

Run every day at 3:00 AM.

Cron Schedule Examples

Understanding a few examples makes cron much easier.

Every day at 3:00 AM

00 3 * * *

Meaning:

Run every day at 3:00 AM.

You could also write:

00 3 * * 1-7

Both express a daily schedule.

Every day at 6:30 AM

30 6 * * *

Meaning:

Run every day at 6:30 AM.

Every Monday at 3:00 AM

00 3 * * 1

Meaning:

Run every Monday at 3:00 AM.

Every Friday at 5:00 PM

00 17 * * 5

Meaning:

Run every Friday at 5:00 PM.

Every hour

00 * * * *

Meaning:

Run at minute 0 of every hour.

For example:

1:00
2:00
3:00
4:00
...

Every 15 minutes

*/15 * * * *

Meaning:

Run every 15 minutes.

For example:

Using Cron Expressions in Apache Airflow

Cron expressions are particularly useful in Apache Airflow because they allow you to control when DAGs should run.

For example:

from airflow import DAG

dag = DAG(
    dag_id="daily_pipeline",
    schedule="00 3 * * *",
)

This tells Airflow to schedule the DAG:

Every day at 3:00 AM.

You may also encounter:

schedule="00 3 * * 1-7"

This explicitly specifies Monday through Sunday.

In this particular case, however, the simpler:

schedule="00 3 * * *"

is easier to read because the * already means every day of the week.

Be Careful With Timezones in Airflow

One of the most important things to understand when working with Airflow schedules is the timezone.

Suppose your Airflow environment uses UTC.

If your DAG is scheduled for:

03:00 UTC

and you are working in Kenya, which uses East Africa Time (EAT), that corresponds to:

06:00 AM EAT

So if your intention is:

Run the pipeline at 3:00 AM Kenya time

you need to make sure your Airflow DAG and environment are configured with the appropriate timezone.

This is especially important for data engineering teams working across countries and regions.

Why Cron Expressions Matter in Data Engineering

Cron schedules are commonly used to control the execution of data pipelines.

For example, imagine you have a pipeline that:

Extracts data from a source database
Loads the data into a data lake
Transforms the data using dbt
Updates a data warehouse
Makes the data available for reporting

You might schedule the pipeline to run every morning:

00 3 * * *

The pipeline would then be triggered every day at 3:00 AM.

This is particularly useful when data needs to be processed before business users start working in the morning.

A Simple Way to Read Cron

Whenever you see a cron expression, read it from left to right:

MINUTE
HOUR
DAY OF MONTH
MONTH
DAY OF WEEK

For:

00 3 * * 1-7

you can translate it mentally as:

00    -> minute 0
3     -> hour 3
*     -> every day
*     -> every month
1-7   -> Monday to Sunday

Then combine everything:

Every day at 3:00 AM.

Quick Cron Cheat Sheet

Cron	Meaning
`00 3 * * *`	Every day at 3:00 AM
`00 3 * * 1`	Every Monday at 3:00 AM
`00 3 * * 1-5`	Monday to Friday at 3:00 AM
`00 3 * * 1-7`	Every day at 3:00 AM
`30 6 * * *`	Every day at 6:30 AM
`00 12 * * *`	Every day at noon
`00 18 * * 5`	Every Friday at 6:00 PM
`/15 * * *`	Every 15 minutes
`00 * * * *`	Every hour
`00 0 1 * *`	First day of every month at midnight

Final Takeaway

The cron expression:

00 3 * * 1-7

means:

Run every day of the week at exactly 3:00 AM.

The five cron fields are:

00    3    *    *    1-7
│     │    │    │      │
│     │    │    │      └── Day of week
│     │    │    └───────── Month
│     │    └────────────── Day of month
│     └─────────────────── Hour
└───────────────────────── Minute

Once you understand these five fields, you can read most basic Linux cron and Apache Airflow schedules without having to memorize them.

Understanding AI Model Pricing

Sospeter Mong'are — Mon, 24 Aug 2026 12:39:42 +0000

When you look at AI pricing for example cursor, you will often see four numbers:

Pricing component	What it means
Input	What you send to the AI
Cache Write	Information saved temporarily so it can be reused
Cache Read	Previously cached information that the AI reads again
Output	What the AI generates for you

These are usually priced per million tokens.

Let's break them down.

1. Input

Input is everything you give the AI.

This can include:

Your question
Your instructions
Code you provide
Files you ask it to analyze
Previous conversation/context
Relevant parts of your project

For example, you tell Cursor:

"Fix this Laravel authentication bug."

And Cursor sends your instructions plus relevant code to the AI.

That information is input.

Example

Suppose the model's input price is:

$2 per million tokens

If your request uses 10,000 input tokens:

10,000 / 1,000,000 × $2
= $0.02

So the input cost would be approximately $0.02.

2. Output

Output is what the AI generates in response.

For a coding assistant, output could include:

Code
Explanations
SQL queries
Suggestions
Refactored code
JSON
Documentation

Suppose a model costs:

$6 per million output tokens

If it generates 10,000 tokens:

10,000 / 1,000,000 × $6
= $0.06

So the output cost would be approximately $0.06.

Why is Output often more expensive?

Generating information is computationally expensive.

That's why you will often see something like:

Input: $2/M
Output: $6/M

The AI charges differently for what it reads and what it generates.

3. Cache Write

This one is slightly more complicated.

Imagine you are working on a large Laravel project.

Every time you ask Cursor something, Cursor may need to provide the AI with a lot of context about your project.

For example:

Laravel project
+ routes
+ controllers
+ models
+ migrations
+ services
+ configuration
+ existing code

Sending the same information repeatedly can be inefficient.

Caching allows some of that information to be stored temporarily so it can be reused.

When information is stored in the cache, that is called a:

Cache Write

In simple terms:

Cache Write = putting information into the AI's reusable memory/cache.

4. Cache Read

Once information has been cached, the AI can reuse it.

Instead of processing the information as completely new input again, it can read the cached information.

That's:

Cache Read

In simple terms:

Cache Read = using information that was already stored in the cache.

This is usually cheaper than sending the same information as completely new input.

For example, suppose:

Input = $2 / million tokens
Cache Read = $0.50 / million tokens

If you repeatedly work with the same project context, using the cache can significantly reduce the cost of processing that repeated context.

5. A Simple Real-World Example

Imagine you are building a Laravel application in Cursor.

You ask:

"Create an API endpoint for registering users."

Cursor might send:

Input

Your instructions + relevant Laravel code.

Then the AI generates:

Output

The controller, request validation, route and other code.

Now you ask:

"Add email verification."

Some of the project context may already be cached.

So instead of treating everything as completely new information, Cursor may use:

Cache Read

to reuse previously processed context.

If Cursor needs to add new information to the cache, that's:

Cache Write

6. Why Cache Pricing Can Be Confusing

You might see pricing like:

	Price per million tokens
Input	$2
Cache Write	$2.50
Cache Read	$0.20
Output	$10

At first, this can look confusing.

You might ask:

"Why am I being charged four different prices?"

Because the AI provider is measuring different types of token processing.

Think about it like a database:

Input = sending data to the database
Cache Write = storing frequently used data
Cache Read = retrieving stored data
Output = generating the result

The exact implementation of caching differs between AI providers, but this mental model is useful for understanding the pricing table.

7. Putting Everything Together

Let's say you use a model with:

Component	Price
Input	$2/M
Cache Write	$2.50/M
Cache Read	$0.20/M
Output	$10/M

During one interaction, suppose you use:

20,000 input tokens
5,000 cache-write tokens
50,000 cache-read tokens
10,000 output tokens

The approximate cost would be:

Input

20,000 / 1,000,000 × $2
= $0.04

Cache Write

5,000 / 1,000,000 × $2.50
= $0.0125

Cache Read

50,000 / 1,000,000 × $0.20
= $0.01

Output

10,000 / 1,000,000 × $10
= $0.10

Total

$0.04 + $0.0125 + $0.01 + $0.10
= $0.1625

So that interaction would cost approximately:

$0.16

The important lesson is that you don't simply multiply the model's headline price by the number of times you use it. The actual cost depends on how many tokens are processed in each category.

8. Which One Should You Pay Most Attention To?

As a beginner, focus on these two first:

Input

How much information are you asking the AI to process?

Output

How much information is the AI generating?

These are the easiest to understand.

Then learn:

Cache Read

This can help reduce the cost of repeatedly processing the same context.

Cache Write

This is related to putting information into the cache so it can potentially be reused.

9. Why This Matters When Using Cursor

This becomes especially important when you use Agent mode.

Suppose you ask Cursor to:

"Build a complete payment integration."

Cursor may need to understand:

Your existing application
Your database
Existing controllers
Routes
Models
Configuration
Payment code
Documentation
Your instructions

That's potentially a lot of context.

If you then continue asking:

"Now add callbacks."

"Now add transaction validation."

"Now add retries."

"Now write tests."

Cursor may repeatedly work with a large amount of project context.

This is one reason why Agent-heavy users can consume significantly more AI usage than developers who only use autocomplete or ask small questions.

10. The Easiest Way to Remember It

Think of an AI conversation like this:

Input

"Here is what I want and here is the information you need."

↓

Cache Write

"Store some of this information so we can reuse it."

↓

Cache Read

"Use information we already stored."

↓

Output

"Here is the answer/code I generated."

And because each operation can have a different computational cost, each can have a different price per million tokens.

That is what the four columns in Cursor's model pricing table are telling you.

Cursor Models and Pricing

Sospeter Mong'are — Mon, 24 Aug 2026 12:37:53 +0000

If you are new to Cursor, the pricing can look complicated because Cursor does not simply charge you based on "how many times you use AI."

The cost depends mainly on which AI model you use, how much you use it, and which Cursor plan you are on.

Think of Cursor like a car rental service:

Your Cursor plan is your monthly membership.
AI models are different cars.
Some cars are cheaper to drive, while others are more powerful and expensive.
Tokens are the fuel you consume.
When your included fuel runs out, you can either pay for more or upgrade your membership.

1. What is Cursor Mode?

Cursor allows you to use different AI models directly inside your code editor.

For example, you can ask AI to:

Write code
Explain code
Fix bugs
Refactor your application
Create database queries
Build features
Analyze errors
Work on multiple files
Make changes to your project using Agent mode

The important thing is that different AI models have different capabilities and costs.

Cursor groups these models into two main pools.

2. The Two Cursor Usage Pools

Cursor currently has two separate usage pools:

Pool 1: Cursor Models

This pool contains Cursor's own models, including:

Cursor Grok 4.6
Cursor Grok 4.5
Composer 2.5

These models come with generous included usage depending on your plan.

For most developers, this is the pool you will use regularly.

Pool 2: Other Models

This pool contains models from companies such as:

OpenAI
Anthropic
Google
Other providers

For example:

GPT-5.6 Luna
GPT-5.6 Sol
GPT-5.6 Terra
Claude Sonnet 5
Claude Opus 5
Gemini 3.1 Pro

These models consume your Other Models usage allowance.

3. What Are Tokens?

This is probably the most important concept to understand.

AI models don't charge you simply because you sent a message.

They measure usage in tokens.

A token is a small piece of text.

For example:

"Create a Laravel API for user registration."

The AI needs to process your request, your existing code, and potentially the response it generates.

This creates:

Input tokens + Output tokens = AI usage

So if you give the AI a huge Laravel project and ask it to modify several files, it can consume significantly more tokens than asking:

"What is dependency injection?"

Understanding AI Model Pricing

When you look at AI pricing, you will often see four numbers:

Pricing component	What it means
Input	What you send to the AI
Cache Write	Information saved temporarily so it can be reused
Cache Read	Previously cached information that the AI reads again
Output	What the AI generates for you

These are usually priced per million tokens.

Let's break them down.

1. Input

Input is everything you give the AI.

This can include:

Your question
Your instructions
Code you provide
Files you ask it to analyze
Previous conversation/context
Relevant parts of your project

For example, you tell Cursor:

"Fix this Laravel authentication bug."

And Cursor sends your instructions plus relevant code to the AI.

That information is input.

Example

Suppose the model's input price is:

$2 per million tokens

If your request uses 10,000 input tokens:

10,000 / 1,000,000 × $2
= $0.02

So the input cost would be approximately $0.02.

2. Output

Output is what the AI generates in response.

For a coding assistant, output could include:

Code
Explanations
SQL queries
Suggestions
Refactored code
JSON
Documentation

Suppose a model costs:

$6 per million output tokens

If it generates 10,000 tokens:

10,000 / 1,000,000 × $6
= $0.06

So the output cost would be approximately $0.06.

Why is Output often more expensive?

Generating information is computationally expensive.

That's why you will often see something like:

Input: $2/M
Output: $6/M

The AI charges differently for what it reads and what it generates.

3. Cache Write

This one is slightly more complicated.

Imagine you are working on a large Laravel project.

Every time you ask Cursor something, Cursor may need to provide the AI with a lot of context about your project.

For example:

Laravel project
+ routes
+ controllers
+ models
+ migrations
+ services
+ configuration
+ existing code

Sending the same information repeatedly can be inefficient.

Caching allows some of that information to be stored temporarily so it can be reused.

When information is stored in the cache, that is called a:

Cache Write

In simple terms:

Cache Write = putting information into the AI's reusable memory/cache.

4. Cache Read

Once information has been cached, the AI can reuse it.

Instead of processing the information as completely new input again, it can read the cached information.

That's:

Cache Read

In simple terms:

Cache Read = using information that was already stored in the cache.

This is usually cheaper than sending the same information as completely new input.

For example, suppose:

Input = $2 / million tokens
Cache Read = $0.50 / million tokens

If you repeatedly work with the same project context, using the cache can significantly reduce the cost of processing that repeated context.

5. A Simple Real-World Example

Imagine you are building a Laravel application in Cursor.

You ask:

"Create an API endpoint for registering users."

Cursor might send:

Input

Your instructions + relevant Laravel code.

Then the AI generates:

Output

The controller, request validation, route and other code.

Now you ask:

"Add email verification."

Some of the project context may already be cached.

So instead of treating everything as completely new information, Cursor may use:

Cache Read

to reuse previously processed context.

If Cursor needs to add new information to the cache, that's:

Cache Write

6. Why Cache Pricing Can Be Confusing

You might see pricing like:

	Price per million tokens
Input	$2
Cache Write	$2.50
Cache Read	$0.20
Output	$10

At first, this can look confusing.

You might ask:

"Why am I being charged four different prices?"

Because the AI provider is measuring different types of token processing.

Think about it like a database:

Input = sending data to the database
Cache Write = storing frequently used data
Cache Read = retrieving stored data
Output = generating the result

The exact implementation of caching differs between AI providers, but this mental model is useful for understanding the pricing table.

7. Putting Everything Together

Let's say you use a model with:

Component	Price
Input	$2/M
Cache Write	$2.50/M
Cache Read	$0.20/M
Output	$10/M

During one interaction, suppose you use:

20,000 input tokens
5,000 cache-write tokens
50,000 cache-read tokens
10,000 output tokens

The approximate cost would be:

Input

20,000 / 1,000,000 × $2
= $0.04

Cache Write

5,000 / 1,000,000 × $2.50
= $0.0125

Cache Read

50,000 / 1,000,000 × $0.20
= $0.01

Output

10,000 / 1,000,000 × $10
= $0.10

Total

$0.04 + $0.0125 + $0.01 + $0.10
= $0.1625

So that interaction would cost approximately:

$0.16

The important lesson is that you don't simply multiply the model's headline price by the number of times you use it. The actual cost depends on how many tokens are processed in each category.

8. Which One Should You Pay Most Attention To?

As a beginner, focus on these two first:

Input

How much information are you asking the AI to process?

Output

How much information is the AI generating?

These are the easiest to understand.

Then learn:

Cache Read

This can help reduce the cost of repeatedly processing the same context.

Cache Write

This is related to putting information into the cache so it can potentially be reused.

9. Why This Matters When Using Cursor

This becomes especially important when you use Agent mode.

Suppose you ask Cursor to:

"Build a complete payment integration."

Cursor may need to understand:

Your existing application
Your database
Existing controllers
Routes
Models
Configuration
Payment code
Documentation
Your instructions

That's potentially a lot of context.

If you then continue asking:

"Now add callbacks."

"Now add transaction validation."

"Now add retries."

"Now write tests."

Cursor may repeatedly work with a large amount of project context.

This is one reason why Agent-heavy users can consume significantly more AI usage than developers who only use autocomplete or ask small questions.

10. The Easiest Way to Remember It

Think of an AI conversation like this:

Input

"Here is what I want and here is the information you need."

↓

Cache Write

"Store some of this information so we can reuse it."

↓

Cache Read

"Use information we already stored."

↓

Output

"Here is the answer/code I generated."

And because each operation can have a different computational cost, each can have a different price per million tokens.

That is what the four columns in Cursor's model pricing table are telling you.

4. Why Do Different Models Cost Different Amounts?

Different AI models have different capabilities and operating costs.

For example, according to the pricing you provided:

Model	Input	Output
Composer 2.5	$0.50/M tokens	$2.50/M
Grok 4.6	$2/M	$6/M
GPT-5.6 Luna	$0.20/M	$1.20/M
GPT-5.6 Sol	$4/M	$20/M
Claude Sonnet 5	$2/M	$10/M
Claude Opus 5	$5/M	$25/M

The prices are per million tokens.

So don't look at a price like "$5" and think:

"Every time I use Claude, I pay $5."

No.

It means that processing one million tokens at that rate would cost that amount.

5. Cursor Plans

There are four main individual plans listed in the information you provided.

Plan	Monthly price	Other Models included
Start	₹649/month	$0
Pro	$20/month	$20
Pro Plus	$60/month	$70
Ultra	$200/month	$400

The important difference is how much AI usage you get.

6. Cursor Pro - $20/month

For most developers, Pro is the starting point worth considering.

You pay:

$20/month

You get:

Generous Cursor Models usage
$20 of Other Models usage
Unlimited Tab completions
Extended Agent usage
Bugbot
Cloud Agents

For example, if you are building Laravel applications and regularly use Agent mode, Pro can be a reasonable starting point.

7. Pro Plus - $60/month

Pro Plus costs:

$60/month

It includes:

$70 of Other Models usage

This is useful if you are a heavier AI coding user.

For example, you might use AI throughout the day for:

Writing features
Refactoring
Debugging
Writing tests
Database work
Documentation
Code reviews

If you regularly use expensive third-party models, you can consume your Pro allowance relatively quickly.

Pro Plus gives you a larger allowance.

8. Ultra - $200/month

Ultra is designed for very heavy users.

It costs:

$200/month

and includes:

$400 of Other Models usage

This is more suitable for power users who heavily rely on AI agents, automation and multiple models.

For an average developer who occasionally asks AI to write code, Ultra is probably unnecessary.

9. What Happens When You Use Up Your Allowance?

This is an important part of Cursor's pricing.

Suppose you have Pro.

You have:

$20 of Other Models usage

You eventually consume the entire $20.

You have two choices:

Option 1 - Add on-demand usage

You can continue using the models and pay for additional usage.

Option 2 - Upgrade

You can upgrade to a higher plan with a larger included allowance.

Importantly, reaching your included usage does not necessarily mean:

"Cursor stops working."

You can continue through additional paid usage if your account allows it.

10. Why Does Model Selection Matter?

Imagine you ask three different AI models to perform the same task.

You might ask:

"Build a complete Laravel authentication system."

One model might consume relatively little usage.

Another might consume significantly more.

A more powerful model can also generate more expensive output.

Therefore:

Your choice of model affects how quickly your usage allowance is consumed.

This is why Cursor gives you different models instead of forcing you to use one model.

11. Fast vs Normal Models

You may also see models such as:

Grok 4.6

and:

Grok 4.6 Fast

The Fast version is designed to provide faster responses, but according to the pricing you provided, it costs more per token.

For example:

Grok 4.6

Input: $2/M
Output: $6/M

While:

Grok 4.6 Fast

Input: $4/M
Output: $12/M

So you're effectively paying more for speed.

A simple way to think about it:

Normal = cheaper

Fast = more expensive, faster

12. What Is Auto?

Cursor also has an Auto feature.

Instead of manually selecting a model, you can allow Cursor to decide which model to use.

There are three Auto modes:

Auto Cost

Optimizes for cost.

Auto Balance

Attempts to balance cost and intelligence.

Auto Intelligence

Prioritizes intelligence/capability.

This is useful for beginners because you don't always need to understand every model.

You can essentially tell Cursor:

"Choose the appropriate model for me."

13. How Much Usage Do You Actually Need?

This is where things become easier.

Cursor's own guidance from the pricing information you provided is approximately:

Daily Tab users

Usually stay within:

$20/month

Limited Agent users

Often stay within:

$20/month

Daily Agent users

Typically:

$60-$100/month

Power users

People using multiple agents and automation can reach:

$200+/month

So your usage pattern matters more than simply saying:

"I am a developer."

14. What Does This Mean for a Developer?

Imagine three developers.

Developer A - Light AI user

They mostly use autocomplete and occasionally ask AI questions.

Pro is probably enough.

Developer B - Daily AI developer

They use Agent every day to build features, debug applications and modify multiple files.

They might consume:

$60-$100+ of usage per month.

Pro Plus may make more sense.

Developer C - AI-first developer

They spend most of their working day using AI agents and automation.

They may consume:

$200+ per month.

Ultra could make sense for them.

15. The Most Important Thing to Understand

Don't think about Cursor pricing as:

"How many AI messages do I get?"

Think about it as:

"How much AI computation am I consuming?"

A simple question such as:

"What does this function do?"

might consume very little.

But this:

"Analyze my entire Laravel application, identify architectural problems, refactor the authentication system, update the tests and fix all related errors."

can consume much more.

The second request requires the AI to process much more context and generate much more output.

16. What I Would Recommend for a Developer

If you're just getting started with Cursor:

Start with Pro - $20/month

Use it normally for a month.

Pay attention to:

How frequently you use Agent
Which models you use
How quickly your usage allowance decreases
How much of your work is being done through AI

If you consistently reach your limits, then consider:

Pro Plus - $60/month

If you're an extremely heavy AI user:

Ultra - $200/month

Don't immediately pay $200 just because Ultra has a much larger allowance.

17. The Simple Mental Model

You can remember Cursor pricing with this:

Plan = Your monthly membership

Model = The AI you choose

Tokens = How much you use

Usage pool = Your allowance

On-demand = Pay for additional usage

Fast = More expensive but faster

Auto = Let Cursor choose the model

And perhaps the most important one:

The more AI work you give Cursor, the more tokens you consume.

So if you are using Cursor primarily for coding, the biggest factor is not just the subscription price. Your development workflow and how heavily you rely on Agent and expensive models will determine your actual monthly cost.

AI System Prompts for Businesses: From Chatbots to Digital Employees

Sospeter Mong'are — Thu, 20 Aug 2026 03:32:00 +0000

As businesses adopt AI, one of the most overlooked components is the system prompt.

Many organizations think of a prompt as simply an instruction such as:

"You are a customer support assistant. Answer customer questions."

That may work for a simple chatbot, but it is not enough for a business-critical AI system.

A production AI system needs to understand its role, its responsibilities, its boundaries, the information it can access, the actions it can perform, and when it should involve a human.

In other words, a good system prompt is not just a question to an AI. It is closer to an operating policy for an AI employee.

What is an AI system prompt?

A system prompt defines how an AI should behave throughout an interaction.

For a business, it can establish things such as:

What the AI is responsible for
What it is allowed to do
What it must never do
What information it can use
How it should make decisions
When it should ask for clarification
When it should escalate to a human
How it should handle sensitive information
How it should respond when a tool fails

For example, a customer support AI should not simply be told to "help customers."

It should know:

Which products it supports
Which policies it can reference
What refunds it can authorize
What customer information it can access
Which actions require approval
What happens when it cannot find an answer
When a human agent must take over

This is where system prompts become particularly valuable in business.

A business AI needs boundaries

One of the biggest mistakes businesses can make is focusing only on what an AI can do.

The more important question is:

What should the AI not do?

Imagine a finance AI connected to a company's accounting system.

If the AI can access transactions, generate reports, and initiate financial actions, simply telling it to "help the finance team" is dangerous.

The system needs explicit boundaries.

For example:

It can analyze transactions.
It can generate reports.
It can identify suspicious transactions.
It cannot approve payments.
It cannot change financial records without authorization.
It cannot invent financial figures.
It must escalate unusual transactions to a human.

The AI's capabilities should therefore be matched with clearly defined authority.

A practical structure for business system prompts

A useful business system prompt can contain several sections.

1. Role

Define who the AI is.

For example:

"You are the Customer Support AI for ABC Insurance."

This gives the model a clear operational identity.

2. Objective

Define what success looks like.

For example:

"Your primary responsibility is to resolve customer questions accurately while minimizing unnecessary escalation to human agents."

This is better than simply saying "help customers."

3. Scope

Define what the AI is responsible for.

For example:

Answer product questions
Explain policies
Check claim status
Create support tickets

And explicitly define what is outside its scope.

4. Rules

These are the business policies the AI must follow.

For example:

Never invent information.
Only provide information from approved sources.
Do not expose confidential information.
Do not make unauthorized decisions.
Do not claim an action succeeded unless the system confirms it.

5. Data handling

Businesses need to think carefully about what information an AI can access.

A system prompt can establish rules such as:

Only request information necessary for the task.
Treat customer information as confidential.
Never request passwords or authentication codes.
Never expose internal system information.

However, the prompt should not be the only security mechanism. Permissions and access controls should exist outside the prompt as well.

6. Tool usage

Modern AI systems increasingly interact with tools.

An AI might have access to:

CRM systems
Databases
Payment APIs
Email
Ticketing systems
ERP systems
Internal APIs

The prompt should explain how those tools should be used.

For example:

"Before modifying customer information, verify the customer's identity and confirm that the requested operation is authorized."

The actual authorization should still be enforced by the underlying system.

7. Escalation

This is one of the most important parts.

The AI should know when not to act.

For example, a customer support AI should escalate when:

The customer explicitly requests a human.
The issue involves a disputed financial transaction.
A refund exceeds its authorization limit.
There is a potential security incident.
The customer threatens legal action.
The AI cannot find sufficient information.
A required system is unavailable.

A mature AI system understands that escalation is sometimes a successful outcome.

8. Failure handling

What happens when the AI's tools fail?

Suppose an AI calls a payment API and the API times out.

The AI should not tell the customer:

"Your payment was successfully processed."

Instead, it should know that the operation could not be confirmed.

This is a critical principle for AI automation:

Never confuse an attempted action with a successful action.

The system should verify outcomes before reporting success.

Different businesses can build different AI employees

The same architecture can support many business functions.

Customer Support AI

Responsible for resolving customer questions and support requests.

Sales AI

Can qualify leads, answer product questions, recommend products, and schedule meetings.

Finance AI

Can analyze transactions, generate reports, identify anomalies, and assist finance teams.

HR AI

Can answer questions about company policies, leave procedures, benefits, and onboarding.

IT Helpdesk AI

Can troubleshoot common technical issues, create tickets, and guide employees through approved procedures.

Data Analyst AI

Can answer business questions using approved datasets and generate analytical summaries.

Operations AI

Can monitor workflows, identify failures, and notify responsible teams.

Document Processing AI

Can extract information from documents, validate fields, classify documents, and route exceptions.

The key is that each AI needs a specific responsibility and authority model.

But a system prompt is not the AI system

This is perhaps the most important distinction.

A company can write an excellent system prompt and still build a terrible AI system.

Why?

Because a production AI system is much more than a prompt.

A useful mental model is:

AI Business System = Prompt + Knowledge + Tools + Permissions + Workflow + Monitoring + Human Escalation

Prompt

Defines how the AI should behave.

Knowledge

Provides trusted information.

This could include:

Company policies
Product documentation
FAQs
Contracts
Procedures
Internal documentation

This is where technologies such as RAG become useful.

Tools

Allow the AI to interact with business systems.

For example:

AI
 |
 +-- CRM
 +-- Database
 +-- Payment API
 +-- Email
 +-- Ticketing System

Permissions

Determine what the AI is actually allowed to do.

The prompt can say:

"You cannot approve payments."

But the stronger control is for the payment system itself to reject unauthorized payment approval requests.

This leads to an important engineering principle:

Do not rely on prompts for security.

Prompts provide behavioral guidance. Applications, APIs, identity systems, and databases should enforce security.

Workflow

Determines when the AI runs and what happens before and after it runs.

For example:

Customer request
       |
       v
AI analyzes request
       |
       +---- Simple question ---> Answer
       |
       +---- Support issue -----> Create ticket
       |
       +---- Sensitive action --> Human approval
       |
       +---- Unknown ----------> Escalate

This is where AI moves from being a chatbot to becoming part of a business process.

Monitoring

Businesses also need to know when their AI is failing.

They should monitor things such as:

Failed tool calls
Escalation rates
Incorrect responses
Response latency
Token usage
Business outcomes
API failures
Human overrides

This creates an important question for every AI automation:

What happens when it breaks, and who knows first?

The three questions before automating AI

Before building an AI workflow, businesses should ask three simple questions:

Who owns it?

Someone must be responsible for the AI system.

What does good look like?

Define measurable success.

For example:

70% of common support requests resolved automatically
Less than 2% incorrect responses
All financial actions require approval
Average response time below 10 seconds

What happens when it breaks, and who knows first?

There should be an escalation path, monitoring, alerting, and an accountable person or team.

These questions apply to both traditional automation and AI automation.

The future is not "AI everywhere"

Businesses should not automate a process simply because AI can automate it.

The better question is:

Where does AI create measurable business value without introducing unacceptable risk?

A customer support AI might make sense because thousands of repetitive questions can be handled automatically.

An AI approving million-shilling payments without human oversight might not.

The difference is not the AI model.

The difference is system design.

Final thought

The next stage of AI adoption in businesses will not simply be about giving employees access to ChatGPT.

It will be about building AI systems that operate inside real business processes.

These systems will have roles, permissions, knowledge, tools, workflows, monitoring, and escalation mechanisms.

And the system prompt will become one of the components that defines how these AI employees operate.

But businesses should remember:

A prompt can tell an AI what it should do. A well-engineered system determines what it can actually do.

That distinction is what separates an AI demo from a production AI system.

How to Set Up a VPS Server From Scratch (Complete Beginner's Guide)

Sospeter Mong'are — Wed, 19 Aug 2026 07:25:30 +0000

Introduction

You just bought a VPS (Virtual Private Server). You have an IP address, a root password, and a blank Ubuntu server staring back at you. What do you do next?

This is the question most beginners struggle with. Tutorials online tend to jump straight into deploying applications without covering the foundational work that every production server needs before a single line of application code is deployed.

This guide covers everything you need to do after buying a VPS, in the correct order. By the end you will have a secure, hardened, production-ready server capable of hosting PHP/Laravel applications, Node.js APIs, Python apps, multiple domains, SSL certificates, and databases.

Everything in this guide is based on a real Ubuntu 24.04 LTS server setup. The same principles apply to any Ubuntu or Debian-based VPS from providers like Contabo, DigitalOcean, Linode, or Vultr.

What Is a VPS and Why Does the Setup Matter?

A VPS is a virtual machine running on shared physical hardware in a data centre. Unlike shared hosting where everything is managed for you, a VPS gives you full root access to a Linux server. You control everything.

That freedom comes with responsibility. A freshly provisioned VPS is:

Accessible to the entire internet on port 22 (SSH)
Running as root by default
Accepting password-based logins
Already being scanned by bots within minutes of going live

If you skip the setup and jump straight to deploying your application, you are building on an insecure foundation. A poorly configured VPS can be compromised within hours of going online.

The setup process is not optional. It is the difference between a server that gets hacked and a server that does not.

Phase 1: Inspect Your Server Before Touching Anything

The first rule of working on any server is to understand what you have before you change anything. When you first log in, run a series of inspection commands to build a picture of your server.

Connect via SSH

ssh root@YOUR_VPS_IP

Your VPS provider will give you the root password in a welcome email. Once connected you will see a prompt like:

root@vps-hostname:~#

You are now logged in as root on your server.

Check the Operating System

cat /etc/os-release && uname -r

This tells you the exact OS version and kernel. Everything else depends on this. Ubuntu 24.04 LTS is the recommended choice for production servers as it is supported until April 2029.

Check CPU, RAM, and Disk

lscpu | grep -E "^CPU\(s\)|^Model name|^Thread|^Core"
free -h
df -h

Note how many CPU cores you have, how much RAM is available, and how much disk space you are working with. These numbers affect how you configure PHP workers, database buffers, and swap space later.

Check What Is Already Running

ss -tlnp
systemctl list-units --type=service --state=running

On a clean VPS from a reputable provider you should see almost nothing running except SSH. If you see MySQL, Redis, or a web server already running, note it before proceeding.

Check the Firewall

ufw status verbose

On most fresh Ubuntu VPS instances the firewall is installed but inactive. This means the only thing protecting your server right now is that nothing unexpected is listening. We will fix this shortly.

Check SSH Configuration

sshd -T | grep -E "^permitrootlogin|^passwordauthentication|^pubkeyauthentication|^port"

On a fresh VPS you will typically see:

permitrootlogin yes
passwordauthentication yes
pubkeyauthentication yes
port 22

This means root can log in with a password over the public internet. This is the most dangerous default configuration on any server and the first thing we will fix.

Phase 2: Secure SSH Access

SSH (Secure Shell) is the gateway to your server. Securing it is the single most important step in this entire guide.

Why Root Login Is Dangerous

When you log in as root, every command you run has unlimited power. A typo, a mistake, or a compromised session can destroy your entire server instantly. Worse, root is a known username that attackers target specifically. Brute force bots attempt thousands of root password combinations every hour against any server with port 22 open.

The solution is to create a separate administrative user that uses SSH keys instead of passwords.

Create a Non-Root Admin User

adduser yourname
usermod -aG sudo yourname

Choose a username that is not obvious. Avoid admin, ubuntu, or user as these are common brute force targets.

Set Up SSH Key Authentication

SSH keys are cryptographic key pairs. Your private key stays on your local machine. Your public key is installed on the server. When you connect, SSH verifies the keys match without ever transmitting a password.

On your local machine, check if you already have a key:

ls ~/.ssh/

If you see id_rsa and id_rsa.pub or id_ed25519 and id_ed25519.pub you already have a key pair. If not, generate one:

ssh-keygen -t ed25519 -C "your-email@example.com"

Ed25519 is the modern recommended key type. It is faster and more secure than the older RSA format.

View your public key:

cat ~/.ssh/id_ed25519.pub

The output is a long string starting with ssh-ed25519. This is safe to share openly.

Install the public key on the server by running this as root on the VPS:

mkdir -p /home/yourname/.ssh
echo "YOUR_PUBLIC_KEY_HERE" >> /home/yourname/.ssh/authorized_keys
chown -R yourname:yourname /home/yourname/.ssh
chmod 700 /home/yourname/.ssh
chmod 600 /home/yourname/.ssh/authorized_keys

The permissions are critical. SSH will refuse to use the key if the permissions are too open. 700 on the directory means only the owner can access it. 600 on the file means only the owner can read it.

Test the New User Before Changing Anything

Open a second SSH session and test logging in as your new user:

ssh yourname@YOUR_VPS_IP

You should be logged in without entering a password. Then verify sudo works:

sudo whoami

It should return root.

Do not close your original root session until this test passes. This is your safety net.

Harden the SSH Configuration

Only after confirming your new user works, back up and edit the SSH configuration:

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

Change these settings:

Setting	Change to
`PermitRootLogin yes`	`PermitRootLogin no`
`PasswordAuthentication yes`	`PasswordAuthentication no`
`X11Forwarding yes`	`X11Forwarding no`
`#MaxAuthTries 6`	`MaxAuthTries 3`
`#LoginGraceTime 2m`	`LoginGraceTime 30`

On Ubuntu 24.04, also check the override files in /etc/ssh/sshd_config.d/. Files in this directory can override settings in the main config. Make sure PasswordAuthentication no is consistent across all files in that directory.

Test the configuration before applying it:

sudo sshd -t

Silence means the configuration is valid. Then reload:

sudo systemctl reload ssh

Test root login from a new terminal. You should see Permission denied (publickey). Root is now blocked.

What If You Get Locked Out?

Every major VPS provider offers a web-based console in their control panel. This gives you direct access to the server regardless of SSH configuration. If you ever lock yourself out, log into your provider's control panel and use the console to fix the SSH config.

Phase 3: Configure the Firewall

Ubuntu ships with UFW (Uncomplicated Firewall). It is inactive by default. Configure and enable it before installing anything else.

Why You Need a Firewall

As you install software, some services will listen on public ports by default. MySQL, Redis, and PostgreSQL have all been compromised on servers where they were accidentally left exposed. A firewall provides a second layer of protection even when a service is misconfigured.

Set Default Policies

sudo ufw default deny incoming
sudo ufw default allow outgoing

Deny everything coming in, allow everything going out. Then explicitly allow only what needs to be public.

Allow Only What Is Necessary

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

Three rules. SSH for administration, HTTP for web traffic and SSL certificate validation, HTTPS for encrypted web traffic.

Never open these ports publicly:

Port	Service	Reason to keep it closed
3306	MySQL	No application needs direct public database access
5432	PostgreSQL	Same reason
6379	Redis	Redis with no password and public access leads to immediate compromise
3000	Node.js	App servers go behind Nginx, never directly public
8000	Python	Same reason

Enable the Firewall

sudo ufw enable

Verify the rules:

sudo ufw status verbose

You should see only ports 22, 80, and 443 allowed. Everything else is blocked.

Phase 4: Harden the Server

With SSH secured and the firewall active, harden the server itself.

Add a Swap File

A swap file is disk space used as overflow when RAM fills up. Without it, the Linux OOM (Out of Memory) killer will terminate processes randomly when memory runs out. On a server this usually means your database or web server gets killed unexpectedly.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

The last command makes swap permanent across reboots. Also reduce swappiness so the kernel prefers RAM over swap:

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl vm.swappiness=10

Set a Meaningful Hostname

sudo hostnamectl set-hostname your-server-name

Then update the hosts file:

sudo nano /etc/hosts

Find the line with your old hostname and replace it with the new one. A clear hostname like production-01 or app-server makes logs easier to read, especially when managing multiple servers.

Enable Automatic Security Updates

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Select Yes when prompted. This automatically installs security patches without requiring manual intervention. It applies security updates only, not major version upgrades, so it will not break your applications.

Disable Unnecessary Services

Ubuntu Server ships with services that serve no purpose on a VPS:

sudo systemctl stop ModemManager multipathd udisks2
sudo systemctl disable ModemManager multipathd udisks2

ModemManager handles mobile modems. multipathd manages multipath storage for enterprise SAN systems. udisks2 manages removable drives. None of these belong on a web server. Removing them reduces memory usage and attack surface.

Apply Kernel Hardening

sudo nano /etc/sysctl.d/99-hardening.conf

Add these settings:

# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Block SYN flood attacks
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Hide kernel pointers
kernel.kptr_restrict = 2

Apply immediately:

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

These settings protect against common network attacks including IP spoofing, SYN floods, and ICMP redirect attacks.

Phase 5: Install Nginx as Your Reverse Proxy

Nginx sits in front of all your applications. The internet talks to Nginx. Nginx decides where to send each request.

sudo apt install nginx -y
sudo systemctl enable nginx

The Nginx Architecture

Internet
    |
    v
Nginx (port 80/443)
    |
    +-- example.com        --> PHP-FPM (Laravel)
    |
    +-- api.example.com    --> Node.js on port 3000
    |
    +-- app.example.com    --> Python on port 8000

Your applications never talk to the internet directly. Only Nginx does. This gives you SSL in one place, security headers in one place, and the ability to run many applications on a single server.

Harden the Default Nginx Configuration

Open the main config:

sudo nano /etc/nginx/nginx.conf

Inside the http {} block, make these changes:

Hide the Nginx version number from response headers:

server_tokens off;

Enable gzip compression:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml;

Set sensible timeouts and upload limits:

client_max_body_size 64M;
client_body_timeout 30;
keepalive_timeout 65;
send_timeout 30;

Disable the Default Site

sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

Create Your Application Directories

sudo mkdir -p /var/www/example.com/public
sudo chown -R youruser:youruser /var/www/example.com

Create a Server Block for Each Site

For a Laravel application:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/current/public;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";
    add_header X-XSS-Protection "1; mode=block";

    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;
}

For a Node.js API:

server {
    listen 80;
    listen [::]:80;
    server_name api.example.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    access_log /var/log/nginx/api.example.com.access.log;
    error_log  /var/log/nginx/api.example.com.error.log;
}

Enable each site and test:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Always run nginx -t before reloading. If the test fails, Nginx keeps the old working configuration running.

Phase 6: Install Your Application Stack

PHP 8.3 and Composer

sudo apt install -y php8.3 php8.3-fpm php8.3-cli \
php8.3-mysql php8.3-pgsql php8.3-mbstring php8.3-xml \
php8.3-curl php8.3-zip php8.3-bcmath php8.3-opcache \
php8.3-intl php8.3-gd

curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer

Node.js LTS

Do not install Node.js from Ubuntu's default repositories. The version there is outdated. Use NodeSource:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Python and Virtual Environment Tools

Ubuntu 24.04 ships with Python 3.12. Add the tooling:

sudo apt install -y python3-pip python3-venv python3-dev

Always use virtual environments for Python applications. Never install application packages system-wide as this creates conflicts between projects.

Phase 7: Install and Secure Your Databases

MySQL

sudo apt install -y mysql-server
sudo mysql_secure_installation

During secure installation answer the prompts like this:

Validate password component: No
Remove anonymous users: Yes
Disallow root login remotely: Yes
Remove test database: Yes
Reload privilege tables: Yes

PostgreSQL

sudo apt install -y postgresql postgresql-contrib

Redis

sudo apt install -y redis-server
sudo sed -i 's/^bind 127.0.0.1 ::1/bind 127.0.0.1/' /etc/redis/redis.conf
sudo systemctl restart redis-server
sudo systemctl enable redis-server

The sed command restricts Redis to localhost only. Redis with no password and public internet access is one of the most common and damaging server compromises in existence. Always keep it bound to 127.0.0.1.

Accessing Databases Remotely

Your databases are not publicly accessible and should stay that way. To connect from your local machine using a tool like TablePlus, DBeaver, or HeidiSQL, use an SSH tunnel:

# MySQL tunnel
ssh -L 3306:127.0.0.1:3306 youruser@YOUR_VPS_IP -N

# PostgreSQL tunnel
ssh -L 5432:127.0.0.1:5432 youruser@YOUR_VPS_IP -N

Then connect your database client to 127.0.0.1 on the forwarded port. The connection travels through your encrypted SSH session. No database port is ever exposed to the internet.

Phase 8: Set Up Backups

A server with no backup strategy is a server waiting to fail. Set this up before deploying anything.

Create a backup script:

sudo mkdir -p /opt/backups/files
sudo nano /opt/backups/backup.sh

Add this content:

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/opt/backups/files"

# MySQL
mysqldump --all-databases --single-transaction | gzip > "$BACKUP_DIR/mysql_$DATE.sql.gz"

# PostgreSQL
sudo -u postgres pg_dumpall | gzip > "$BACKUP_DIR/postgres_$DATE.sql.gz"

# Nginx config
tar -czf "$BACKUP_DIR/nginx_$DATE.tar.gz" /etc/nginx/

# Remove backups older than 7 days
find "$BACKUP_DIR" -type f -mtime +7 -delete

Make it executable and schedule it:

sudo chmod +x /opt/backups/backup.sh
sudo crontab -e

Add this line to run every night at 2 AM:

0 2 * * * /opt/backups/backup.sh >> /var/log/backup.log 2>&1

Backups that exist only on the same server are not real backups. Set up offsite backup to Google Drive using rclone, to AWS S3, or to a separate server. If your VPS is compromised or the data centre has an incident, local-only backups go with it.

Phase 9: Monitor Your Server

Native Linux Tools

These are available immediately with no installation:

# Interactive process monitor
htop

# Disk usage
df -h

# Memory usage
free -h

# Real time Nginx access log
sudo tail -f /var/log/nginx/example.com.access.log

# Real time error log
sudo tail -f /var/log/nginx/example.com.error.log

# System logs
sudo journalctl -f

# Active listening ports
sudo ss -tlnp

Netdata Dashboard

Netdata gives you a real-time visual dashboard for CPU, RAM, disk, Nginx, MySQL, Redis, and PHP-FPM all in one place:

curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh
sudo sh /tmp/netdata-kickstart.sh --stable-channel --disable-telemetry

Netdata runs on port 19999. Do not open this port publicly. Access it via SSH tunnel:

ssh -L 19999:localhost:19999 youruser@YOUR_VPS_IP -N

Then visit http://localhost:19999 in your browser for the full dashboard.

External Uptime Monitoring

Sign up for a free account at UptimeRobot. Add your domain and it checks every 5 minutes, sending you an email or SMS the moment your site goes down. This catches server crashes, Nginx failures, and network issues before your customers do.

The Pre-Deployment Checklist

Before pointing any domain at this server or deploying any application, run through this checklist:

Security

[ ] Root SSH login is disabled
[ ] Password authentication is disabled
[ ] SSH key authentication is confirmed working
[ ] Admin user has sudo access
[ ] Firewall is active with only ports 22, 80, and 443 open
[ ] No database ports are publicly accessible
[ ] Redis is bound to localhost only
[ ] Kernel hardening parameters are applied
[ ] Unnecessary services are disabled

Stack

[ ] Nginx is running and enabled on boot
[ ] PHP-FPM is running and enabled on boot
[ ] Composer is installed
[ ] Node.js and npm are installed
[ ] Python and venv tools are installed
[ ] MySQL is installed and secured
[ ] PostgreSQL is installed
[ ] Redis is installed and localhost-only

Infrastructure

[ ] 2GB swap file is active and permanent
[ ] Hostname is set correctly
[ ] Automatic security updates are enabled
[ ] Backup script is created and scheduled
[ ] Backup script has been tested manually at least once
[ ] Offsite backup destination is configured
[ ] Uptime monitoring is active

Nginx

[ ] Default site is disabled
[ ] Server blocks exist for all your domains
[ ] nginx -t passes with no errors
[ ] server_tokens off is set
[ ] Security headers are in all server blocks
[ ] Log files are configured per site

What Comes Next

Once your checklist is complete your server is production ready. Here is what to do next:

Point your DNS first. Update your domain's A record to point to your server IP at your registrar. DNS propagation takes anywhere from a few minutes to 48 hours depending on your provider.

Install SSL certificates. Once DNS is pointing to your server, run Certbot to get free Let's Encrypt certificates for each domain. This takes under two minutes per domain.

Deploy your applications. Each application type has its own deployment process. Treat each one as a separate focused task rather than trying to deploy everything at once.

Create application databases. For each app, create a dedicated database user with only the permissions that app needs. Never use the root database user for application connections.

Common Mistakes to Avoid

Skipping the firewall. Every day you run without a firewall is a day your databases could be accidentally exposed. Enable UFW before installing any software.

Deploying as root. Applications should run as dedicated low-privilege users. Running as root means a compromised application has unlimited access to your entire server.

Using root for database connections. Always create application-specific database users with minimal permissions. The MySQL or PostgreSQL root user should never appear in an application config file.

Storing secrets in Git. Your .env file contains database passwords, API keys, and application secrets. It must never be committed to version control. Add .env to .gitignore before your first commit.

Skipping backups until later. Later never comes. Set up backups before your first deployment. The worst time to realise you have no backups is after something breaks.

Opening database ports publicly. Use SSH tunneling for database access from your local machine. Ports 3306 and 5432 should never appear in your UFW allowed rules.

Summary

Setting up a VPS correctly is not complicated but it requires doing things in the right order. Here is the sequence that matters:

Inspect the server before changing anything
Create a non-root admin user with SSH key authentication
Test the new user, then disable root login and password auth
Configure and enable the firewall before installing any software
Harden the server with swap, kernel parameters, and automatic updates
Install Nginx as a reverse proxy
Install your application stack: PHP, Node.js, Python
Install and secure your databases: MySQL, PostgreSQL, Redis
Set up automated backups with offsite storage
Set up monitoring and uptime alerts

Only after completing all of these steps should you point a domain to the server and begin deploying applications.

The time you invest in this setup pays back every single day your server runs without incident. A server configured this way can host multiple production applications for years without requiring significant maintenance or firefighting.

For technical assistance whatsapp me here

This guide is part of a series on production server management. Other articles in the series cover Nginx as a reverse proxy in depth, setting up free SSL certificates with Let's Encrypt, and deploying applications with zero-downtime releases.

Let's Encrypt SSL: A Beginner's Guide to Free HTTPS for Your Website

Sospeter Mong'are — Sun, 16 Aug 2026 19:15:27 +0000

Introduction

A few years ago, adding HTTPS to your website cost money — sometimes hundreds of dollars per year for an SSL certificate. Many small websites and developers skipped it entirely, leaving their users exposed.

Then in 2016, Let's Encrypt changed everything.

Today, there is no excuse for a website without HTTPS. Let's Encrypt provides free, trusted, automatically renewing SSL certificates to anyone with a domain name. It powers over 300 million websites worldwide and is trusted by every major browser.

This guide explains what SSL is, why it matters, how Let's Encrypt works, and exactly how to install it on an Nginx server running on Ubuntu.

What Is SSL and Why Does It Matter?

SSL (Secure Sockets Layer) — more accurately called TLS (Transport Layer Security) today, though the term SSL stuck — is a protocol that encrypts the connection between a visitor's browser and your web server.

Without SSL, data travels across the internet in plain text. Anyone between the visitor and your server — their ISP, a coffee shop router, a malicious actor on the same network — can read that data. This includes:

Login credentials
Credit card numbers
Personal information
Form submissions
Session cookies

With SSL, all of that data is encrypted. Even if intercepted, it is unreadable without the decryption key.

The Padlock in the Browser

You have seen it thousands of times — the padlock icon in the browser address bar next to a URL that starts with https://. That padlock means:

The connection between the browser and server is encrypted
The server's identity has been verified by a trusted Certificate Authority
Data cannot be intercepted or tampered with in transit

Without SSL, modern browsers display a "Not Secure" warning in the address bar. This alone drives visitors away and destroys trust in your website.

SSL Is Not Optional Anymore

Beyond security, SSL affects your website in several concrete ways:

Search Engine Rankings: Google confirmed in 2014 that HTTPS is a ranking signal. Two otherwise identical websites — one with HTTPS, one without — the HTTPS site ranks higher.

Browser Warnings: Chrome, Firefox, and Safari all display prominent "Not Secure" warnings on HTTP sites, especially on pages with login forms or payment fields.

HTTP/2: The modern HTTP/2 protocol — which makes websites significantly faster — requires HTTPS in all major browsers. No SSL means no HTTP/2.

User Trust: Studies consistently show that users abandon websites that display security warnings. For any website handling user data, SSL is non-negotiable.

What Is a Certificate Authority?

Your browser doesn't just trust any SSL certificate. It maintains a list of trusted Certificate Authorities (CAs) — organisations that have been vetted and approved to issue certificates.

When you install an SSL certificate, you are essentially telling browsers: "A trusted organisation has verified that I own this domain. You can trust this connection."

Traditionally, Certificate Authorities charged for this service — anywhere from $10 to $1,000+ per year depending on the certificate type. The revenue model made sense: the CA did the work of verifying your identity and browsers trusted their signature.

Let's Encrypt disrupted this entirely. It is a non-profit Certificate Authority — backed by Mozilla, Google, Cisco, and others — that issues certificates for free, automatically, and without any manual verification process.

What Is Let's Encrypt?

Let's Encrypt is a free, automated, open Certificate Authority launched in 2016 by the Internet Security Research Group (ISRG).

Its certificates are:

Free — no cost, ever
Trusted — recognised by all major browsers and operating systems
Automatic — issuance and renewal are fully automated
Open — the process is transparent and publicly audited

The only meaningful difference between a Let's Encrypt certificate and a paid certificate is the validation level. Let's Encrypt issues Domain Validated (DV) certificates, which verify you control the domain but do not verify your organisation's legal identity. For the vast majority of websites — blogs, SaaS applications, APIs, portfolios — DV certificates are perfectly sufficient.

If you run a bank or a large e-commerce platform that wants to display your company name in the browser bar, you might want an Extended Validation (EV) certificate from a paid CA. For everything else, Let's Encrypt is the right choice.

How Let's Encrypt Works

Let's Encrypt uses a protocol called ACME (Automatic Certificate Management Environment) to automate the entire certificate lifecycle.

Here is the process, simplified:

Step 1 — Domain Ownership Verification

Before issuing a certificate for example.com, Let's Encrypt needs to verify you actually control that domain. It does this through a challenge.

The most common challenge type is the HTTP-01 challenge:

Let's Encrypt tells your server to place a specific file at a specific URL — for example http://example.com/.well-known/acme-challenge/randomtoken
Let's Encrypt then fetches that URL from its servers
If the file is there with the correct content, domain ownership is proven
The certificate is issued

This entire process happens in seconds and is fully automated by Certbot.

Step 2 — Certificate Issuance

Once domain ownership is verified, Let's Encrypt issues a certificate valid for 90 days. This short validity period is intentional — it limits the window of exposure if a certificate is ever compromised, and it forces automation of renewal.

Step 3 — Automatic Renewal

Certbot installs a systemd timer (or cron job) that runs twice daily. It checks whether any certificate is within 30 days of expiring. If so, it automatically renews it — re-running the challenge, obtaining a new certificate, and reloading Nginx — all without any manual intervention.

In practice, your certificates renew themselves every 60-70 days, long before the 90-day expiry.

What Is Certbot?

Certbot is the official client tool for Let's Encrypt, maintained by the Electronic Frontier Foundation (EFF). It is the software you install on your server that:

Communicates with Let's Encrypt's ACME servers
Handles the domain ownership challenge automatically
Obtains and installs the SSL certificate
Configures Nginx (or Apache) to use it
Sets up automatic renewal

Without Certbot, you would need to manually interact with Let's Encrypt's API. Certbot makes the entire process a single command.

Prerequisites Before Running Certbot

Before you can install an SSL certificate, three things must be true:

1. Your Domain Must Point to Your Server

Let's Encrypt verifies domain ownership by making an HTTP request to your domain. If your domain's DNS is not pointing to your server's IP address, the challenge will fail and no certificate will be issued.

Check your DNS records at your registrar. You need:

Record	Type	Value
`example.com`	A	Your server IP
`www.example.com`	A	Your server IP
`api.example.com`	A	Your server IP

DNS changes can take anywhere from a few minutes to 48 hours to propagate, depending on your registrar and TTL settings. You can verify DNS has propagated using:

dig example.com +short

Or use an online tool like dnschecker.org.

2. Nginx Must Be Running and Configured

Certbot needs Nginx to be running with a server block configured for your domain. The server block does not need SSL yet — Certbot adds that. It just needs to exist and be active.

3. Port 80 Must Be Open

Certbot uses port 80 (HTTP) to complete the domain challenge. Your firewall must allow incoming traffic on port 80. If you followed the server setup guide in this series, UFW already has port 80 open.

Installing Certbot on Ubuntu with Nginx

Step 1 — Install Certbot

sudo apt install -y certbot python3-certbot-nginx

The python3-certbot-nginx plugin allows Certbot to automatically modify your Nginx configuration to enable SSL — you do not need to edit any config files manually.

Step 2 — Obtain Your First Certificate

sudo certbot --nginx -d example.com -d www.example.com

What the flags mean:

--nginx — use the Nginx plugin to automatically configure SSL
-d example.com — issue certificate for this domain
-d www.example.com — include this as an additional domain on the same certificate

You can include multiple -d flags to cover multiple subdomains on one certificate:

sudo certbot --nginx -d example.com -d www.example.com -d api.example.com

Step 3 — Answer the Prompts

Certbot will ask you a few questions:

Enter email address: you@example.com
Agree to terms of service: Y
Share email with EFF: N (your choice)
Redirect HTTP to HTTPS: 2 (Always redirect — recommended)

Choose option 2 for the redirect. This automatically adds an Nginx rule that sends all HTTP traffic to HTTPS, so visitors who type http://example.com are seamlessly redirected to https://example.com.

Step 4 — What Certbot Does Automatically

After you answer the prompts, Certbot:

Contacts Let's Encrypt servers
Places a challenge file in your web root
Let's Encrypt verifies the file
Certificate is issued and saved to /etc/letsencrypt/live/example.com/
Certbot modifies your Nginx config to enable SSL on port 443
Certbot adds the HTTP to HTTPS redirect on port 80
Nginx is reloaded

Your site is now serving HTTPS. The entire process takes under 60 seconds.

What Your Nginx Config Looks Like After Certbot

Before Certbot, your Nginx server block looked like this:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    ...
}

After Certbot runs, it transforms it into:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    root /var/www/example.com/public;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    ...your existing config...
}

The first server block catches all HTTP traffic and redirects it to HTTPS. The second handles all HTTPS traffic with your SSL certificate.

Where Certbot Stores Your Certificates

/etc/letsencrypt/
├── live/
│   └── example.com/
│       ├── fullchain.pem    ← Your certificate + intermediate chain
│       ├── privkey.pem      ← Your private key (keep this secret)
│       ├── cert.pem         ← Your certificate only
│       └── chain.pem        ← Intermediate certificates only
├── archive/
│   └── example.com/         ← Historical certificates (all versions)
└── renewal/
    └── example.com.conf     ← Renewal configuration

Important: The files in live/ are actually symbolic links pointing to the latest version in archive/. When Certbot renews your certificate, it creates new files in archive/ and updates the symlinks — so your Nginx config never needs to change.

Never delete anything in /etc/letsencrypt/ unless you know exactly what you are doing.

Automatic Certificate Renewal

This is where Let's Encrypt's real power shows. Certbot installs a systemd timer that runs twice daily:

# Check the timer status
sudo systemctl status certbot.timer

You will see it is active and scheduled to run at random times twice per day. The randomisation prevents all Certbot installations worldwide from hitting Let's Encrypt's servers simultaneously.

When the timer runs, Certbot checks each certificate. If any certificate expires within 30 days, it renews it automatically. In practice your certificates renew around the 60-day mark — well before the 90-day expiry.

Test Renewal Without Actually Renewing

sudo certbot renew --dry-run

This simulates the entire renewal process without actually changing anything. Run this after installation to confirm renewal will work when the time comes.

Expected output:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Managing Multiple Domains

If you host multiple websites on one server, you can have separate certificates for each domain:

# Certificate for your main app
sudo certbot --nginx -d example.com -d www.example.com

# Certificate for your API
sudo certbot --nginx -d api.example.com

# Certificate for another site
sudo certbot --nginx -d anotherdomain.com -d www.anotherdomain.com

Each domain gets its own certificate stored separately in /etc/letsencrypt/live/. Certbot manages renewal for all of them automatically.

List all your certificates:

sudo certbot certificates

Output:

Found the following certs:
  Certificate Name: example.com
    Domains: example.com www.example.com
    Expiry Date: 2026-11-14 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem

  Certificate Name: api.example.com
    Domains: api.example.com
    Expiry Date: 2026-11-14 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/api.example.com/fullchain.pem

Testing Your SSL Installation

After installing your certificate, verify it is working correctly.

Test in Your Browser

Visit https://example.com and click the padlock icon. You should see:

Connection is secure
Certificate is valid
Issued by: Let's Encrypt

Test with SSL Labs

SSL Labs provides a free, detailed SSL analysis of your domain. It checks:

Certificate validity
Certificate chain
Protocol support (TLS 1.2, TLS 1.3)
Cipher strength
Known vulnerabilities

A properly configured Let's Encrypt certificate with default Certbot settings typically scores A on SSL Labs.

Test from the Command Line

curl -I https://example.com

Expected output:

HTTP/2 200
server: nginx
...

The HTTP/2 200 confirms both HTTPS and HTTP/2 are working.

Common Problems and Solutions

Challenge Failed — Domain Not Pointing to Server

Error:

Challenge failed for domain example.com

Cause: DNS is not pointing to your server yet, or DNS has not propagated.

Solution:

# Check what IP your domain resolves to
dig example.com +short

# It must match your server IP
curl ifconfig.me

Wait for DNS propagation and try again.

Port 80 Is Blocked

Error:

Connection refused on port 80

Cause: Your firewall is blocking HTTP.

Solution:

sudo ufw allow http
sudo ufw status

Nginx Configuration Error

Error:

nginx: configuration file test failed

Solution:

sudo nginx -t

Fix whatever error it reports before running Certbot again.

Certificate Already Exists

If you run Certbot for a domain that already has a certificate, it will ask whether to renew, expand, or reinstall. Choose:

Renew — get a fresh certificate for the same domains
Expand — add new domains to the existing certificate
Reinstall — reinstall the existing certificate without changes

Rate Limits

Let's Encrypt has rate limits to prevent abuse:

Limit	Value
Certificates per domain per week	5
Duplicate certificates per week	5
Failed validations per hour	5

In practice you will never hit these limits in normal use. They only matter if you are repeatedly requesting certificates for the same domain due to testing or errors.

If you do hit a rate limit, you must wait before trying again. To avoid this during testing, use Let's Encrypt's staging environment:

sudo certbot --nginx --staging -d example.com

Staging certificates are not trusted by browsers but have much higher rate limits. Use staging to test your setup, then run without --staging for the real certificate.

Revoking a Certificate

If your private key is ever compromised, revoke the certificate immediately:

sudo certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem

Then obtain a new certificate:

sudo certbot --nginx -d example.com

The Bigger Picture — HTTPS Everywhere

Let's Encrypt's mission is to make HTTPS universal. Before it existed, the friction and cost of SSL certificates meant that millions of websites transmitted user data in plain text. Today there is no technical or financial barrier to HTTPS.

If you are building a web application, an API, or any internet-facing service, HTTPS is not a feature — it is a baseline requirement. Let's Encrypt removes every excuse not to have it.

Quick Reference — Certbot Commands

# Install Certbot
sudo apt install -y certbot python3-certbot-nginx

# Obtain certificate for a domain
sudo certbot --nginx -d example.com -d www.example.com

# List all certificates
sudo certbot certificates

# Test renewal (dry run)
sudo certbot renew --dry-run

# Force renewal immediately
sudo certbot renew --force-renewal

# Revoke a certificate
sudo certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem

# Delete a certificate
sudo certbot delete --cert-name example.com

# Check renewal timer
sudo systemctl status certbot.timer

# Test staging (no rate limits)
sudo certbot --nginx --staging -d example.com

Summary

Here is everything covered in this guide:

SSL encrypts the connection between your visitor and server — it is mandatory for any modern website
Let's Encrypt is a free, trusted, automated Certificate Authority that issues 90-day certificates
Certbot is the tool that talks to Let's Encrypt, installs your certificate, configures Nginx, and renews automatically
Domain ownership is verified via the HTTP-01 challenge — Let's Encrypt checks a file on your server
Certificates auto-renew every 60 days via a systemd timer — zero manual work required
Always run certbot renew --dry-run after setup to confirm renewal works
Use --staging for testing to avoid rate limits
SSL Labs gives you an independent grade of your SSL configuration

When your domain is pointed to your server and Nginx is configured, running Let's Encrypt takes less than two minutes. There is genuinely no reason to run any website without it.

What Is Nginx? A Beginner's Guide to the Web Server Powering the Modern Internet

Sospeter Mong'are — Sun, 16 Aug 2026 16:54:22 +0000

Introduction

If you have ever set up a website, deployed a web application, or rented a VPS (Virtual Private Server), you have almost certainly encountered the name Nginx (pronounced engine-x). It powers some of the busiest websites on the internet — including Netflix, Dropbox, and WordPress.com — yet many beginners find it intimidating at first glance.

This guide will change that.

By the end of this article, you will understand exactly what Nginx is, why it exists, how it works, and how to use it to serve real websites on a Linux server. No prior experience with web servers is required.

What Is Nginx?

Nginx is a web server — software that listens for requests coming from the internet and responds with web pages, files, or data.

But Nginx is more than just a web server. It is also:

A reverse proxy — it sits in front of your applications and forwards requests to them
A load balancer — it can distribute traffic across multiple servers
An HTTP cache — it can store and serve cached responses to reduce server load
An SSL terminator — it handles HTTPS encryption so your applications don't have to

Think of Nginx as the reception desk of a large office building. Every visitor (web request) walks in through the front door (port 80 or 443). The receptionist (Nginx) greets them, figures out where they need to go, and directs them to the right department — the Laravel team, the Node.js team, or the Python team. The visitor never wanders the building themselves.

Why Not Just Use Apache?

Apache is the other major web server and has been around since 1995. For years it dominated the web. So why does Nginx exist?

The answer comes down to architecture.

Apache creates a new thread or process for every incoming connection. This works fine for low traffic, but under heavy load — thousands of simultaneous connections — Apache consumes enormous amounts of RAM and CPU.

Nginx was built in 2004 specifically to solve this problem. It uses an event-driven, asynchronous architecture. Instead of one thread per connection, a single Nginx worker process can handle thousands of simultaneous connections efficiently using very little memory.

The result:

	Apache	Nginx
Architecture	Thread per connection	Event-driven
Memory usage under load	High	Low
Static file serving	Good	Excellent
Reverse proxy	Possible	Native, highly optimised
Configuration style	`.htaccess` per directory	Centralised config files

For modern application servers running Laravel, Node.js, or Python, Nginx is the industry standard choice.

How Nginx Fits Into a Real Server

Here is the architecture that professional developers use on production servers:

Internet
    |
    ▼
[ Nginx — Port 80/443 ]
    |
    ├──► example.com        → PHP-FPM (Laravel app)
    ├──► api.example.com    → Node.js running on port 3000
    └──► app.example.com    → Python running on port 8000

Notice that none of the applications talk directly to the internet. Only Nginx does. This is the reverse proxy pattern and it is fundamental to how modern servers work.

Why is this pattern so powerful?

Security: Your Node.js app running on port 3000 is never exposed to the internet. UFW (the firewall) blocks port 3000 publicly. Only Nginx — on port 443 — is reachable, and Nginx decides what to forward.

SSL in one place: Instead of configuring HTTPS in your Laravel app, your Node.js app, and your Python app separately, you configure it once in Nginx. All apps automatically get HTTPS.

Multiple apps on one server: Without a reverse proxy, you could only run one application per server (one thing can listen on port 80 at a time). With Nginx routing by domain name, you can run dozens of applications on a single server.

Static files: Nginx serves static files (images, CSS, JavaScript) directly from disk at incredible speed — without involving PHP, Node.js, or Python at all. This dramatically reduces load on your application.

Understanding Nginx Configuration

Nginx configuration lives in /etc/nginx/ on Ubuntu/Debian systems. Here is the directory layout:

/etc/nginx/
├── nginx.conf              ← Main configuration file
├── sites-available/        ← All site configs (active or not)
│   ├── example.com
│   └── api.example.com
├── sites-enabled/          ← Symlinks to active sites only
│   ├── example.com → ../sites-available/example.com
│   └── api.example.com → ../sites-available/api.example.com
├── conf.d/                 ← Additional configuration fragments
└── snippets/               ← Reusable configuration pieces

The sites-available and sites-enabled pattern

This is an elegant system. You write your site configuration in sites-available/. To activate it, you create a symbolic link (a shortcut) in sites-enabled/. To deactivate a site without deleting its configuration, you simply remove the symlink.

# Enable a site
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

# Disable a site (config is preserved)
sudo rm /etc/nginx/sites-enabled/example.com

Server Blocks — Nginx's Virtual Hosts

In Nginx, each website or application is configured using a server block. This is equivalent to Apache's Virtual Hosts. A server block tells Nginx: "When a request comes in for this domain name, here is how to handle it."

Example 1: Serving a Static HTML Website

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;

    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;
}

Let's break this down line by line:

listen 80 — listen for HTTP traffic on port 80
listen [::]:80 — also listen on IPv6
server_name example.com www.example.com — this block handles requests for these domain names
root /var/www/example.com/public — files are served from this directory
index index.html — the default file to serve when a directory is requested
try_files $uri $uri/ =404 — try to find the requested file; return 404 if not found
access_log and error_log — where to write logs for this site

Example 2: Serving a Laravel (PHP) Application

Laravel is a PHP framework that requires PHP-FPM to process .php files. Here is how Nginx is configured to work with it:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;

    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;
}

The key addition here is the location ~ \.php$ block. This tells Nginx: "For any request ending in .php, don't serve it as a static file — pass it to PHP-FPM for processing."

PHP-FPM (FastCGI Process Manager) is a separate service that runs PHP code and returns the result to Nginx. They communicate via a Unix socket (php8.3-fpm.sock) — a fast, secure local communication channel.

The location ~ /\.(?!well-known).* block denies access to hidden files (files starting with a dot, like .env). This is a critical security rule — your .env file contains database passwords and application secrets, and it must never be publicly accessible.

Example 3: Reverse Proxy to Node.js

When your Node.js/Express application is running on port 3000, Nginx forwards requests to it like this:

server {
    listen 80;
    listen [::]:80;
    server_name api.example.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    access_log /var/log/nginx/api.example.com.access.log;
    error_log  /var/log/nginx/api.example.com.error.log;
}

The proxy_pass http://localhost:3000 directive is the core of reverse proxying. Every request that hits api.example.com is forwarded to your Node.js process running locally on port 3000.

The proxy_set_header directives pass important information to your Node.js app — particularly X-Real-IP and X-Forwarded-For, which tell your application the real IP address of the visitor (since from Node.js's perspective, all requests appear to come from localhost).

Important Security Headers

Every Nginx server block should include these security headers:

add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";

X-Frame-Options SAMEORIGIN — prevents your site from being embedded in an iframe on another website (protects against clickjacking attacks)
X-Content-Type-Options nosniff — prevents browsers from guessing the content type of a response (protects against MIME type confusion attacks)
X-XSS-Protection — enables the browser's built-in cross-site scripting filter

Hiding the Nginx Version Number

By default, Nginx tells the world exactly which version it is running. This is visible in HTTP response headers:

Server: nginx/1.24.0

This is a gift to attackers — they can look up known vulnerabilities for that exact version. One line in your nginx.conf fixes this:

server_tokens off;

After this, the header simply shows:

Server: nginx

Testing and Reloading Configuration

This is the most important operational habit with Nginx. Always test your configuration before reloading.

# Test configuration syntax
sudo nginx -t

# If the test passes, reload gracefully
sudo systemctl reload nginx

The difference between reload and restart is important:

reload — applies the new configuration without dropping existing connections. Zero downtime.
restart — stops and starts Nginx completely. Active connections are dropped.

Always use reload in production. Only use restart if Nginx is genuinely broken and needs a full restart.

A passing test looks like this:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If you see any errors, fix them before reloading. A broken configuration with a running reload command will leave the old configuration running — Nginx is smart enough not to apply a broken config.

Understanding Nginx Worker Processes

When Nginx starts on a modern server, you will see multiple processes running:

nginx: master process
nginx: worker process
nginx: worker process
nginx: worker process
nginx: worker process

The master process manages the workers and handles configuration reloads. It runs as root so it can bind to ports 80 and 443.

The worker processes handle the actual connections. They run as the www-data user — a low-privilege account — so even if a worker is compromised, the damage is limited.

By default on Ubuntu 24.04, Nginx automatically sets the number of workers to match your CPU core count. On a 4-core server you get 4 workers. This is the correct production setting.

Nginx Logs

Every site configured in Nginx writes to its own log files:

# Access log — every request
/var/log/nginx/example.com.access.log

# Error log — problems and warnings
/var/log/nginx/example.com.error.log

To watch requests in real time:

sudo tail -f /var/log/nginx/example.com.access.log

To watch errors:

sudo tail -f /var/log/nginx/example.com.error.log

The access log shows you every request: the IP address, timestamp, requested URL, HTTP status code, and response size. The error log shows you configuration problems, upstream connection failures, and PHP-FPM errors.

Common Nginx Commands Reference

# Check if Nginx is running
sudo systemctl status nginx

# Start Nginx
sudo systemctl start nginx

# Stop Nginx
sudo systemctl stop nginx

# Reload configuration (zero downtime)
sudo systemctl reload nginx

# Test configuration syntax
sudo nginx -t

# Enable a site
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

# Disable a site
sudo rm /etc/nginx/sites-enabled/example.com

# View access logs in real time
sudo tail -f /var/log/nginx/example.com.access.log

# View error logs in real time
sudo tail -f /var/log/nginx/example.com.error.log

What Comes After Nginx?

Once Nginx is installed and configured, the typical next steps in building a production server are:

PHP and PHP-FPM — to run Laravel and other PHP applications
Node.js — to run Express.js APIs and applications
SSL certificates with Let's Encrypt — to serve everything over HTTPS
MySQL or PostgreSQL — for your application databases
Redis — for caching and queues

All of these work behind Nginx. The internet sees only Nginx. Everything else is internal.

Summary

Nginx is the backbone of modern web server infrastructure. Here is what you have learned in this guide:

Nginx is a web server, reverse proxy, load balancer, and SSL terminator
It uses an event-driven architecture that handles thousands of connections efficiently
The reverse proxy pattern keeps your applications hidden from the internet
Server blocks define how Nginx handles requests for each domain
PHP applications use PHP-FPM, Node.js and Python apps use proxy_pass
Always test configuration with nginx -t before reloading
Use reload not restart in production to avoid downtime
Security headers and server_tokens off are essential hardening steps

Nginx rewards the time you invest in learning it. Once you understand its architecture, managing multiple applications on a single server becomes straightforward, predictable, and reliable.

Airflow vs Cron: Is Apache Airflow Just a Cron Job?

Sospeter Mong'are — Wed, 12 Aug 2026 11:31:46 +0000

If you're new to data engineering, you may come across Apache Airflow and wonder:

"Isn't Airflow basically just a fancy cron job?"

The short answer is not exactly.

Airflow can do what cron does - schedule tasks to run at specific times - but Airflow is designed to solve a much bigger problem.

A useful way to think about it is:

Cron is primarily a scheduler. Airflow is a workflow orchestrator that also provides scheduling.

Let's break that down.

What is Cron?

Cron is a time-based job scheduler available on Unix and Linux systems.

You can tell cron:

"Run this command every day at 2 AM."

For example:

0 2 * * * python process_data.py

This means:

Every day at 2:00 AM
        |
        v
Run process_data.py

That's the main job of cron.

It answers:

When should this command run?

Cron is excellent for simple scheduled tasks.

For example:

Backing up a database
Cleaning temporary files
Running a simple script
Sending a scheduled report
Running a maintenance task

But things become more complicated when your process has many steps and dependencies.

What is Airflow?

Apache Airflow is a platform for developing, scheduling, and monitoring workflows.

Instead of simply saying:

"Run this command at 2 AM."

you can define an entire workflow.

For example:

2:00 AM
   |
   v
Extract data
   |
   v
Load staging tables
   |
   v
Run dbt transformations
   |
   v
Validate data
   |
   v
Send notification

Airflow understands the relationship between these tasks.

It knows that:

The transformation shouldn't run until the data has been loaded.

And:

The validation shouldn't run until the transformation has completed.

This is where Airflow goes beyond a traditional cron job.

Airflow uses DAGs

The workflows you create in Airflow are called DAGs, which stands for Directed Acyclic Graph.

Don't let the name scare you.

A DAG is essentially a definition of:

What tasks should run, in what order, and under what conditions?

For example:

Extract Customers
       |
       v
Load Customers
       |
       v
Run dbt Customers
       |
       v
Validate Customers

You can also have multiple branches:

             Extract Data
                  |
          +-------+-------+
          |               |
          v               v
   Load Customers    Load Policies
          |               |
          v               v
   dbt Customers     dbt Policies
          |               |
          +-------+-------+
                  |
                  v
            Final Validation

Airflow understands these dependencies.

Airflow can schedule tasks like cron

This is where the comparison comes from.

You can tell Airflow:

Run every day at 2 AM

or:

Run every hour

or:

Run every Monday

So yes, Airflow can perform the scheduling role of cron.

For example:

Every day at 2 AM
        |
        v
Start DAG
        |
        v
Execute workflow

But scheduling is only one part of Airflow.

The biggest difference: Dependencies

Imagine you have this workflow:

Extract data
     |
     v
Load staging
     |
     v
Run dbt
     |
     v
Validate

You don't want Run dbt to execute before Load staging has completed.

Airflow understands this dependency.

Cron, on the other hand, would typically require you to manually coordinate the schedules.

For example, you might end up with:

2:00 AM -> Extract
2:30 AM -> Load staging
3:30 AM -> Run dbt
4:00 AM -> Validate

But what happens if extraction takes 2 hours instead of 30 minutes?

Now your timing assumptions break.

Airflow doesn't need you to rely solely on fixed times.

It can say:

Extract completed successfully
        |
        v
Start Load
        |
        v
Load completed successfully
        |
        v
Start dbt

That's a much more reliable approach for complex workflows.

Airflow can retry failed tasks

Another important feature is retries.

Imagine your pipeline is loading data from an external database and the connection temporarily fails.

Instead of requiring someone to manually restart everything, Airflow can be configured to retry the task.

For example:

Load data
   |
   X
Failed
   |
   v
Wait
   |
   v
Retry
   |
   v
Success

You can configure things such as:

Number of retries
Retry delay
Timeout
Failure behavior

This is particularly useful for data pipelines that depend on external systems.

Airflow provides monitoring

Cron doesn't give you a sophisticated workflow monitoring interface.

You might have logs scattered across servers and applications.

Airflow provides a UI where you can see your workflows and tasks.

For example:

DAG: kehealth_elt

Task                     Status
------------------------------------
extract_claims            SUCCESS
load_claims               SUCCESS
dbt_staging_claims        SUCCESS
dbt_fct_claims            RUNNING
validate_claims           QUEUED

You can immediately see:

What has completed
What is currently running
What failed
What is waiting
How long a task has been running

This becomes extremely valuable when workflows have many steps.

Airflow handles failure paths

You can also define what should happen when something fails.

For example:

                 Run Task
                    |
              +-----+-----+
              |           |
           SUCCESS       FAIL
              |           |
              v           v
        Next Task       Retry
                          |
                    +-----+-----+
                    |           |
                 SUCCESS       FAIL
                    |           |
                    v           v
                 Continue     Alert

This gives you much more control than simply running a command from cron.

Airflow can orchestrate different technologies

Another major advantage is that Airflow doesn't care that every task uses the same technology.

One DAG could potentially orchestrate:

Oracle
   |
   v
Python
   |
   v
SQL
   |
   v
dbt
   |
   v
API
   |
   v
Data validation

For example:

Extract data from Oracle
        |
        v
Run SQL transformation
        |
        v
Run dbt model
        |
        v
Call an API
        |
        v
Validate results

Airflow acts as the coordinator.

How Airflow fits with ADF and dbt

This becomes particularly interesting in modern enterprise data platforms.

You might have an architecture like:

                 SOURCE
                   |
                   v
                 Oracle
                   |
                   v
                  ADF
                   |
                   v
              STAGING TABLES
                   |
                   v
                AIRFLOW
                   |
                   v
                  DBT
                   |
             +-----+-----+
             |           |
             v           v
        Dimensions      Facts
             |           |
             +-----+-----+
                   |
                   v
             Data Consumers

Each technology has a different responsibility.

ADF

ADF may handle:

Connecting to source systems
Extracting data
Moving data
Loading staging tables
Initial orchestration

Think:

"Get the data from A to B."

Airflow

Airflow may handle:

Scheduling
Dependencies
Workflow orchestration
Retries
Monitoring
Error handling
Coordinating different processes

Think:

"Make sure the entire workflow happens in the right order."

dbt

dbt may handle:

Data transformation
Business logic
SQL models
Facts
Dimensions
Data tests

Think:

"Turn the raw/staged data into useful business data."

A real-world example

Imagine an insurance company wants to process claims every night.

The workflow might look like this:

              Oracle
                |
                v
               ADF
                |
                v
       Claims staging table
                |
                v
             Airflow
                |
                v
       Run dbt transformations
                |
                v
          fct_claims
                |
                v
          Data validation
                |
                v
            Reporting

At 2 AM, Airflow could start the workflow.

ADF extracts the claims data from Oracle and loads it into staging.

Once the staging process is complete, Airflow can trigger the dbt models.

dbt transforms the staged data into the final fact and dimension tables.

Airflow then runs validation tasks.

If everything succeeds:

SUCCESS

If something fails:

FAILURE
   |
   +--> Retry
   |
   +--> Log error
   |
   +--> Notify team

That's much more sophisticated than:

2:00 AM
   |
   v
Run script

So, is Airflow a cron job?

The best answer is:

Airflow includes scheduling capabilities similar to cron, but it is not simply a cron job.

Think about the difference this way:

Capability	Cron	Airflow
Schedule tasks	Yes	Yes
Run scripts	Yes	Yes
Manage dependencies	Limited	Yes
Retry failed tasks	Basic/manual	Yes
Workflow visualization	No	Yes
Task monitoring	Limited	Yes
Complex workflows	Difficult	Designed for it
Data pipelines	Not its primary purpose	Designed for it
dbt orchestration	Possible	Common use case
Failure handling	Basic	Advanced

A simple analogy

Imagine you're managing a restaurant.

Cron is an alarm clock.

It says:

"At 6 PM, start cooking."

Airflow is the restaurant manager.

It says:

"At 6 PM, start preparing the food. Once the ingredients are ready, start cooking. Don't serve until the food is ready. If the oven fails, retry. If the problem continues, alert the manager. Keep track of what has been completed."

That's the fundamental difference.

The mental model to remember

If you're working with ADF, Airflow, and dbt, a useful mental model is:

ADF
  |
  | Move/ingest data
  v
STAGING
  |
  v
Airflow
  |
  | Orchestrate workflow
  v
dbt
  |
  | Transform data
  v
FACTS / DIMENSIONS

So instead of thinking:

"Airflow is just another cron job."

think:

"Cron schedules commands. Airflow schedules and orchestrates workflows."

That distinction becomes very important once your data pipelines start having multiple dependencies, retries, validations, long-running tasks, and different systems that need to work together.

DEV Community: Sospeter Mong'are

Getting Started with Dagster: A Beginner's Guide

Step 1: Scaffold a New Dagster Project

Step 2: Set Up Your Virtual Environment

Step 3: Your Project Structure

Step 4: Create Your First Asset

Step 5: Register Your Assets in definitions.py

Step 6: Launch the Dagster UI

Step 7: Materialize Your Assets

What Just Happened? 🤔

One-Time Commands (Run Only Once)

Every Time You Work on Your Project

Quick Summary Table

Pro Tip 💡

How to Install Dagster: WSL & Native Windows Guide for Beginners (Using pip)

Introduction

Prerequisites

Method 1: Installing Dagster via WSL (Recommended) 🐧

Step 1: Install WSL

Step 2: Set Up Ubuntu

Step 3: Install Python

Step 4: Create Your Dagster Project Folder

Step 5: Create a Virtual Environment

Step 6: Activate the Virtual Environment

Step 7: Install Dagster Using pip

Step 8: Scaffold a Dagster Project

Step 9: Install Project Dependencies

Step 10: Verify the Installation

Step 11: Launch Dagster

Every Time You Return (WSL) 🔁

Method 2: Installing Dagster on Native Windows (Without WSL) 🪟

Step 1: Install Python

Step 2: Upgrade pip

Step 3: Create Your Dagster Project Folder

Step 4: Create a Virtual Environment

Step 5: Activate the Virtual Environment

Step 6: Install Dagster Using pip

Step 7: Scaffold a Dagster Project

Step 8: Install Project Dependencies

Step 9: Verify the Installation

Step 10: Launch Dagster

Every Time You Return (Native Windows) 🔁

WSL vs Native Windows: Which Should You Choose?

Troubleshooting Common Issues 🔧

❌ dg command not found

❌ Python version too old

❌ pip version too old

❌ Port 3000 already in use

❌ Still stuck?

Summary

Running AI Models Locally on Windows

Introduction

Why Would You Want to Do This?

What You Need Before Starting

Understanding Model Sizes

The Models Available on Ollama and What They Are Best At

Small Models - 1B to 4B Parameters

Medium Models - 7B to 13B Parameters

Large Models - 27B to 70B Parameters

Specialised Models

Full Model Comparison Table

Quick Reference - Which Model for Which Task

What Should You Run Given Your Machine?

Advantages Over ChatGPT, Claude, and Other Cloud AI

Disadvantages - Being Honest

Step 1 - Install Ollama on Windows

Step 2 - Download Your First Model

Step 3 - Chat via the Terminal

Step 4 - Use a Proper Chat Interface in the Browser

Tips for Getting Better Responses

Frequently Asked Questions

Summary

KCB Funds Transfer API

What Is the KCB Funds Transfer API?

What Can It Actually Do?

Before You Write Any Code

To Get Started on Sandbox

GOING LIVE (For Production (Real Money))

How the API Works - The Big Picture

Step 1: Get an Auth Token

Step 5: Register Your Assets in `definitions.py`

❌ `dg` command not found

Understanding `00 3 * * 1-7`

1. The Minute Field - `00`

2. The Hour Field - `3`

3. Day of Month - `*`

4. Month - `*`

5. Day of Week - `1-7`