DEV Community: Shubham Singh

How the Web Actually Works: A Developer's Mental Model of Modern Architecture

Shubham Singh — Tue, 29 Sep 2026 19:06:26 +0000

I spent a long time writing code before I genuinely understood what happened after I hit Enter on a URL. I knew about frontend and backend. I had a vague sense that CDNs existed. But if someone asked me to draw the path a request takes from a browser to a database and back — I would have drawn something embarrassingly incomplete.

This post is the explanation I wish I had early on. No Docker. No Kubernetes deep-dives. Just the foundational mental model of how modern web architecture actually fits together — the pieces every developer should be able to reason about clearly.

What Actually Happens When You Type a URL

Let us start with the most fundamental question: you open a browser, type https://example.com, and press Enter. What happens?

Most people say "the browser loads the page." That is true in the same way that "a car moves" describes a Formula 1 race. The real answer involves at least six different systems activating in under a second.

Step 1 — DNS Resolution

Your browser does not understand names like example.com. It only speaks in IP addresses — things like 104.21.5.8. So the first thing it does is ask a system called DNS (Domain Name System) to translate:

Browser:  "Where is example.com?"
DNS:      "It is at 104.21.5.8"

DNS is essentially a phone book for the internet. The key thing to understand is that the IP address DNS returns is usually not your actual application server. It almost always belongs to a CDN, a load balancer, or a reverse proxy sitting in front of your real infrastructure. More on those shortly.

Step 2 — HTTPS and Encryption

Once the browser has an IP, it does not just start firing data at it. It first sets up an encrypted channel using TLS (the protocol behind HTTPS). Think of this as sealing your request in an envelope that only the destination server can open.

Without this encryption, anyone on the same network — say, someone on the same coffee shop WiFi — could read everything you send: passwords, session cookies, tokens, form data. HTTPS makes the entire conversation private.

Step 3 — The Edge Layer

Here is something most tutorials skip over. Your request does not go straight to your app. It hits what is called the edge layer first — a set of systems sitting between the public internet and your actual servers.

System	What it does
CDN (Cloudflare, CloudFront)	Caches files near the user, absorbs load
Load Balancer	Spreads traffic across multiple servers
Reverse Proxy	Routes requests, hides backend infrastructure
WAF	Blocks malicious traffic before it reaches your app

This layer is doing real work: blocking attack traffic, serving cached files without ever touching your application, routing requests to the right place, and encrypting/decrypting connections. By the time a request actually reaches your application, it has already been filtered and directed.

Steps 4–6 — Application, Database, Response

The request finally reaches your application server, which processes it: checks if you are logged in, queries a database, applies business logic, and assembles a response. That response — HTML, CSS, JavaScript, or JSON — travels back the same chain to your browser, which renders what you see.

The full journey:

You type example.com
       │
       ▼
DNS  →  IP address returned
       │
       ▼
HTTPS connection opened (encrypted)
       │
       ▼
Edge layer (CDN / Load Balancer / Reverse Proxy)
       │
       ▼
Application server
       │
       ▼
Database (if needed)
       │
       ▼
Response travels back
       │
       ▼
Browser renders the page

All of that happens in roughly 50–200 milliseconds. Every step matters.

The Most Important Split: Frontend vs Backend

Every web system is divided into two distinct worlds, and confusing them causes real architectural mistakes.

Frontend is everything the user sees and interacts with — buttons, layouts, forms, animations. In modern development, frontend code (React, Vue, Angular) runs inside the user's browser, not on your server. Once the browser downloads your JavaScript bundle, it executes locally on the user's device. Your server is no longer involved in rendering the UI.

Backend is everything that runs on your server, hidden from users. It handles things that require authority and trust:

Authenticating who you are
Checking what you are allowed to do
Reading and writing to databases
Processing payments
Sending emails
Enforcing business rules

The single most important distinction between these two:

Frontend:  Runs in the USER's browser — never trust it with secrets
Backend:   Runs on YOUR server — this is where authority lives

This is not just a conceptual distinction. It has real security consequences. Frontend code can be read by anyone — open DevTools, open the source, everything is visible. Sensitive logic, secret keys, and authorization decisions must always live on the backend. The frontend presents information; the backend enforces rules.

Static vs Dynamic Content

Not all content on the web is the same kind of thing, and understanding the difference shapes every hosting decision you make.

Static content is identical for every single user who requests it. Your JavaScript bundle, CSS files, images, fonts — these files do not change based on who is asking. They are the same for a first-time visitor in Delhi and a returning user in Berlin.

Dynamic content is generated fresh for each request, personalised per user. Your dashboard data, account balance, notification count, order history — this content is unique and cannot be pre-baked.

Why does this matter? Because the strategies for serving them are completely different:

Static content  →  Serve from CDN (fast, cheap, globally distributed)
Dynamic content →  Must go through your backend server (personalised, cannot be cached naively)

Smart architecture offloads as much as possible to static delivery and keeps the backend focused only on work that genuinely requires computation or personalisation.

SPA vs SSR: Two Different Ways to Build a Frontend

There are two dominant approaches to building web frontends, and they have meaningfully different architectures.

SPA — Single Page Application

A SPA (React, Vue in standard mode) works like this: the browser downloads the entire frontend application once — HTML, CSS, a JavaScript bundle — and React boots up inside the browser. From that point, all navigation happens inside the browser. When data is needed, React calls your backend API, gets JSON back, and updates the page without a full reload.

First visit:
  Browser → Downloads React app (index.html + main.js)

All subsequent interactions:
  React (in browser) → calls API → backend returns JSON → React updates UI
  No full page reloads. The server's job is essentially done after the initial download.

The big upside: smooth, app-like experience. The static files sit perfectly on a CDN. Frontend and backend are completely independent.

The known tradeoffs: the first load requires the browser to download and execute JavaScript before anything renders, which can feel slow. Search engines historically struggled with pages that were empty HTML shells populated only after JavaScript ran — though this has improved significantly.

SSR — Server-Side Rendering

SSR (Next.js, Nuxt) addresses those tradeoffs by doing the rendering work on the server before sending content to the browser:

Browser requests /product/123
Server runs React, fetches product data, generates complete HTML
Browser receives ready-to-display HTML immediately
JavaScript loads in background and makes page interactive

The user sees real content almost immediately. Search engine crawlers see actual content, not an empty <div id="root">. The tradeoff is that SSR requires a running server — you cannot just put it on a CDN and walk away.

Most modern frameworks like Next.js support both modes at once: some pages pre-rendered at build time, others server-rendered on each request, others rendered purely in the browser. You pick per page.

API-Driven Architecture: Why Frontend and Backend Are Separate

Older web applications were tightly coupled — the server generated complete HTML pages and sent them to the browser. Modern systems separate frontend and backend into independent services that communicate through APIs.

An API (Application Programming Interface) is simply a set of URLs your backend exposes that return structured data, almost always JSON:

Frontend calls:  GET /api/user/42
Backend returns: { "id": 42, "name": "Priya", "email": "priya@example.com" }
Frontend renders: a profile card with that data

This separation pays dividends in multiple ways. The same backend API serves your web frontend, your iOS app, your Android app, and any third-party integrations — all consuming the same endpoints. Frontend teams deploy independently of backend teams. You can rewrite the frontend in a completely different framework without touching the backend.

The principle here is loose coupling — components that communicate through clean interfaces rather than being tangled together. It is one of the most important architectural patterns in modern software.

CDN: Why the Web Can Be Fast for Everyone

Without a CDN, every user in the world downloads files from your one server. A user in Frankfurt downloading your JavaScript from a server in Mumbai is adding 150–200ms of network round-trip latency to every asset, before their browser even starts executing anything.

A CDN (Content Delivery Network) solves this by maintaining hundreds of servers — called edge nodes — distributed globally. When you upload your static files to a CDN, it replicates them across these locations:

Without CDN:
  User in Frankfurt → Server in Mumbai → 180ms just in network travel

With CDN:
  User in Frankfurt → CDN edge in Frankfurt → 5ms
  User in Delhi     → CDN edge in Delhi     → 3ms
  User in New York  → CDN edge in New York  → 4ms

The first time a user in Frankfurt requests your main.js, the CDN fetches it from your origin server and caches it locally. Every user after that — from Frankfurt or anywhere nearby — gets it directly from that edge node. Your origin server is not involved at all.

This is what "cache hit" means: the file was already at the nearest edge. At scale, a well-configured CDN will serve 95%+ of static file requests from cache, leaving your origin server mostly untouched.

One clarification worth making explicit: CDNs are excellent at serving static content. They are not designed for your dynamic API responses that contain personal user data. Those must still reach your backend.

Reverse Proxies: The Traffic Directors

A reverse proxy is a server that sits in front of your application and mediates all incoming traffic. Users talk to the proxy; the proxy talks to your app. Users never contact your application directly.

Internet → Reverse Proxy → Your Application

Nginx is the most common reverse proxy, and it earns its place by handling several things your application should not have to deal with:

TLS termination — the reverse proxy handles HTTPS decryption so your application code receives plain HTTP. You manage one certificate, at the proxy, not inside every service.

Routing — requests to /api/* go to the backend server, requests to / go to the frontend server. One proxy, multiple destinations.

Compression — the proxy compresses responses automatically. A 500KB JSON payload can compress to 80KB, reducing transfer time by 84%.

Rate limiting — block clients making too many requests before they ever touch your application code.

Buffering — this one is subtle but important. Without buffering, slow mobile clients keep Gunicorn workers busy for the entire duration of the download, even though Django finished generating the response in 10ms. With buffering, the proxy receives the full response instantly, frees the Gunicorn worker, and then slowly drips data to the slow client. Your application becomes far more concurrent.

Load Balancers: Distributing the Work

When traffic grows beyond what one server can handle, you run multiple copies of your application and use a load balancer to distribute requests across them:

Users
  │
  ▼
Load Balancer
  ├── Server 1
  ├── Server 2
  └── Server 3

The load balancer tracks which servers are healthy and routes new requests to available ones. If Server 2 goes down, the load balancer stops sending it traffic automatically. When it recovers, it is added back.

This setup also enables something powerful: you can take servers offline for updates without any downtime. Take Server 1 offline, update it, bring it back, then do the same for Server 2. Traffic continues flowing to the remaining healthy servers throughout.

Load balancers are also the entry point for autoscaling. At low traffic: two servers. Traffic spikes: add four more. Load balancer starts including them immediately.

Stateless vs Stateful: The Architectural Divide That Shapes Everything

This concept shows up in every conversation about scaling, and it is worth understanding precisely.

A stateless system stores no important data locally. Every request it receives is self-contained — the server does not need to remember anything about previous requests to handle the next one. If you have three copies of a stateless backend running, any of them can handle any request. Kill one, start another, it picks up immediately.

A stateful system holds critical persistent data. A database is stateful. If your PostgreSQL instance disappears, so does every user record, every order, every piece of data your product is built on. You cannot simply start a fresh copy and continue — the data is gone.

Stateless → Can restart anytime, scale freely, failures are trivial to recover
Stateful  → Requires persistent storage, backups, replication, failover plans

The golden rule of modern web architecture follows from this: make your application logic stateless. Store all persistent data in dedicated external systems — databases, cache stores, object storage. Your application servers then become disposable: scale them up, scale them down, replace crashed ones, deploy new versions — none of it risks data loss because there is no important data inside them.

A concrete example: if a user uploads a profile photo and your backend stores it on the server's local filesystem, you have a stateful application. When that server restarts or gets replaced, the photo is gone. If instead the backend uploads the photo to object storage (S3, R2, or similar) and stores only the URL in the database, the server becomes stateless again — it holds nothing of value that cannot be recovered.

The Three-Layer Production Architecture

Modern production systems are almost always organised into three distinct layers. Understanding this structure helps you reason about where things live and why.

DELIVERY LAYER
  CDN (Cloudflare, CloudFront)
  Serves static files from hundreds of global locations
  React app, CSS, images, fonts

         │
         ▼

COMPUTE LAYER
  Application servers
  Backend APIs, business logic, authentication
  WebSocket services for realtime features
  Background workers for async jobs

         │
         ▼

DATA LAYER
  PostgreSQL (relational data — users, orders, content)
  Redis (fast cache, sessions, realtime pub/sub)
  Object Storage (uploaded files, images, documents)

The delivery layer is cheap and globally fast — CDN infrastructure is designed to handle enormous traffic with minimal cost. The compute layer is stateless and scales horizontally — add more servers during peaks, remove them during quiet periods. The data layer is stateful and requires the most careful management — this is where persistence, replication, and backups live.

Here is what a real request looks like flowing through this:

A user loads your React app:

Browser → CDN edge (nearest city) → serves main.js from cache → React boots up

That user logs in:

Browser → Cloudflare → Load Balancer → Backend API
        → database query (verify credentials)
        → returns auth token to browser

React fetches dashboard data:

Browser → Load Balancer → Backend API
        → Redis (check cache — is this data already stored?)
        → Cache miss → PostgreSQL query
        → Store result in Redis for next request
        → Return JSON → React renders the page

Each layer does what it is best at. Static files never touch your backend. Dynamic data never hits the CDN. Frequently-accessed data gets cached in Redis so the database is not queried repeatedly for the same thing.

The Mental Models That Actually Matter

After understanding all of the above, a few core ideas stand out as the ones worth internalising:

The web is many systems, not one. A single URL request involves DNS, TLS negotiation, CDN caching, load balancing, application processing, and database queries. Understanding which layer is responsible for what makes debugging and architecture decisions dramatically clearer.

Frontend and backend are separated by design. The browser runs your UI. Your server runs your logic. Never put secrets or authorization decisions in the frontend — it is visible to everyone.

Static content and dynamic content need different strategies. Files that are the same for everyone belong on a CDN. Data that is personalised or changes frequently must be generated by the backend.

Stateless scales, stateful requires care. Design your application servers to hold no important data. Let databases and dedicated storage systems handle persistence. This is not just good practice — it is what makes modern scaling possible.

The CDN is not optional at scale. Serving files from one server to users on every continent is slow and expensive. CDNs exist to solve this, and they solve it well.

What Comes Next

This is the foundation. The natural next questions — how are applications packaged and deployed, how do they handle thousands of simultaneous users, how does authentication work in distributed systems, how do you build real-time features — all of them build directly on the concepts here.

Once you can picture the full request journey, the layers of a production system, and why stateless design matters, the rest of modern web infrastructure becomes considerably less mysterious.

The concepts have names: containers, orchestration, JWT, WebSockets, message queues. But underneath the vocabulary, they are all answers to the same fundamental questions: how do you serve the right content to the right user, reliably, at scale, without losing data? The architecture described here is how the industry answered those questions.

I Built a Privacy Layer for AI Coding Tools — CodeMask UI and CodeMask Proxy

Shubham Singh — Wed, 19 Aug 2026 15:19:59 +0000

I was debugging a config file of my personal project and pasted it straight into Claude to get help. A few seconds later I looked at what I had actually sent: internal IP addresses, a database password, and an API key. All of it. To a cloud API. Without thinking.

I don't think I am the only one who has done this. Most developers use AI assistants daily, and most of the time the code going in contains things it shouldn't. This post is about the two tools I built to fix that — and what I learned building them.

The Problem — Two Different Workflows

Before building anything, I realized the problem has two distinct shapes depending on how you use AI.

Workflow 1 — Manual AI chat (ChatGPT, Claude.ai, Gemini)

You copy a file, paste it into the chat, ask your question, copy the response. The sensitive data goes in with the code because you are doing the pasting manually and there is no gate between your clipboard and the AI.

Workflow 2 — AI coding agents (Cline, Claude Code, Cursor)

These tools read your files automatically. When you ask Cline to explain a function, it reads the file, builds a prompt, and calls the LLM API directly. There is no paste step at all. Your secrets go out in the background with every request without you ever touching them.

Same root problem, completely different mechanism. Each needed a different solution.

Solution 1 — CodeMask UI

What it is: A browser-based tool that sanitizes code before you share it with any AI chat, and restores real values after the AI responds.

How it works: Two-way flow with a session registry.

When you paste code in and click Sanitize, the tool scans for secrets using regex patterns and replaces each one with a numbered placeholder:

DB_HOST = "192.168.50.100"     →    DB_HOST = "{{IP_1}}"
DB_PASSWORD = "SuperSecret123" →    DB_PASSWORD = "{{PASSWORD_1}}"
API_KEY = "sk-test-abc123..."  →    API_KEY = "{{OPENAI_KEY_1}}"

A registry is built in the background mapping every placeholder to its real value. You copy the sanitized code, paste it into Claude or ChatGPT, and ask your question. When the AI responds with suggestions that reference {{IP_1}}, you paste that response back into the Restore tab. The tool looks up the registry and swaps every placeholder back to the real value before you see it.

The registry persists in localStorage so it survives a page refresh. If you sanitize three different code files in one session, the same IP always gets the same placeholder, and all three can be restored from the same registry.

What it detects automatically:

Category	Examples
IPv4 / CIDR	`10.10.10.10`, `192.168.1.0/24`
IPv6	Full and compressed formats
AWS Keys	`AKIA...`, `AWS_SECRET_ACCESS_KEY`
OpenAI Keys	`sk-...`, `sk-proj-...`, `sk_test_...`
Anthropic Keys	`sk-ant-...`
GitHub Tokens	`ghp_...`, `gho_...`
GitLab Tokens	`glpat-...`
Slack Tokens	`xoxb-...`, `xoxp-...`
Bearer Tokens	`Authorization: Bearer ...`
Generic API Keys	`api_key = "..."`, `token: "..."`
JWT / Signing Keys	`jwt_signing_key = "..."`
Passwords (quoted)	`password = "secret"`
Passwords (unquoted)	`PASSWORD=Hello123`, `db_password=secret`
DB Connection Strings	`postgres://user:pass@host`
PEM Private Keys	`-----BEGIN PRIVATE KEY-----` blocks

Architecture — nothing leaves the browser:

This is built with React and Vite. There is no backend, no server, no API calls. The entire sanitize and restore logic runs client-side in the browser. Your secrets never travel anywhere — not even to a server I control. The patterns.js file holds all the detection regexes and sanitizer.js handles the replace and restore logic. Both are plain JavaScript, readable, and extendable.

codemask/
├── src/
│   ├── engine/
│   │   ├── patterns.js       ← detection regexes (add your own here)
│   │   └── sanitizer.js      ← sanitize + restore logic
│   ├── hooks/
│   │   ├── useRegistry.js    ← session state + localStorage persistence
│   │   └── useCopy.js        ← clipboard hook
│   ├── components/
│   │   ├── CodePanel.jsx     ← input/output panels
│   │   ├── RegistryTable.jsx ← secrets table with blur/reveal
│   │   └── ManualAdd.jsx     ← manual secret registration
│   └── App.jsx

Running it locally:

git clone https://github.com/shubham-singhS2/CodeMask.git
cd CodeMask
npm install
npm run dev
# Open http://localhost:5173

Or with Docker:

docker run -d -p 8080:80 shubhamsinghs2/codemask:latest
# Open http://localhost:8080

One thing worth mentioning: CIDR notation is handled properly. 192.168.1.0/24 becomes {{IP_1}}/24 not {{IP_1}} — the prefix is preserved so the AI still understands it is a network range, not just a host address.

Solution 2 — CodeMask Proxy

The problem with the UI tool for agent workflows:

When you use Cline or Claude Code, the agent reads your project files and sends them to the LLM API automatically. There is no paste step, so there is no place to intercept manually. By the time you see any output, your secrets have already been sent.

The fix is a proxy server.

What it is: A local Node.js/Express server that runs on localhost:8080 and acts as a drop-in replacement for any OpenAI-compatible LLM API endpoint.

You change one setting in your AI agent — point the base URL to localhost:8080 instead of api.openai.com or api.mistral.ai. The agent never knows the difference. Every request passes through the proxy first.

The complete flow:

AI Agent (Cline)
      │
      │  POST /v1/chat/completions
      │  { messages: [{ content: "DB=192.168.1.10 password=secret" }] }
      ▼
CodeMask Proxy (localhost:8080)
      │  scans all message content for secrets
      │  builds session registry
      │  replaces real values with placeholders
      │
      │  POST /v1/chat/completions  ← forwarded to real API
      │  { messages: [{ content: "DB={{IP_1}} password={{PASSWORD_1}}" }] }
      ▼
Real LLM API (Mistral / OpenAI / your org LLM)
      │
      │  response: "The config connects to {{IP_1}} using {{PASSWORD_1}}"
      ▼
CodeMask Proxy
      │  scans response for placeholders
      │  restores real values from session registry
      │
      │  response: "The config connects to 192.168.1.10 using secret"
      ▼
AI Agent — receives real values, works normally

Proof from a real test:

I asked Cline to explain a config.py file containing real IPs and passwords while the proxy was running. This is what the proxy logged as going to Mistral:

[VERIFY] ── What proxy sent to LLM ──────────────────
[read_file for 'config.py'] Result:
1 | DB_HOST = "{{IP_1}}"
2 | DB_PASSWORD = "{{PASSWORD_1}}"
3 | API_KEY = "{{OPENAI_KEY_1}}"
[VERIFY] ─────────────────────────────────────────────

Mistral never saw a single real value. Cline received the response with real values fully restored and worked normally.

Session management — in-memory with TTL:

The registry that maps {{IP_1}} back to 192.168.1.10 lives in server memory, not a database or file. Each agent gets a session (derived from its API key), and sessions expire automatically after 60 minutes of inactivity. A cleanup timer runs every 10 minutes. If the proxy restarts, sessions clear — which is intentional. There is no sensitive data persisted anywhere on disk.

// Each session holds:
{
  id: "auto-abc123",
  registry: [
    { placeholder: "{{IP_1}}", realValue: "192.168.1.10", type: "ip" },
    { placeholder: "{{PASSWORD_1}}", realValue: "secret", type: "pass" }
  ],
  counters: { ip: 1, key: 0, pass: 1 },
  lastUsed: Date.now(),
  expiresInSec: 3450
}

Streaming — the tricky part:

LLM APIs stream responses as Server-Sent Events (SSE). Each chunk is a small JSON object with a few tokens of content. The challenge: a placeholder like {{IP_1}} can arrive split across two chunks:

Chunk 1: "connect to {{IP"
Chunk 2: "_1}} and use port 5432"

Per-chunk restoration fails because neither chunk contains the complete placeholder. The fix: buffer the entire stream from the LLM, restore placeholders on the complete assembled text, then re-emit the restored content as fresh SSE chunks back to the agent. The agent gets a streaming response. The placeholders are restored correctly. Both requirements satisfied.

Running it:

git clone https://github.com/shubham-singhS2/codemask-proxy.git
cd codemask-proxy
npm install
cp .env.example .env
npm start
# Proxy running at http://localhost:8080

Or with Docker (recommended for daily use — runs in background, restarts on reboot):

docker run -d \
  --name codemask-proxy \
  --restart always \
  -p 8080:8080 \
  -e OPENAI_TARGET_URL=https://api.mistral.ai/v1 \
  shubhamsinghs2/codemask-proxy:latest

Configuring your agent (Cline example):

API Provider: OpenAI Compatible
Base URL:     http://localhost:8080
API Key:      your-real-api-key  ← forwarded transparently
Model:        mistral-small-latest

That is the entire setup. One config change and every request is protected.

Monitoring — endpoints and dashboard:

The proxy exposes management endpoints so you can inspect what is happening:

# Health + global stats
curl http://localhost:8080/status | jq

# Active sessions
curl http://localhost:8080/sessions | jq

# Full registry for one session (values partially masked in output)
curl http://localhost:8080/session/SESSION_ID | jq

# Last 50 requests
curl http://localhost:8080/logs | jq

# Clear a session
curl -X DELETE http://localhost:8080/session/SESSION_ID

There is also a browser dashboard at http://localhost:8080/dashboard showing stat cards, session table with expandable registry, and a request log — useful if you prefer a visual view over curl.

Provider compatibility:

Provider	Works	Notes
OpenAI	✅	Standard format
Mistral	✅	Verified with Cline
Anthropic	✅	`/v1/messages` route
Groq	✅	Set `OPENAI_TARGET_URL=https://api.groq.com/openai`
Ollama	✅	Set `OPENAI_TARGET_URL=http://localhost:11434`
Org / internal LLM	✅	Set `DISABLE_TLS_VERIFY=true` for self-signed certs
AWS Bedrock	❌	SigV4 auth not supported yet
Google Gemini	❌	Different format not supported yet

The self-signed certificate case:

If your organisation runs an internal LLM with a self-signed certificate, Node.js will refuse to connect by default. Rather than setting NODE_TLS_REJECT_UNAUTHORIZED=0 in your terminal every time, you can set it once in .env:

DISABLE_TLS_VERIFY=true

The proxy reads this at startup and sets the flag internally. You never have to think about it again.

Testing Without a Real API Key

Both tools can be tested completely without spending any API credits using a mock LLM server included in the proxy repo.

# Terminal 1 — start mock server (pretends to be Mistral/OpenAI)
node mock-llm.js

# Terminal 2 — start proxy pointing at mock
# Set OPENAI_TARGET_URL=http://localhost:9999 in .env
npm start

# Terminal 3 — send a test request
curl -s -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "x-api-key: fake-key" \
  -d '{
    "model": "gpt-4",
    "messages": [{
      "role": "user",
      "content": "DB=192.168.1.10 password=secret123 fix this"
    }]
  }' | jq

The mock server prints a security check for every request showing whether it received placeholders or real values:

🔍 Security Check:
   Placeholders found : ✅ YES
   Real IPs present   : ✅ NO
   Real passwords     : ✅ NO

How the Two Tools Relate

They solve the same problem at different layers and are designed to be used together.

	CodeMask UI	CodeMask Proxy
For	Manual AI chat (ChatGPT, Claude.ai)	AI coding agents (Cline, Claude Code)
Triggered by	You, manually	Agent requests, automatically
Storage	Browser localStorage	Server memory, TTL-based
Runs as	Static site (Nginx/Vercel)	Node.js process or Docker container
Setup	Open a URL	One docker run or npm start

Both use the same detection engine — patterns.js and sanitizer.js — which is the core logic shared between them.

What Is Next

Both projects are deployed and working. The UI version is running on a K3s cluster deployed via ArgoCD using a GitOps pipeline — GitHub Actions builds a Docker image, pushes to Docker Hub, updates the Kubernetes manifests repo, and ArgoCD syncs the cluster automatically. That deployment story is worth a separate post.

Both are open source:

CodeMask UI: github.com/shubham-singhS2/CodeMask
CodeMask Proxy: github.com/shubham-singhS2/codemask-proxy
Docker Hub (UI): hub.docker.com/r/shubhamsinghs2/codemask
Docker Hub (Proxy): hub.docker.com/r/shubhamsinghs2/codemask-proxy

If you use AI coding tools and have not thought about what goes into those prompts, it is worth spending ten minutes on. The proxy setup takes less time than that.

How to Set Up a Free Custom Domain Email with Zoho Mail, Cloudflare, and Your Own Domain

Shubham Singh — Sat, 01 Aug 2026 18:29:57 +0000

How to Set Up a Free Custom Domain Email with Zoho Mail, Cloudflare, and Your Own Domain

A custom email address like contact@yourdomain.com makes a huge difference when you are building a personal brand, portfolio, or freelance presence. It looks more professional than a free Gmail address, and it is surprisingly easy to set up using Zoho Mail’s free plan and your domain’s DNS.

In this guide, I will walk through the exact flow I used to create a professional email address on a custom domain, without paying for a traditional business email suite.

Important: This post uses placeholder values instead of real DNS records, IPs, or credentials. Replace the examples with the values Zoho shows for your own account.

What you will need

Before you begin, make sure you already have:

A domain name (for example, yourdomain.com)
DNS access in Cloudflare or your domain provider
A Zoho Mail account
A few minutes to add DNS records and wait for propagation

For this setup, I used:

Website hosting: Vercel
DNS: Cloudflare
Email provider: Zoho Mail

That combination works very well for a personal website or portfolio.

Why use Zoho Mail?

Zoho Mail is useful because it lets you create a professional email address using your own domain. On the free plan, Zoho supports a single domain with up to 5 users, 5 GB of storage per user, and web-only access. The free plan is available only in select data centers, so availability may vary by region.

For a personal website, that is usually more than enough.

The overall flow

Here is the setup in simple terms:

Buy a domain.
Sign up for Zoho Mail.
Add your existing domain.
Verify that you own the domain using a TXT record.
Add MX records so mail is delivered to Zoho.
Add SPF, DKIM, and DMARC for email authentication.
Test sending and receiving mail.

Step 1: Sign up for Zoho Mail

Go to Zoho Mail’s signup page and choose the free plan.

During signup, Zoho will ask whether you want to add a new domain or an existing one. Since you already own the domain, choose Add an existing domain.

Enter your domain exactly as it should appear, for example:

yourdomain.com

Do not type www.yourdomain.com for email setup. Email should be configured on the root domain.

Step 2: Verify domain ownership

Zoho will ask you to prove that you own the domain. The simplest method is to add a TXT record in Cloudflare DNS.

Zoho will give you a TXT value similar to this:

zoho-verification=zbXXXXXXXX.zmverify.zoho.in

In Cloudflare, add a new DNS record:

Type	Name	Content
TXT	@	`zoho-verification=zbXXXXXXXX.zmverify.zoho.in`

If Cloudflare does not accept @, use the root domain name directly.

After saving the record, go back to Zoho and click Verify TXT Record.

Once that works, Zoho knows the domain belongs to you.

Step 3: Create your mailbox

After verification, Zoho will let you create the first user account for your domain.

For a personal site, a good choice is:

contact@yourdomain.com

You can also create:

hello@yourdomain.com
shubham@yourdomain.com
resume@yourdomain.com
jobs@yourdomain.com

If you only want one inbox, use aliases later instead of creating multiple mailboxes.

Step 4: Add MX records in Cloudflare

MX records tell the internet where your email should be delivered.

Without MX records, people can send mail to your domain name, but no one will know which server should receive it.

Add the MX records Zoho provides for your data center. For Zoho’s India region, the records usually look like this:

Type	Name	Mail Server	Priority
MX	@	mx.zoho.in	10
MX	@	mx2.zoho.in	20
MX	@	mx3.zoho.in	50

In Cloudflare DNS:

Type: MX
Name: @
Content: mx.zoho.in / mx2.zoho.in / mx3.zoho.in
Priority: 10, 20, 50

Do not proxy MX records. Cloudflare handles them as DNS-only records.

Step 5: Add SPF

SPF tells the world which servers are allowed to send email for your domain.

Add this TXT record:

v=spf1 include:zoho.in ~all

In Cloudflare:

Type	Name	Content
TXT	@	`v=spf1 include:zoho.in ~all`

What SPF means

This says:

Zoho is allowed to send mail for your domain.
Other servers should not be trusted by default.

This helps reduce spoofing and improves inbox delivery.

Step 6: Add DKIM

DKIM adds a digital signature to outgoing email. It helps receivers confirm that the message really came from your domain and was not modified in transit.

Zoho will generate a DKIM public key for you. The record usually looks like this:

Type	Name	Content
TXT	zmail._domainkey	`v=DKIM1; k=rsa; p=YOUR_LONG_PUBLIC_KEY_HERE`

What to do

Open Zoho Admin Console.
Go to DKIM settings.
Generate the DKIM record.
Copy the full TXT value into Cloudflare.
Save the record.
Return to Zoho and verify it.

DKIM verification can take a little longer than SPF because DNS propagation and verification caches may not update instantly.

Step 7: Add DMARC

DMARC is the policy layer that sits on top of SPF and DKIM.

It tells receiving mail servers what to do when authentication fails.

A good starting DMARC record for a personal domain is:

v=DMARC1; p=quarantine; pct=100; adkim=r; aspf=r; rua=mailto:contact@yourdomain.com; ruf=mailto:contact@yourdomain.com

In Cloudflare:

Type	Name	Content
TXT	_dmarc	`v=DMARC1; p=quarantine; pct=100; adkim=r; aspf=r; rua=mailto:contact@yourdomain.com; ruf=mailto:contact@yourdomain.com`

What these parts mean

p=quarantine → suspicious messages should go to spam
pct=100 → apply this policy to all mail
adkim=r → relaxed DKIM alignment
aspf=r → relaxed SPF alignment
rua → aggregate reports
ruf → forensic reports

For most personal domains, relaxed alignment is the simplest and safest choice.

Step 8: Wait for propagation

After you add the records, the changes need time to spread across DNS resolvers.

Usually:

TXT records propagate quickly
MX records may take a little longer
Zoho’s dashboard may still show red or pending status even when everything is already working

Do not panic if Zoho’s UI is slow to update.

A good way to confirm is to test real mail flow.

Step 9: Test sending and receiving

Send a test email from your Zoho mailbox to Gmail.

Then reply from Gmail back to your custom domain email.

If both directions work, the setup is operational.

You can also check the message headers in Gmail to confirm:

SPF: pass
DKIM: pass
DMARC: pass

That is the best real-world proof that your setup is correct.

Common issues and fixes

1. Zoho still shows MX in red

If mail is already working, the DNS is usually fine. Wait for propagation and check again later.

2. SPF is green but DKIM is still pending

That usually means the DKIM TXT record is correct but Zoho has not rechecked it yet, or the record was added recently.

3. Email is landing in spam

Check all three:

SPF
DKIM
DMARC

Also make sure your domain is not sending from an unauthorized service.

4. Cloudflare says the record already exists

Double-check for duplicates. You should have only one SPF TXT record and one DKIM TXT record for each selector.

Optional improvements

Once the core setup works, you can make it even better:

Create aliases

A single inbox can receive mail for multiple addresses such as:

contact@yourdomain.com
hello@yourdomain.com
resume@yourdomain.com
jobs@yourdomain.com

Add a signature

A clean signature makes every email look more professional:

Shubham Singh
DevOps / DevSecOps Engineer

Website: https://yourdomain.com
LinkedIn: linkedin.com/in/your-link
GitHub: github.com/your-handle
Email: contact@yourdomain.com

Use your custom email everywhere

Replace your Gmail address on:

Portfolio website
Resume
LinkedIn contact info
Job applications
GitHub profile
Freelance profiles

That keeps your brand consistent.

What this setup gives you

This setup is not end-to-end encrypted email, but it does give you:

Professional custom email
TLS encryption in transit
SPF authentication
DKIM signatures
DMARC protection
Better inbox deliverability
A clean personal brand

For a portfolio or professional website, this is exactly what you want.

Final DNS record checklist

Here is the full checklist in one place:

Record	Purpose	Example
TXT	Zoho domain verification	`zoho-verification=zbXXXXXXXX.zmverify.zoho.in`
MX	Incoming mail delivery	`mx.zoho.in`, `mx2.zoho.in`, `mx3.zoho.in`
TXT	SPF	`v=spf1 include:zoho.in ~all`
TXT	DKIM	`v=DKIM1; k=rsa; p=...`
TXT	DMARC	`v=DMARC1; p=quarantine; ...`

Conclusion

With a domain, Cloudflare DNS, and Zoho Mail’s free plan, you can build a fully professional email address without paying for a large business email suite.

For a personal portfolio, that is one of the best low-cost upgrades you can make.

It improves your credibility, looks cleaner on your website, and gives your project a more polished finish.