DEV Community: Sospeter Mong'are

Stop Giving AI Coding Agents Your Passwords: A Practical Guide to Secure Credentials

Sospeter Mong'are — Fri, 25 Sep 2026 19:31:56 +0000

AI coding agents such as Cursor, Claude Code, GitHub Copilot and other agentic development tools are changing how developers build and deploy software.

They can read your code, modify files, run terminal commands, execute tests and, depending on how they are configured, interact with your servers and deployment infrastructure.

That power is useful - but it also introduces a security problem:

How do you give an AI coding agent enough access to deploy and troubleshoot your application without giving it the keys to your entire infrastructure?

The answer is not simply "put your password in a .env file."

The better approach is to use least privilege, scoped credentials, SSH keys, CI/CD secrets and separate deployment accounts.

Here is a practical approach.

1. Never Paste Your VPS or cPanel Password Into an AI Chat

This should be your first rule.

Avoid prompts like:

My VPS password is MySuperSecretPassword123.

SSH into the server and deploy my application.

Or:

cPanel username: myuser
cPanel password: MyPassword123

Even if you trust the AI tool, you are unnecessarily exposing a credential through a conversation.

That credential could potentially appear in:

Chat history
Terminal output
Agent logs
Debug output
Screenshots
Project files
Shell history
Deployment logs

More importantly, you are giving the AI agent a secret that may provide far more access than the task actually requires.

Instead of asking:

"How do I give Cursor my server password?"

ask:

"How do I let Cursor perform this task with the minimum access required?"

That change in mindset is the foundation of secure AI-assisted development.

2. Use Environment Variables - But Understand Their Limitation

For local development and deployment scripts, environment variables are much better than hardcoding credentials into your application.

For example:

CPANEL_FTP_HOST=ftp.example.com
CPANEL_FTP_USER=my_deployment_user
CPANEL_FTP_PASS=your_password

Your deployment script can then read these values.

For example:

import os

host = os.getenv("CPANEL_FTP_HOST")
username = os.getenv("CPANEL_FTP_USER")
password = os.getenv("CPANEL_FTP_PASS")

And make sure .env is ignored by Git:

.env
.env.*
!.env.example

You can safely commit a template:

CPANEL_FTP_HOST=
CPANEL_FTP_USER=
CPANEL_FTP_PASS=

But here is the important part

.env protects your secrets from being committed to Git. It does not necessarily protect them from an AI coding agent.

If Cursor can read your project directory, it may be able to read .env too.

Therefore, don't think:

"It is in .env, so the AI cannot see it."

Instead think:

"The secret isn't in my source code or Git history, but I still need to control who and what can access the environment."

3. Prefer SSH Keys Over Password Authentication

For VPS access, SSH keys are generally preferable to passwords.

Generate an Ed25519 key:

ssh-keygen -t ed25519

You will typically have:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

The public key goes to the server.

The private key stays on your machine.

Never share the private key:

id_ed25519

The public key:

id_ed25519.pub

is the one intended to be installed on the server.

You can then connect using:

ssh deploy@your-server.com

This eliminates the need to paste a server password into an AI conversation.

But there is another important issue

An SSH key is only as safe as the account behind it.

If your key connects as:

root@production

you have potentially given the AI agent full control over the server.

That is not much better than giving it the root password.

4. Create a Dedicated Deployment User

Instead of giving an AI agent root access, create a dedicated user:

deploy

Give that user access only to what it needs.

For example:

/var/www/myapp

rather than the entire server.

Your architecture becomes:

AI Agent
   |
   v
SSH Key
   |
   v
deploy user
   |
   v
/var/www/myapp

Instead of:

AI Agent
   |
   v
root credentials
   |
   v
Entire VPS

This is the principle of least privilege.

If the deployment credential is compromised, the potential damage is limited.

5. For cPanel, Create a Dedicated Deployment Account

The same principle applies to cPanel.

Your main cPanel account may have access to:

Websites
Databases
Email
DNS
FTP
SSL
Cron jobs
Backups
File Manager

There is usually no reason for a deployment script to have access to everything.

Instead, create a dedicated FTP/SFTP account for the application.

For example:

Username:
myapp-deploy

Directory:
/public_html/my-app

Now the deployment credential is associated with the application rather than your entire hosting account.

If the credential is compromised, the attacker does not automatically get your entire cPanel account.

Where supported, prefer secure protocols such as SFTP or SSH over plain FTP.

6. Separate Development, Staging and Production Credentials

Don't use the same credentials everywhere.

Avoid:

Development -> Production credentials
Staging     -> Production credentials
Production  -> Production credentials

Instead:

Development
   |
   +-- Development credentials

Staging
   |
   +-- Staging credentials

Production
   |
   +-- Production credentials

This becomes especially important when working with AI agents.

Give your development environment access to test credentials whenever possible.

For example, if you are integrating a payment API, use sandbox credentials during development instead of your live production secret.

The same principle applies to:

Databases
Cloud accounts
SSH
Payment APIs
Email providers
Third-party APIs

7. Keep Production Secrets Out of the AI Agent Where Possible

For production deployments, a better architecture is to let the AI agent work on the code while your CI/CD system handles the production credentials.

For example:

Cursor
   |
   | git push
   v
GitHub
   |
   v
CI/CD
   |
   | Deployment secrets
   v
Production VPS

Your GitHub repository contains the code and deployment workflow, but not the actual production password.

Secrets can be stored in your CI/CD platform's secret store.

For example:

DEPLOY_HOST
DEPLOY_USER
DEPLOY_SSH_KEY

The workflow uses those values during deployment without putting them directly into the repository.

This creates a useful separation:

AI agent -> code

CI/CD -> production deployment

That is often safer than allowing the AI agent to directly administer production.

8. Give AI Agents the Minimum Access They Need

Before giving an AI agent access to anything, ask:

What does it need to do?

For example:

Deploy my application.

What does it need to access?

/var/www/myapp

What permissions does it need?

Read + write application files

How long does it need access?

Only during deployment

Then create credentials around those requirements.

Don't start with:

"Here is my root password. Figure it out."

Start with:

"This deployment user can only modify this application's directory."

9. Watch Your Terminal Output

Credentials can leak even when you don't explicitly paste them into a chat.

Avoid commands such as:

echo $CPANEL_PASSWORD

or:

env

if your environment contains secrets.

Also be careful with shell debugging such as:

set -x

because commands containing sensitive values may appear in terminal or CI/CD logs.

Your rule should be:

Secrets should not appear in source code, terminal output, application logs or CI/CD logs.

10. What If You Already Shared a Credential?

If you have already pasted a production password, API key or private key into an AI conversation, don't simply delete the message and assume the problem is solved.

Treat the credential as potentially exposed.

Rotate it.

A simple response procedure is:

1. Identify the exposed credential
2. Revoke it
3. Generate a replacement
4. Update the application or deployment system
5. Review authentication and server logs
6. Check for suspicious activity
7. Review how the credential was exposed

For an SSH key, generate a replacement key and remove the old public key from the server.

For an API key, revoke the old key and generate a new one.

For a password, change it.

Credential rotation is more important than simply deleting the leaked secret from the conversation or code.

A Practical Secure Setup

For a small VPS or SaaS project, you don't need a complicated enterprise security architecture.

A practical setup could look like this:

                  +----------------+
                  |  Cursor / AI   |
                  |     Agent      |
                  +-------+--------+
                          |
                          v
                  +----------------+
                  |  Source Code   |
                  +-------+--------+
                          |
                       Git Push
                          |
                          v
                  +----------------+
                  |    GitHub      |
                  +-------+--------+
                          |
                          v
                  +----------------+
                  | CI/CD + Secrets|
                  +-------+--------+
                          |
                     SSH / SFTP
                          |
                          v
                  +----------------+
                  | Deploy User    |
                  +-------+--------+
                          |
                          v
                  +----------------+
                  | Application    |
                  | Directory      |
                  +----------------+

The AI agent can help you write, test and prepare the application.

The deployment system handles the production credentials.

The deployment account has only the permissions required to deploy the application.

Security Checklist

Before giving an AI coding agent access to your infrastructure, check:

[ ] I am not pasting my master password into an AI chat.
[ ] Production secrets are not committed to Git.
[ ] .env is included in .gitignore.
[ ] I understand that .env can still be read by an agent with filesystem access.
[ ] I use SSH keys where practical.
[ ] Production uses a dedicated deployment user.
[ ] The deployment user does not have unnecessary root access.
[ ] cPanel credentials are scoped to the application.
[ ] Development, staging and production credentials are separate.
[ ] Production secrets are stored in CI/CD or a secret manager where appropriate.
[ ] Database users have only the permissions they need.
[ ] Secrets do not appear in terminal or CI/CD logs.
[ ] I can quickly revoke and rotate credentials.
[ ] Destructive production operations require appropriate human approval.

Final Thought

AI coding agents are becoming increasingly capable of interacting with real infrastructure.

The goal should not be to prevent them from doing useful work.

The goal is to limit the damage they can cause if something goes wrong.

Don't ask:

"How can I give Cursor my VPS password?"

Ask:

"How can I allow Cursor to perform this task without giving it unnecessary access to my infrastructure?"

Use environment variables to keep secrets out of source code, SSH keys instead of passwords where practical, dedicated deployment users instead of root, scoped cPanel accounts instead of master credentials, and CI/CD or secret managers for production secrets.

The safest credential is not simply the one that is hidden.

It is the one that has the least power necessary to get the job done.

A Beginner's Guide to Learning RPA: Where to Start and What to Learn

Sospeter Mong'are — Thu, 24 Sep 2026 11:43:38 +0000

Robotic Process Automation, commonly known as RPA, is an area of technology that focuses on using software robots to automate repetitive, rule-based tasks that people normally perform on computers.

If you have ever copied information from an email into Excel, downloaded files from a website, entered data into another system, or generated and sent the same report every day, you have probably encountered a process that could potentially be automated with RPA.

The good news is that you do not need to be an advanced programmer to start learning RPA.

You can begin with visual automation tools and gradually learn programming, APIs, databases, cloud services and AI as you become more advanced.

This guide explains a practical path for someone starting from zero.

What is RPA?

Imagine an employee receives an email containing an Excel file every morning.

They have to:

Open the email.
Download the Excel file.
Read the information.
Open another application.
Enter the information.
Save the changes.
Generate a report.
Send the report to their manager.

If these steps happen repeatedly and follow predictable rules, an RPA bot can potentially perform them automatically.

A simple RPA workflow could look like this:

Email received
      ↓
Download attachment
      ↓
Read Excel file
      ↓
Validate information
      ↓
Open business application
      ↓
Enter data
      ↓
Generate report
      ↓
Send email

The goal of RPA is not simply to replace people.

It is to automate repetitive work so that people can spend more time on tasks that require judgment, communication, creativity and decision-making.

What makes a good RPA process?

Not every process should be automated.

RPA works particularly well when a process is:

Repetitive
Rule-based
Predictable
High-volume
Time-consuming
Based on structured data
Performed using existing computer applications

For example:

Every morning, download a report from a website, process it, update an Excel spreadsheet and email the results.

This is a good candidate for RPA.

A process such as:

Decide whether a complex customer complaint deserves compensation.

may require human judgment and may not be suitable for traditional RPA alone.

Do I need to know programming?

No.

Many RPA platforms provide visual interfaces where you build workflows by dragging and configuring activities.

However, learning programming will give you a significant advantage as you become more advanced.

Useful programming skills include:

Python
JavaScript
SQL
REST APIs
JSON
Regular expressions

You do not need to master all of these before starting.

You can learn them gradually as your automation projects become more complex.

The main RPA tools to learn

There are many RPA platforms, but beginners do not need to learn all of them.

I recommend starting with two major tools:

1. Microsoft Power Automate

Power Automate is part of Microsoft's automation ecosystem.

It allows you to automate processes across services such as:

Outlook
Excel
SharePoint
Teams
OneDrive
SQL databases
HTTP APIs
Microsoft 365
Other third-party services

It also includes Power Automate Desktop, which allows you to automate tasks performed directly on a Windows computer.

For example:

Open browser
    ↓
Go to website
    ↓
Login
    ↓
Download report
    ↓
Open Excel
    ↓
Process data
    ↓
Save file

Power Automate is a good starting point, especially if you work in organizations that already use Microsoft 365 and Azure.

2. UiPath

UiPath is another major RPA platform.

It provides tools for building, deploying and managing software robots.

Important UiPath concepts include:

UiPath Studio
Activities
Variables
Arguments
Selectors
DataTables
Workflows
Exception handling
Logging
Queues
Orchestrator
Robots

UiPath is worth learning if you want to pursue RPA as a dedicated career path.

What should you learn first?

Do not try to learn everything at once.

A good learning path looks like this:

RPA Fundamentals
       ↓
Power Automate Desktop
       ↓
UiPath
       ↓
Web Automation
       ↓
Excel & Data Processing
       ↓
APIs
       ↓
SQL
       ↓
Python
       ↓
Enterprise RPA
       ↓
AI + RPA

Let's break this down.

Step 1: Learn RPA fundamentals

Before learning a specific tool, understand the basic concepts.

Learn:

What RPA is
What RPA is not
RPA use cases
Attended automation
Unattended automation
Rule-based processes
Process discovery
Workflow design
Exceptions
Logging
Monitoring

One important concept is process discovery.

Before building a bot, you should understand the process you are trying to automate.

For example:

What starts the process?
        ↓
What information is required?
        ↓
What applications are used?
        ↓
What decisions are made?
        ↓
What can go wrong?
        ↓
What should happen when something fails?

This is an important skill for an RPA developer.

Step 2: Learn Power Automate Desktop

Once you understand the basics, build simple desktop automations.

Start with:

Automation 1 - File management

Build a bot that:

Find files in a folder
       ↓
Read filenames
       ↓
Create folders
       ↓
Move files
       ↓
Generate a summary

Automation 2 - Excel

Build an automation that:

Open Excel
     ↓
Read data
     ↓
Filter records
     ↓
Calculate values
     ↓
Create a report

Automation 3 - Email

Build:

Check email
    ↓
Find messages matching a condition
    ↓
Download attachments
    ↓
Process attachment
    ↓
Send response

Automation 4 - Browser

Build:

Open browser
     ↓
Navigate to website
     ↓
Login
     ↓
Read information
     ↓
Save information

These simple projects will teach you many of the concepts used in real RPA work.

Step 3: Learn UiPath

Once you are comfortable with basic automation, start learning UiPath.

Focus on understanding:

Activities

Activities are the building blocks of UiPath workflows.

Examples include:

Open browser
Click
Type
Read text
Read Excel
Write Excel
Send email
Create file
Move file

Variables

Learn how to store information inside your automation.

For example:

customerName
invoiceNumber
amount
emailAddress

Conditions

Learn how to make the bot behave differently depending on the data.

IF amount > 100000
    send for approval
ELSE
    process automatically

Loops

Learn how to process multiple records.

For each customer
    Validate customer
    Update system
    Generate result

Selectors

Selectors are particularly important in UI automation.

They allow an RPA tool to identify elements on a webpage or application.

For example:

Username field
Password field
Login button
Submit button

Understanding selectors will help you build more reliable automations.

Step 4: Learn Excel and data processing

A lot of business automation involves data.

You should become comfortable with:

Excel
CSV
JSON
XML
DataTables
Basic data validation
Filtering
Sorting
Transformations

For example:

Excel
   ↓
Validate records
   ↓
Remove duplicates
   ↓
Transform data
   ↓
Send to API

You should also learn basic SQL.

At minimum, understand:

SELECT
WHERE
JOIN
GROUP BY
ORDER BY
INSERT
UPDATE

Step 5: Learn APIs

This is one of the most valuable skills you can add to RPA.

Modern automation does not always need to interact with a website through clicks.

If a system provides an API, you can often integrate with it directly.

Instead of:

RPA Bot
   ↓
Open browser
   ↓
Click login
   ↓
Click menu
   ↓
Click customer
   ↓
Enter information

you may be able to do:

RPA
 ↓
REST API
 ↓
Business System

Learn:

REST APIs
HTTP methods
GET
POST
PUT/PATCH
DELETE
Headers
Authentication
OAuth 2.0
API keys
JSON
Webhooks

This is where RPA starts connecting with traditional software engineering.

Step 6: Learn Python

Python is not mandatory for RPA, but it can make you much more capable.

You can use Python for:

Data processing
File manipulation
API integration
Complex business logic
Data transformation
Automation scripts
AI integration

Useful libraries include:

pandas
requests
openpyxl
Playwright
Selenium
PyAutoGUI

For web automation, Playwright is particularly useful to learn.

You can eventually build workflows such as:

RPA
 ↓
Python
 ↓
Process data
 ↓
REST API
 ↓
Database
 ↓
RPA
 ↓
Email notification

Step 7: Learn enterprise RPA

After learning the basics, start thinking about how automation works in real organizations.

This introduces concepts such as:

Attended automation

A user starts or interacts with the automation.

Example:

Employee
   ↓
Starts bot
   ↓
Bot processes task
   ↓
Employee continues

Unattended automation

The automation runs without someone sitting in front of the computer.

For example:

2:00 AM
   ↓
Robot starts
   ↓
Processes 5,000 records
   ↓
Generates report
   ↓
Sends notification

You should also learn:

Queues
Scheduling
Credentials
Secrets
Logging
Monitoring
Retry mechanisms
Exception handling
Audit trails
Deployment
Version control

These concepts become important when automations are running in production.

Step 8: Learn AI + RPA

This is an exciting area because AI can extend what traditional RPA can do.

Traditional RPA is generally good at structured, predictable tasks.

AI can help with less structured information.

For example, consider invoices.

A traditional RPA workflow might expect:

Invoice number = cell A1
Amount = cell B1
Date = cell C1

But invoices can have different layouts.

AI can help extract information from documents:

Invoice
   ↓
OCR / Document AI
   ↓
Extract information
   ↓
Validate
   ↓
RPA
   ↓
Update accounting system

You can eventually learn technologies such as:

OCR
Intelligent Document Processing
Azure AI Document Intelligence
Large Language Models
Structured AI output
AI agents
Human-in-the-loop workflows

This combination is often referred to as intelligent automation.

Build projects instead of only watching tutorials

One of the biggest mistakes beginners make is spending months watching tutorials without building anything.

After learning a concept, build something.

Here are some beginner projects.

Project 1 - Employee onboarding

Build:

New employee information
        ↓
Validate information
        ↓
Create folder
        ↓
Generate documents
        ↓
Send welcome email
        ↓
Notify HR

Project 2 - Invoice processing

Invoice arrives by email
        ↓
Download attachment
        ↓
Extract information
        ↓
Validate invoice
        ↓
Store information
        ↓
Send notification

Project 3 - Daily reporting

Scheduled automation
        ↓
Retrieve data
        ↓
Process data
        ↓
Generate Excel report
        ↓
Send email

Project 4 - Customer data synchronization

System A
    ↓
API
    ↓
Transform data
    ↓
System B
    ↓
Log result

Project 5 - AI document processing

Document
   ↓
AI extraction
   ↓
Validate information
   ↓
Human approval if necessary
   ↓
RPA/API
   ↓
Business system

RPA skills checklist

As you progress, you can use this checklist.

Beginner

[ ] Understand RPA
[ ] Identify automation opportunities
[ ] Understand workflows
[ ] Power Automate Desktop
[ ] Basic UiPath
[ ] Excel automation
[ ] File automation
[ ] Email automation
[ ] Browser automation
[ ] Conditions
[ ] Loops
[ ] Variables

Intermediate

[ ] UiPath selectors
[ ] Exception handling
[ ] Logging
[ ] Debugging
[ ] DataTables
[ ] SQL
[ ] REST APIs
[ ] JSON
[ ] OAuth
[ ] Python
[ ] Playwright
[ ] Power Automate Cloud

Advanced

[ ] UiPath Orchestrator
[ ] Queues
[ ] Unattended automation
[ ] Credentials and secrets
[ ] Monitoring
[ ] CI/CD
[ ] Version control
[ ] Enterprise architecture
[ ] Intelligent Document Processing
[ ] AI integration
[ ] AI agents
[ ] Human-in-the-loop automation

Do you need to learn everything?

No.

You don't need to become an expert in UiPath, Power Automate, Python, APIs, SQL and AI before building your first bot.

Start small.

A practical progression is:

Learn RPA concepts
       ↓
Build a simple desktop automation
       ↓
Automate Excel
       ↓
Automate email
       ↓
Automate a website
       ↓
Learn APIs
       ↓
Learn SQL
       ↓
Learn Python
       ↓
Build enterprise workflows
       ↓
Add AI

The most valuable skill is not knowing how to click around an RPA platform.

It is learning how to look at a business process and answer:

"What part of this process can be automated, how should it be automated, and how can I make the automation reliable?"

Once you develop that ability, learning another RPA platform becomes much easier.

Final thoughts

RPA sits at an interesting intersection between software engineering, business processes and automation.

You can start without being a programmer, but programming, APIs, databases and cloud technologies can significantly expand what you are able to build.

A strong long-term skill set could look like:

                Automation Engineer
                        |
        +---------------+---------------+
        |               |               |
       RPA             APIs            AI
        |               |               |
   UiPath / PA      REST / OAuth      LLMs
        |               |               |
   Desktop/Web       Python/SQL      Agents
        |               |               |
        +---------------+---------------+
                        |
                 Business Automation

If you are starting today, don't try to learn ten tools simultaneously.

Start with Power Automate Desktop or UiPath, build a few real automations, then add APIs, SQL and Python. Once you understand those foundations, explore AI-powered automation.

That progression can take you from building simple bots to designing complete business automation solutions.

Understanding Retrieval-Augmented Generation (RAG)

Sospeter Mong'are — Fri, 18 Sep 2026 15:40:46 +0000

Introduction

Large Language Models (LLMs) have changed how we interact with software. They can answer questions, summarize documents, generate code, analyze information, and perform many other tasks using natural language.

However, LLMs have an important limitation: they do not automatically know everything about your organization, your internal documents, or information that has changed since their training.

This is where Retrieval-Augmented Generation (RAG) comes in.

RAG is an AI architecture that allows an LLM to retrieve relevant information from an external knowledge source before generating a response. Instead of relying entirely on what the model learned during training, the system first searches a collection of trusted information, retrieves relevant content, and provides that content to the LLM as context.

A simple way to think about RAG is an open-book exam.

Instead of asking the AI to answer a question entirely from memory, you give it access to the relevant documents first. The AI searches those documents, finds the information it needs, and then uses that information to formulate an answer.

For example, imagine an employee asks:

"What is our company's Q3 remote work policy?"

A general-purpose LLM may not know the company's internal policy. With RAG, the system can search the organization's policy documents, retrieve the relevant section, provide it to the LLM, and generate an answer based on that information.

This makes RAG particularly useful for organizations working with proprietary, domain-specific, or frequently changing information.

The Two Major Pipelines of RAG

A complete RAG system can be thought of as having two major pipelines:

The Data Preparation Pipeline, also called ingestion
The Runtime Pipeline, which happens when a user asks a question

Understanding this distinction is important because RAG does not simply mean "put documents into an AI model."

There is significant work that happens before the user ever asks a question.

1. The Data Preparation Pipeline

The first step is preparing your data so that an AI system can efficiently search and retrieve relevant information.

Your source data could come from:

PDF documents
Word documents
Internal company wikis
Websites
Databases
SharePoint
Emails
Knowledge bases
API responses
Internal documentation

The general process looks like this:

Documents -> Chunking -> Embeddings -> Vector Database

Chunking

Large documents are usually too big to retrieve as a single piece.

Imagine having a 200-page employee handbook. If someone asks about the company's leave policy, you don't want to retrieve the entire 200-page document.

Instead, the document is divided into smaller pieces called chunks.

A chunk might contain:

A paragraph
Several paragraphs
A section
A group of related sentences

For example:

Employee Handbook
        |
        v
+-------------------+
| Chunk 1           |
| Introduction      |
+-------------------+
| Chunk 2           |
| Leave Policy      |
+-------------------+
| Chunk 3           |
| Remote Work       |
+-------------------+
| Chunk 4           |
| Benefits          |
+-------------------+

The goal is to create chunks that contain enough information to be useful while remaining small enough for efficient retrieval.

Chunking is more important than it might initially appear. Poorly chosen chunks can result in the system retrieving incomplete or irrelevant information, which can ultimately affect the quality of the generated answer.

Embedding

Once the documents have been divided into chunks, each chunk is passed through an embedding model.

An embedding model converts text into a numerical representation called a vector embedding.

For example, a sentence such as:

"Employees can work remotely three days per week."

is converted into a mathematical representation containing many numbers.

The important idea is that the vector represents the semantic meaning of the text.

This allows a system to identify relationships between concepts rather than simply matching exact words.

For example, a user might ask:

"How many days can I work from home?"

The document might contain:

"Employees can work remotely three days per week."

Even though the wording is different, the system can recognize that the two pieces of text are semantically related.

Storing the Embeddings

The generated embeddings are stored in a vector database.

Examples include:

ChromaDB
Pinecone
Weaviate
pgvector
Qdrant
Milvus

The vector database acts as a searchable index for the knowledge base.

A simplified representation might look like:

Document Chunk
      |
      v
Embedding Model
      |
      v
Vector
[0.021, -0.183, 0.492, ...]
      |
      v
Vector Database

The database can then perform similarity searches to identify which pieces of information are most relevant to a user's question.

2. The Runtime Pipeline

The second part of RAG happens when a user actually interacts with the application.

This is the part most people associate with RAG.

The basic process is:

User Query
     |
     v
Retrieval
     |
     v
Retrieved Context
     |
     v
Augmentation
     |
     v
LLM
     |
     v
Generated Answer

There are three core stages:

Retrieval
Augmentation
Generation

Step 1: Retrieval

The user submits a question.

For example:

"What is our company's Q3 remote work policy?"

The system converts the question into an embedding using the same or a compatible embedding model used during ingestion.

It then searches the vector database for chunks that are semantically similar to the query.

The vector database might return something like:

Chunk 1:
"Employees are required to work from the office..."

Chunk 2:
"Employees may work remotely up to three days per week..."

Chunk 3:
"Remote employees must remain available during..."

The system selects the most relevant chunks to provide as context to the LLM.

This is the retrieval part of Retrieval-Augmented Generation.

Step 2: Augmentation

The retrieved information is then combined with the user's original question.

The application typically uses a prompt template to tell the LLM how to use the retrieved information.

Conceptually, it could look like:

Use the following information to answer the user's question.

Context:
Employees may work remotely up to three days per week.
Remote employees must remain available during
normal working hours.

Question:
What is our company's Q3 remote work policy?

The LLM now has access to information that was retrieved specifically for the user's question.

This is the augmentation part of RAG.

Step 3: Generation

The augmented prompt is sent to the LLM.

The model uses the retrieved context, together with its language understanding and reasoning capabilities, to generate the final response.

For example:

"According to the company's policy, employees may work remotely up to three days per week while remaining available during normal working hours."

This is the generation part of RAG.

Putting everything together:

                   DATA PREPARATION
                   -----------------

Documents
    |
    v
Chunking
    |
    v
Embedding Model
    |
    v
Vector Database
    |
    |
    |                    RUNTIME
    |                    -------
    |                       |
    |                  User Question
    |                       |
    |                       v
    +-------------->  Query Embedding
                            |
                            v
                     Similarity Search
                            |
                            v
                    Relevant Chunks
                            |
                            v
                       Prompt + Context
                            |
                            v
                           LLM
                            |
                            v
                     Generated Answer

Why Organizations Use RAG

RAG is particularly useful for organizations that need AI systems to work with their own data.

1. Grounding AI Responses

LLMs can sometimes generate information that sounds convincing but is incorrect. This is commonly referred to as hallucination.

RAG can reduce this problem by providing the model with relevant source information before it generates an answer.

However, RAG does not magically eliminate hallucinations.

If the retrieval system returns irrelevant information, incomplete information, or outdated information, the LLM can still produce a poor answer.

This is why the quality of the retrieval system is just as important as the LLM itself.

2. Easier Knowledge Updates

Suppose a company changes its leave policy.

With a traditional approach, you might consider retraining or fine-tuning a model to incorporate the new information.

With RAG, you can update the underlying knowledge base.

The new document can be processed, chunked, embedded, and added to the vector database.

The LLM itself does not need to be retrained simply because the organization's documentation changed.

This makes RAG particularly useful for information that changes frequently.

3. Working With Private Data

Organizations have large amounts of internal information that general-purpose AI models were not trained on.

This could include:

Internal policies
Product documentation
Customer support information
Financial reports
Technical documentation
Employee handbooks
Business processes
Internal knowledge bases

RAG provides a way to build an AI interface over this information while keeping the organization's knowledge source separate from the underlying LLM.

Of course, privacy and security still need to be designed carefully. Access controls, authentication, authorization, data isolation, logging, and appropriate handling of sensitive information remain important.

4. Cost and Maintenance

Continuously retraining a large language model whenever an organization's information changes is generally impractical.

RAG separates the knowledge layer from the language model.

The LLM handles language understanding and generation, while the retrieval system provides the relevant organizational knowledge.

This separation makes it easier to maintain and update the knowledge source independently.

RAG Is More Than a Vector Database

One common misconception is that building a RAG system simply means:

"Put documents into a vector database and connect it to an LLM."

In practice, there are several components involved.

A production RAG system may include:

Document ingestion
Text extraction
Chunking
Embedding models
Vector databases
Metadata filtering
Keyword search
Semantic search
Hybrid search
Reranking
Prompt engineering
LLMs
Access control
Observability
Evaluation
Caching
Data freshness mechanisms

This means RAG is better understood as an architecture rather than a single technology.

The Importance of Retrieval Quality

One of the most important lessons when building RAG systems is:

A better LLM cannot always compensate for poor retrieval.

Imagine a user asks:

"What is the company's maternity leave policy?"

But the retrieval system returns documents about annual leave.

The LLM now has the wrong context.

Even if the LLM is extremely capable, it may generate an answer based on irrelevant information.

A simplified way to think about the process is:

Good Retrieval
      +
Relevant Context
      +
Good LLM
      =
Useful Answer

But:

Poor Retrieval
      +
Wrong Context
      +
Good LLM
      =
Potentially Wrong Answer

This is why RAG evaluation needs to look beyond the final response. You also need to evaluate whether the system retrieved the right information in the first place.

RAG and Traditional LLM Applications

A standard LLM application might look like:

User
  |
  v
LLM
  |
  v
Response

The model relies primarily on the information encoded in its parameters during training, plus whatever information is included in the current conversation or prompt.

A RAG application adds an external knowledge layer:

                  +----------------+
                  | Knowledge Base |
                  +-------+--------+
                          |
                          v
User -> Retrieval -> Context -> LLM -> Response

This architectural difference is what makes RAG useful for organization-specific knowledge.

A Practical Example

Consider a healthcare organization with thousands of documents.

An employee asks:

"What is the process for approving a medical claim?"

Without RAG, the LLM may have general knowledge about medical claims, but it does not necessarily know the organization's specific process.

With RAG:

User Question
     |
     v
Search Knowledge Base
     |
     v
Retrieve Claims Procedure
     |
     v
Add Procedure to Prompt
     |
     v
LLM
     |
     v
Answer Based on Retrieved Procedure

The same architecture can be applied to many other domains:

Banking
Insurance
Healthcare
Education
Legal documentation
Customer support
Enterprise IT
Human resources
Government services

Anywhere an organization has a large collection of documents or structured knowledge, RAG can potentially provide a useful interface for accessing that information.

Conclusion

Retrieval-Augmented Generation is one of the most practical architectures for connecting LLMs to external knowledge.

The fundamental idea is simple:

Retrieve relevant information first, then let the LLM generate an answer using that information.

A RAG system generally consists of two major phases.

During data preparation, documents are collected, chunked, converted into embeddings, and stored in a searchable knowledge store.

During runtime, a user's question is converted into a searchable representation, relevant information is retrieved, that information is added to the prompt, and the LLM generates the final response.

The important thing to remember is that RAG is not just about the LLM. The quality of the entire pipeline matters - from how documents are processed and chunked, to how information is retrieved, filtered, ranked, and finally presented to the model.

As organizations look for practical ways to use AI with their own data, understanding RAG provides an important foundation for building AI applications that are connected to real, domain-specific knowledge rather than relying solely on what a model learned during training.

What is Grok Bot? The Complete Beginner's Guide and Use Cases

Sospeter Mong'are — Fri, 18 Sep 2026 06:57:56 +0000

Imagine having a personal assistant who doesn't just type out answers, but actually sits down at a computer, opens a web browser, fills out forms, and organizes files for you. That is exactly what Grok Bot does.

As artificial intelligence evolves, we are moving away from simple chatbots and entering the era of AI "agents"—programs that can actively execute multi-step tasks. In this guide, we will break down what Grok Bot is, how it works, and how you can use it to automate your daily digital chores.

What is Grok Bot?

At its core, Grok Bot is an autonomous AI assistant designed to interact with a computer just like a human would. Unlike traditional AI that only generates text or code, Grok Bot is equipped with a dedicated, persistent Linux virtual machine in the cloud.

This cloud computer gives the bot its own:

Web Browser: To navigate websites, click buttons, and log into portals.
File Manager: To download, organize, and edit documents or spreadsheets.
Terminal: To run commands and execute lightweight scripts.

Because it operates on an independent cloud machine, it is always on. You can give Grok Bot a complex assignment, close your laptop, walk away, and it will keep working in the background until the job is done.

Top Use Cases for Grok Bot

Because Grok Bot can use the internet and manage files, its practical applications are almost limitless. Here are the most common ways people use it:

1. Automating Boring Workflows

We all have repetitive digital tasks that eat up our time. Grok Bot can take over these chores entirely. For example, it can log into your company’s vendor portal every Friday, download invoice data, and manually type that information into an accounting spreadsheet. It is perfect for moving data between two software platforms that do not easily talk to each other.

2. Deep Web Research and Monitoring

Instead of spending hours searching the web, you can deploy Grok Bot to do the heavy lifting. It can scan competitor websites to track pricing changes, gather contact details from public directories to build lead lists, or monitor retail sites for hard-to-find inventory, instantly alerting you when an item comes back in stock.

3. File and Data Management

If you deal with large volumes of data, Grok Bot can act as your digital organizer. It can look through a folder containing thousands of downloaded files, rename them based on specific rules, convert them from PDFs to text files, and filter out duplicate entries using its built-in terminal tools.

4. Software and QA Testing

For developers and businesses, Grok Bot can act as a real user. You can instruct it to visit your newly built website, click through the checkout process, and report back if any links are broken or if the system crashes.

What Else Should Beginners Know?

Before you dive in, there are a few essential things to keep in mind to get the most out of your AI assistant:

A Shared Environment: If you build or deploy multiple bots under your account, they all share access to the same single cloud machine, file system, and browser sessions. This makes it easy for different bots to collaborate on the same set of files.
Security and Credentials: Because Grok Bot needs to log into websites to do its job, you will need to manage security credentials. Always practice safe data habits by using secure credential managers or dedicated account permissions for your bot.
Beginner-Friendly Controls: You don't need to be a computer programmer to use Grok Bot. You can guide it using plain, natural language instructions, and it will translate your goals into clicks, typing, and commands.

Conclusion

Grok Bot represents a massive leap forward in personal productivity. By pairing advanced artificial intelligence with a fully functional cloud computer, it transforms from a simple conversation partner into a capable digital worker. Whether you are trying to escape repetitive data entry, track market trends, or manage messy file directories, Grok Bot can handle the heavy lifting—leaving you free to focus on the work that actually matters.

How to deploy a Laravel app to a VPS

Sospeter Mong'are — Wed, 16 Sep 2026 18:57:04 +0000

This is a beginner guide for a Laravel app where the pages and the API live in the same project. Blade is the frontend. Laravel routes under /api are the backend. There is no separate Node server.

Replace YOUR_SERVER_IP, YOUR_DOMAIN, YOUR_APP, and STRONG_PASSWORD with your own values. Do not copy a real password, APP_KEY, or a private key into a chat, a screenshot, or git.

Introduction

A VPS is a Linux computer in a data center. Visitors type a domain. An A record points that domain at the server's IP. Nginx receives HTTPS and hands every URL to PHP.

One Laravel app answers both kinds of request. They share public/index.php, the same .env, and the same MySQL database.

Request	Who answers	Why
`https://YOUR_DOMAIN/` and `/login`	Laravel `routes/web.php`	Blade pages
`https://YOUR_DOMAIN/api/...`	Laravel `routes/api.php`	The API in the same app
MySQL	`127.0.0.1:3306` only	Laravel's own database. It is not on the public internet

There is no second port to open. PHP-FPM is a local socket, not a public port. Nginx is the only door.

GitHub Actions cannot upload code until the server already has a folder, a database, .env, Nginx, and an SSH key. Actions logs in as deploy, not as your sudo account. A leaked GitHub key can update the app, but it cannot install packages or change the firewall.

Two accounts, two jobs:

User	Job
`YOUR_SUDO_USER`	The account you SSH in as. It has `sudo`. On the Contabo server used for MtandaoBilling this account is `sos`. A lot of VPS images do not give you a root password.
`deploy`	Owns `/var/www/YOUR_DOMAIN`, runs Composer and Artisan, and is the GitHub Actions login. It has no password.

PHP itself runs as www-data. That user must be able to write storage/ and bootstrap/cache even though deploy owns the files.

1. Log in, and do not SSH as deploy yet

From your PC:

ssh YOUR_SUDO_USER@YOUR_SERVER_IP

You are on the server. The prompt looks like YOUR_SUDO_USER@your-server:~$.

Do not run ssh deploy@YOUR_SERVER_IP from that prompt. deploy has no password and, at this point, no SSH key. The server answers Permission denied (publickey). You are already on the machine. Switch user instead:

sudo -u deploy -i

sudo means "run this as another user." -u deploy -i opens a login shell as deploy. Type exit to go back to your sudo account.

apt, Nginx, and MySQL stay on the sudo account. Files inside the app folder are edited as deploy, after that user owns the folder.

2. Install what Laravel needs

You do not need PM2. PHP-FPM already stays running. You do need Node once, on the machine that builds CSS and JavaScript. On the server, Composer installs PHP packages. Vite assets are usually built in GitHub Actions and uploaded, so the server does not have to run npm if that build already happened.

Package	Why
`nginx`	Receives HTTPS and sends PHP files to PHP-FPM
`php8.3-fpm` and PHP extensions	Runs Blade pages and the `/api` routes. `fpm` is the PHP process Nginx talks to
`composer`	Installs Laravel's PHP libraries
`mysql-server`	Laravel's database
`certbot`	Gets a free HTTPS certificate from Let's Encrypt
`acl`	Lets `www-data` write logs and sessions in a folder owned by `deploy`
`ufw`	Firewall. Only SSH, HTTP, and HTTPS should be open

As YOUR_SUDO_USER:

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx mysql-server certbot python3-certbot-nginx \
  git curl unzip ufw acl \
  php8.3-fpm php8.3-cli php8.3-mysql php8.3-mbstring php8.3-xml \
  php8.3-curl php8.3-zip php8.3-bcmath php8.3-tokenizer

curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

If php8.3-* is not in your Ubuntu version, install PHP 8.2 or newer and later point Nginx at that socket (ls /run/php/).

Check that the commands exist:

php -v
composer -V
nginx -v
mysql --version

Create deploy once, if it does not exist. --disabled-password is deliberate. GitHub will log in with a key, not a password that can be guessed.

sudo adduser --disabled-password --gecos "" deploy

Open only SSH and the web ports. Do not open MySQL port 3306.

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

OpenSSH keeps your current login alive. Nginx Full is ports 80 and 443.

3. Make the app folder, and make deploy the owner

Nginx will not use this folder as the website root. It uses public/ inside it. The rest of Laravel (.env, app/, vendor/) must stay outside the web root so visitors cannot download it.

sudo mkdir -p /var/www/YOUR_DOMAIN
sudo chown -R deploy:deploy /var/www/YOUR_DOMAIN

chown means "this user owns these files."

A folder created earlier as root stays owned by root. mkdir -p as deploy does not change a folder that already exists, and nano then fails with Permission denied. Check with:

ls -ld /var/www/YOUR_DOMAIN

The owner must be deploy deploy. If it says root root:

sudo chown -R deploy:deploy /var/www/YOUR_DOMAIN

4. Create the MySQL database

The Linux user deploy is not the database user. Create a separate MySQL user. In MySQL, localhost and 127.0.0.1 are two different accounts.

localhost means "connect through a Unix socket." 127.0.0.1 means "connect with TCP." If .env says DB_HOST=127.0.0.1, a user created only @localhost is invisible. ALTER USER for the TCP account then fails with ERROR 1396 because that account does not exist yet.

PHP's MySQL driver can use MySQL 8's normal caching_sha2_password plugin. You do not need mysql_native_password unless this same database is also used by Prisma. This guide uses the normal plugin.

As YOUR_SUDO_USER:

sudo mysql

sudo mysql works without a MySQL root password because Ubuntu lets the system admin in through the socket. Invent a long password. Call it STRONG_PASSWORD here. Use the same string later in .env. Do not reuse a password from a chat log.

CREATE DATABASE your_app CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'your_app_user'@'127.0.0.1' IDENTIFIED BY 'STRONG_PASSWORD';
GRANT ALL PRIVILEGES ON your_app.* TO 'your_app_user'@'127.0.0.1';
FLUSH PRIVILEGES;
SELECT user, host FROM mysql.user WHERE user = 'your_app_user';

The host column must include 127.0.0.1. Then type exit.

5. Write `.env` on the server only

There is one .env, at the Laravel project root, not a separate frontend file. GitHub must not upload it.

As deploy:

nano /var/www/YOUR_DOMAIN/.env

Start from your project's .env.example and set at least these. Leave APP_KEY empty. Artisan fills it after Composer has run.

APP_NAME=YOUR_APP
APP_ENV=production
APP_KEY=
APP_DEBUG=false
APP_URL=https://YOUR_DOMAIN

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=your_app
DB_USERNAME=your_app_user
DB_PASSWORD=STRONG_PASSWORD

SESSION_DRIVER=database
CACHE_STORE=database
QUEUE_CONNECTION=database

APP_DEBUG=false so a crash does not print secrets in the browser. The real error still goes to storage/logs/laravel.log.

SESSION_DRIVER=database is fine for a Laravel app that owns MySQL, but only after php artisan migrate has created the sessions table. If you want the first page to work before that migrate, set SESSION_DRIVER=file and CACHE_STORE=file instead. A 500 that says no such table: sessions means the driver is database and migrate has not run.

As the sudo user, lock the file:

sudo chown deploy:deploy /var/www/YOUR_DOMAIN/.env
sudo chmod 600 /var/www/YOUR_DOMAIN/.env

600 means owner read/write, everyone else nothing.

6. Install Nginx and the free certificate

The website root is public/, not the project root. If you point Nginx at /var/www/YOUR_DOMAIN, visitors can request .env.

As YOUR_SUDO_USER:

sudo nano /etc/nginx/sites-available/YOUR_DOMAIN

Paste this. Read the comments. They are the reason each line exists.

server {
    listen 80;
    listen [::]:80;
    server_name YOUR_DOMAIN;

    # Only public/ is on the internet. app/, .env, and vendor/ are not.
    root /var/www/YOUR_DOMAIN/public;
    index index.php;

    access_log /var/log/nginx/YOUR_APP.access.log;
    error_log  /var/log/nginx/YOUR_APP.error.log;

    charset utf-8;
    client_max_body_size 20m;

    # Real files (CSS, images, Vite /build) are sent as files.
    # Every other URL, including /api/..., goes to public/index.php.
    # Laravel then chooses web.php or api.php. Nginx does not split them.
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    error_page 404 /index.php;

    # PHP-FPM socket. If this file does not exist, run: ls /run/php/
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param HTTPS $https if_not_empty;
    }

    # Block .env and .git if they ever land inside public/.
    # /.well-known/ stays open so Certbot can prove you own the domain.
    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Enable the site and test it before you reload. nginx -t stops a typo from taking every site on the server down.

sudo ln -s /etc/nginx/sites-available/YOUR_DOMAIN /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

A 404 or a PHP error now is normal. The app is not uploaded yet.

Then ask Let's Encrypt for a certificate. Certbot is free. The prompt "agree to register with the ACME server" is their terms, not a paid account. Type yes, and enter an email so they can warn you before a certificate expires.

sudo certbot --nginx -d YOUR_DOMAIN

Certbot edits the Nginx file on the server. It adds port 443 and redirects HTTP to HTTPS. Do not copy those certificate paths into git.

7. Give GitHub a key that can log in as deploy

A password in GitHub is worse than a key you can delete. The key has two halves:

File	Where it goes
`YOUR_APP_deploy.pub`	The server. This is public. It says "this key is allowed."
`YOUR_APP_deploy`	Your PC, then the GitHub secret. This is private. Never commit it, and never paste it into a chat.

On your PC, not inside the SSH session:

ssh-keygen -t ed25519 -C "github-actions-YOUR_APP" -f ~/.ssh/YOUR_APP_deploy -N ""
scp ~/.ssh/YOUR_APP_deploy.pub YOUR_SUDO_USER@YOUR_SERVER_IP:~/

In PowerShell, if ~ is not your user folder, use the full path, for example C:\Users\ADMIN\.ssh\YOUR_APP_deploy.pub.

On the VPS, as YOUR_SUDO_USER:

sudo mkdir -p /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys < ~/YOUR_APP_deploy.pub
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

authorized_keys is the list of public keys allowed to log in as that user. 700 and 600 are not optional. SSH ignores a key file if other users can read it.

Test from your PC. You should land in /home/deploy with no password:

ssh -i ~/.ssh/YOUR_APP_deploy deploy@YOUR_SERVER_IP

8. Add the GitHub secrets

In the repository: Settings, then Secrets and variables, then Actions, then New repository secret.

Secret	Value
`SSH_HOST`	`YOUR_SERVER_IP`
`SSH_USERNAME`	`deploy`
`SSH_PRIVATE_KEY`	The whole private file, including the `BEGIN` and `END` lines
`SSH_PORT`	`22`
`DEPLOY_PATH`	`/var/www/YOUR_DOMAIN`

Show the private key on your PC only, then paste it into GitHub. Use the file without .pub.

cat ~/.ssh/YOUR_APP_deploy

A small workflow you can put in .github/workflows/deploy.yml of that Laravel project. It builds the Vite files in GitHub, uploads the app, and does not upload .env or node_modules.

name: Deploy Laravel

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"
          tools: composer:v2

      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: PHP dependencies and Vite build
        run: |
          composer install --no-interaction --prefer-dist --optimize-autoloader --no-dev
          npm ci
          npm run build

      - name: Upload
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT || 22 }}
          source: ".,!node_modules,!.env"
          target: ${{ secrets.DEPLOY_PATH }}
          overwrite: true

      - name: Migrate and refresh caches
        uses: appleboy/ssh-action@v1.2.0
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT || 22 }}
          script: |
            cd "${{ secrets.DEPLOY_PATH }}"
            composer install --no-dev --optimize-autoloader --no-interaction
            php artisan storage:link || true
            php artisan migrate --force
            php artisan config:cache
            php artisan route:cache
            php artisan view:cache
            sudo systemctl reload php8.3-fpm

deploy cannot run sudo systemctl reload unless you allow that one command. If the reload line fails, SSH in as YOUR_SUDO_USER and run sudo systemctl reload php8.3-fpm yourself after the first deploy. PHP keeps the old cached config until that reload.

public/build must be in the upload. If GitHub skips npm run build, Laravel pages that use @vite return 500 with "Vite manifest not found."

9. First boot on the server

After the first upload, as deploy:

cd /var/www/YOUR_DOMAIN
composer install --no-dev --optimize-autoloader --no-interaction
php artisan key:generate --force
php artisan migrate --force
php artisan storage:link
php artisan config:cache
php artisan route:cache
php artisan view:cache

key:generate writes APP_KEY. Without it, every page is 500. Do not run it again on later deploys. A new key logs everybody out and can make old encrypted cookies unreadable.

migrate --force creates tables, including sessions if you use the database session driver. --force is required because Laravel refuses to migrate when APP_ENV=production unless you say so.

storage:link makes public/storage point at uploaded files. Skip the error if the link already exists.

config:cache bakes .env into one PHP file. After this, editing .env does nothing until you run config:cache again.

PHP must be able to write logs and sessions. As YOUR_SUDO_USER:

sudo mkdir -p /var/www/YOUR_DOMAIN/storage/framework/{cache/data,sessions,views} \
  /var/www/YOUR_DOMAIN/storage/logs \
  /var/www/YOUR_DOMAIN/bootstrap/cache
sudo chown -R deploy:www-data /var/www/YOUR_DOMAIN/storage /var/www/YOUR_DOMAIN/bootstrap/cache
sudo chmod -R ug+rwX /var/www/YOUR_DOMAIN/storage /var/www/YOUR_DOMAIN/bootstrap/cache
sudo systemctl reload php8.3-fpm

www-data is the PHP user. The group write bit is what lets PHP save sessions and log a 500 instead of dying with Permission denied.

10. Confirm the site

Open https://YOUR_DOMAIN/ and one API URL, for example https://YOUR_DOMAIN/api/user or whatever your routes/api.php exposes. A 401 on a protected API route is fine. It means Laravel answered. A 404 from Nginx, with no Laravel styling, means the request never reached index.php.

If the page is 500:

sudo grep "production.ERROR" /var/www/YOUR_DOMAIN/storage/logs/laravel.log | tail -1

The first production.ERROR line is the cause. The long stack under it is not.

What the log says	What to do
`No application encryption key`	`php artisan key:generate --force`, then `config:cache`, then reload PHP-FPM
`no such table: sessions`	`php artisan migrate --force`, or set `SESSION_DRIVER=file` and cache config again
`Permission denied` under `storage/`	Repeat the `chown` and `chmod` in step 9
`Vite manifest not found`	`npm run build` in GitHub (or on the server) so `public/build/manifest.json` exists
`Access denied for user`	`DB_USERNAME`, `DB_PASSWORD`, and `DB_HOST=127.0.0.1` must match the MySQL user from step 4

After any .env change:

cd /var/www/YOUR_DOMAIN
php artisan config:cache

Then as the sudo user: sudo systemctl reload php8.3-fpm.

Conclusion

Prepare the server before GitHub deploys. The order is: PHP, Composer, Nginx, and MySQL, a deploy user, a folder that user owns, a MySQL user at 127.0.0.1, one .env, Certbot, an SSH key, then a push.

Blade pages and /api are the same app. Nginx sends both to public/index.php. You do not run a second process and you do not open an API port.

When it fails, look here first:

storage/logs/laravel.log for a 500 page. Read the production.ERROR line.
Confirm Nginx root is .../public, not the project root.
Confirm DB_HOST is 127.0.0.1 and that SELECT user, host FROM mysql.user shows that host.
After an .env edit, php artisan config:cache and reload PHP-FPM.

Do not put the database password, APP_KEY, or the private key in git. deploy is the only account GitHub should log in as.

How to Point a Subdomain to Your Contabo VPS

Sospeter Mong'are — Mon, 14 Sep 2026 19:33:31 +0000

If you have a domain hosted with one provider but your application or website is running on a VPS from another provider, you don't need to move the entire domain.

You can simply create a subdomain and point it to your VPS.

For example, suppose your main domain is:

mydomain.com

And you have a Contabo VPS where you want to host an application at:

mysubdomain.mydomain.com

In this setup:

Your main domain remains with your existing DNS provider, such as Truehost.
Your application runs on the Contabo VPS.
The subdomain points directly to the VPS IP address.
Your DNS provider tells browsers where to find that subdomain.

This guide walks through the process step by step.

What You Need Before Starting

You will need:

A registered domain, for example mydomain.com
Access to the domain's DNS management panel
A Contabo VPS
The public IPv4 address of your VPS
Access to the server so you can configure your web server

In this example, we'll use:

Domain: mydomain.com
Subdomain: mysubdomain.mydomain.com
VPS Provider: Contabo
DNS Provider: Truehost

How DNS Works in This Setup

Before changing anything, it helps to understand what is actually happening.

When someone enters:

https://mysubdomain.mydomain.com

their browser needs to know which server should receive the request.

The DNS record provides that information.

You will essentially tell DNS:

mysubdomain.mydomain.com
        ↓
Contabo VPS IP address
        ↓
Your application

This is done using an A record.

An A record maps a domain or subdomain to an IPv4 address.

For more background, see cPanel's explanation of pointing a subdomain to another server.

Step 1: Find Your Contabo VPS IP Address

First, you need to find the public IP address of your Contabo VPS.

You should see an IPv4 address similar to:

123.123.123.123

Copy this IP address.

You will need it when creating the DNS record.

Why do you need the IP address?

DNS needs to know where to send requests for your subdomain.

For example:

mysubdomain.mydomain.com
              ↓
       123.123.123.123

The IP address is therefore the destination for your subdomain.

Step 2: Open Your DNS Zone Editor

If your domain is managed through Truehost, log in to your Truehost cPanel.

From the cPanel dashboard, look for the Domains section.

Select:

Zone Editor

The Zone Editor allows you to manage DNS records for your domain.

You can also refer to Truehost's guide on subdomains and domain configuration.

You should see your domain listed, for example:

mydomain.com

Select the option to manage its DNS records.

Step 3: Create an A Record

This is the most important step.

An A record tells DNS:

When someone requests this hostname, send them to this IPv4 address.

Next to mydomain.com, select:

+ A Record

You will typically see fields similar to:

Name:
Address / Value:

Enter your values.

Name

You can enter:

mysubdomain

Depending on your DNS provider, you may also be able to enter the complete hostname:

mysubdomain.mydomain.com

Address / Value

Enter the IPv4 address of your Contabo VPS.

For example:

123.123.123.123

Your record will effectively look like:

Type:     A
Name:     mysubdomain
Value:    123.123.123.123

Then save the record.

For additional background on creating A records, see HostPapa's guide to pointing a subdomain to an IP address.

Step 4: Configure Your Contabo VPS

Adding the DNS record is only half of the process.

Your VPS also needs to know what to do when a request arrives for:

mysubdomain.mydomain.com

For example, if you're using Nginx, you need to configure a server block for the subdomain.

A simplified configuration could look like:

server {
    listen 80;
    server_name mysubdomain.mydomain.com;

    root /var/www/mysubdomain;
    index index.html;
}

If you're using Apache, CyberPanel, or another server management solution, the configuration will be different.

The important thing is that your VPS must be configured to recognize the hostname.

Think of it this way:

DNS
 |
 | mysubdomain.mydomain.com
 ↓
Contabo VPS
 |
 | "I know this domain"
 ↓
Web server
 |
 ↓
Your application

If DNS is configured correctly but your web server doesn't recognize the domain, the request can still fail.

Step 5: Test the DNS Configuration

After saving the A record, you can check whether the DNS record is resolving correctly.

From your computer, you can use:

nslookup mysubdomain.mydomain.com

Or:

dig mysubdomain.mydomain.com

You should eventually see your Contabo VPS IP address returned.

For example:

mysubdomain.mydomain.com
Address: 123.123.123.123

You can also use online DNS lookup tools to check whether the record has propagated.

Step 6: Configure HTTPS

Once the subdomain is pointing correctly to your VPS, you will probably want to enable HTTPS.

Instead of accessing:

http://mysubdomain.mydomain.com

you want:

https://mysubdomain.mydomain.com

If you're using Nginx, one popular option is Certbot with Let's Encrypt.

Let's Encrypt provides free TLS certificates for HTTPS.

You can learn more from the official Let's Encrypt documentation.

How Long Does DNS Propagation Take?

DNS changes are not always visible immediately.

After creating the A record, it can take some time before different DNS resolvers around the internet start returning the new IP address.

You may see the subdomain working within a few minutes, while in some cases you may need to wait longer.

This is commonly referred to as DNS propagation.

So don't worry if:

Your computer → old DNS information

while another device or DNS checker already sees:

mysubdomain.mydomain.com → Contabo VPS

DNS caching can cause temporary differences.

Common Mistakes to Check

If your subdomain isn't working, check these things first.

1. Wrong IP address

Make sure the A record points to the public IPv4 address of your Contabo VPS.

2. Incorrect DNS record

Make sure you created an A record, not a CNAME record, if you're directly pointing the hostname to an IPv4 address.

3. Web server isn't configured

DNS can successfully point the domain to your VPS, but Nginx, Apache, or your control panel still needs to know how to handle the hostname.

4. Firewall

Make sure your VPS firewall allows HTTP and HTTPS traffic.

Typically:

Port 80  - HTTP
Port 443 - HTTPS

5. DNS hasn't propagated yet

Give the DNS change some time and check it using nslookup, dig, or an online DNS checker.

The Final Setup

Once everything is configured, the architecture will look something like this:

                    Internet
                       |
                       |
        mysubdomain.mydomain.com
                       |
                       ↓
              DNS A Record
                       |
                       ↓
             Contabo VPS IP
              123.123.123.123
                       |
                       ↓
                Nginx / Apache
                       |
                       ↓
                Your Application

Your main domain can continue operating normally:

mydomain.com

while your subdomain runs from the Contabo VPS:

mysubdomain.mydomain.com

You don't need to move the entire domain to Contabo just to host one application on your VPS.

Conclusion

Pointing a subdomain to a Contabo VPS is relatively straightforward once you understand the separation between DNS and your server.

The basic process is:

Find your Contabo VPS IP address.
Open your domain's DNS Zone Editor.
Create an A record for your subdomain.
Point the A record to the VPS IP address.
Configure Nginx, Apache, or your server software to handle the subdomain.
Wait for DNS changes to propagate.
Configure HTTPS once the domain resolves correctly.

The key thing to remember is that DNS only tells the internet where your server is. Your VPS still needs to be configured to serve the application for that specific hostname.

Once you understand this pattern, you can use it to host multiple applications on the same VPS, for example:

api.mydomain.com
app.mydomain.com
admin.mydomain.com
blog.mydomain.com

All of them can point to the same VPS while your web server routes each hostname to the appropriate application.

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.