DEV Community: MysticMc

Why Can't My App Connect to My Database?

MysticMc — Fri, 09 Oct 2026 11:39:55 +0000

A beginner's guide to the 4 checks on AWS

The big idea first

When your app connects to a database, the connection has to pass 4 checks, one after another. If any one fails, the connection fails.

Think of visiting a friend in a secure apartment building:

Step	Building analogy	On AWS + PostgreSQL
1	The front gate lets you in	Security group allows the traffic
2	Someone is home to answer the door	PostgreSQL is listening for connections
3	Your name is on the visitor list	`pg_hba.conf` allows your app
4	You know the secret password	Username and password are correct

Keep this picture in mind. Everything below explains one of these steps.

Part 1: Security groups (gate 1)

What is a security group?

A security group is a firewall for your AWS resources, like an EC2 instance (a virtual server). It decides which network traffic is allowed in.

Two rules to remember:

Everything coming in is blocked by default. You add rules to allow what you need.
Replies are automatic. If a request is allowed in, the response is allowed back out. You don't need a separate rule for that.

What's in a rule?

Every inbound rule has 3 parts:

Part	Question it answers	Example
Protocol	What kind of traffic?	TCP
Port	Which "door" on the server?	22
Source	Who is allowed to connect?	Your IP address

The "Type" dropdown is just a shortcut

When you pick a Type like SSH or HTTP, AWS fills in the protocol and port for you:

Type	Port	Used for
SSH	22	Logging in to a Linux server
HTTP	80	Normal websites
HTTPS	443	Secure websites
Custom TCP	You choose	Anything else

AWS does not check what's actually running on that port. Picking "SSH" just means "open port 22." If your SSH runs on port 2222, pick Custom TCP and type 2222.

Part 2: Who can connect? (the source)

What does `0.0.0.0/0` mean?

It means anyone on the internet (any IPv4 address).

Does that mean anyone can log in?

No. It means anyone can reach the door and try the lock. They still need the right key, such as your SSH private key.

But it's still risky:

Bots scan the internet all day and will try to break in.
Bugs in software sometimes let attackers in without a key.
Future mistakes, like a weak password, become much more dangerous.

Safer options for SSH

Use "My IP" as the source. AWS fills in your IP with /32 at the end, which means "only this one address." If your home IP changes, you'll need to update the rule.
Use AWS Session Manager. It gives you a terminal on your server without opening port 22 at all.

Part 3: Ports

What happens when you open a port?

Situation	Result
Nothing is running on that port	Connection fails, nothing to talk to
An app is running on that port	Traffic can reach that app

Why big port ranges are dangerous

Opening 3000-9000 opens 6,001 ports, not just the one you need.

Today, maybe only your web app is running. Next week you install PostgreSQL on port 5432, and it's suddenly exposed to the internet without you changing anything in AWS.

Common ports to know:

Port	Usually used by
3000	Dev web apps, Grafana
5432	PostgreSQL
6379	Redis
8080	Jenkins, Tomcat

Rule of thumb: open only the ports you need, only to the sources that need them.

Part 4: Connecting an app server to a database server

You have two servers:

App server: runs your website
Database server: runs PostgreSQL

You want the app to reach the database and block everyone else.

Option A: allow the app server's IP (works, but annoying)

Port: 5432    Source: 10.0.1.25/32

The problems:

If you replace the app server, it gets a new IP, and you have to update the rule.
If you add 10 app servers, you need 10 rules.

Option B: allow a security group (better)

Create a security group called app-sg.
Attach it to your app server.
On the database's security group, allow:

Port: 5432    Source: app-sg

This means: "Allow any server wearing the app-sg badge."

Replace a server? Give the new one app-sg. No rule changes.
Add 10 servers? Give them all app-sg. Still one rule.

⚠️ One catch: this only works when the app connects to the database's private IP (inside the same network). If it uses the database's public IP, the badge isn't recognized and the connection will time out.

Part 5: The 4 gates in detail

Gate 1: Security group

Question: Is traffic allowed to reach port 5432?

The database's security group needs a rule allowing TCP 5432 from app-sg.

Gate 2: Is PostgreSQL listening?

Question: Is PostgreSQL accepting connections from other machines?

By default, PostgreSQL usually listens only to itself (localhost). Other servers can't reach it.

To fix it, edit postgresql.conf:

listen_addresses = '*'

This means "listen on all network connections." It does not mean anyone can log in. Gates 3 and 4 still protect you.

💡 You must restart PostgreSQL after changing this. A reload isn't enough.

Gate 3: PostgreSQL's visitor list (`pg_hba.conf`)

Question: Is this app allowed to connect to this database as this user?

PostgreSQL has its own list of who's allowed, separate from AWS. You need a line in pg_hba.conf allowing your app server to connect to mydb as user app. For example, to allow the app server's whole subnet:

# TYPE  DATABASE  USER  ADDRESS        METHOD
host    mydb      app   10.0.1.0/24    scram-sha-256

💡 After editing, reload PostgreSQL.

Gate 4: Username and password

Question: Are the login details correct?

Host:     10.0.2.40
Port:     5432
Database: mydb
Username: app
Password: (the correct one)

Even if gates 1–3 are perfect, a wrong password means no entry.

Part 6: Reading error messages

The error message tells you which gate failed. This is the most useful skill in this guide.

Error message	What it feels like	Which gate	What to check
`Connection timed out`	Waits a long time, then gives up	Gate 1 (network)	Security group rules, network settings, server firewall
`Connection refused`	Fails instantly	Gate 2	Is PostgreSQL running? Is it listening on the network?
`no pg_hba.conf entry for host...`	PostgreSQL answered but said no	Gate 3	Your `pg_hba.conf` rules
`password authentication failed`	Got all the way to login	Gate 4	Username, password, does the user exist?

💡 Good news hidden in errors: the further down the table your error is, the more is already working. A password error means gates 1–3 are fine.

💡 "Password authentication failed" also appears if the user doesn't exist at all. PostgreSQL does this on purpose so attackers can't guess usernames.

Part 7: Two commands to test

Run these from the app server.

Test 1: Can I reach the port? (gates 1–2)

nc -zv 10.0.2.40 5432

Success means the network path works and something is listening.
It does not test the password or pg_hba.conf.

Test 2: Can I log in? (all 4 gates)

psql -h 10.0.2.40 -U app -d mydb

Part	Meaning
`-h 10.0.2.40`	Database server's address
`-U app`	Log in as user `app`
`-d mydb`	Connect to database `mydb`

Success means all 4 gates pass.
Failure means you read the error and match it to the table in Part 6.

Part 8: Troubleshooting checklist

When the app can't connect, don't change random settings. Go in order:

Security group: Does the DB allow port 5432 from app-sg?
Network: Can the app server reach the DB's private IP? (nc -zv)
PostgreSQL running: Is it running and listening on the network?
Visitor list: Does pg_hba.conf allow this app, database, and user?
Login: Are the username and password correct? (psql)

Quick recap

Term	One-line meaning
Security group	AWS firewall that controls incoming traffic
Type dropdown	Shortcut that fills in the port
`0.0.0.0/0`	Anyone on the internet. Avoid for SSH and databases
`/32`	Exactly one IP address
Port range	Opens every port in the range. Keep it narrow
SG as source	"Allow anything with this badge"
`listen_addresses`	Makes PostgreSQL listen to the network
`pg_hba.conf`	PostgreSQL's own visitor list

The one thing to remember:

Security group → PostgreSQL listening → pg_hba.conf → Password

These are 4 separate locks. Fixing one doesn't fix the others. The error message tells you which lock is stuck.

Good to know later (skip for now)

Once you're comfortable with the basics, look into these:

Network ACLs, a second, stricter firewall layer on subnets.
Outbound rules on the app's security group.
IPv6 (::/0), the IPv6 equivalent of 0.0.0.0/0.
AWS RDS, a managed database where gates 2 and 3 work a bit differently.

originally published at https://github.com/nazmur96/devops-learning-journal/blob/main/networking/why-cant-my-app-connect-to-my-database.md

How Code Goes from Your Laptop to the User

MysticMc — Thu, 08 Oct 2026 14:15:27 +0000

The big idea

Every programming language solves the same four problems:

Where does the program start? → the Entry Point
How do I get other people's code (libraries)? → the Dependency Manager
How do I turn my code into something ready to ship? → the Build Tool
What do I actually give to the user or server? → the Final Output

A simple analogy is a recipe:

Step	Recipe analogy	Software
Entry Point	"Step 1" of the recipe	The first file that runs
Dependency Manager	Going shopping for ingredients	Downloading libraries
Build Tool	Cooking	Compiling and packaging
Final Output	The finished dish	The file you deploy

The tools have different names in each language, but the job is the same.

Two families of languages

Most of the differences come from one question: does the final output need a runtime installed to work?

Family A: compiled to a single binary (Go, Rust).
The output is one file that runs by itself. You copy it to a server and run it. Nothing else needs to be installed.

Family B: needs a runtime (Java, C#, Python, JavaScript).
The output only works if a "helper program" is installed on the machine:

Java needs the JVM (Java Virtual Machine)
C# needs the .NET runtime
Python needs the Python interpreter
JavaScript needs a browser (or Node.js on a server)

With this in mind, the rest is easier to remember.

Language by language

1. JavaScript (frontend)

Entry Point: index.html loads index.js (or main.js)
Dependencies: npm, yarn, or pnpm, listed in package.json
Build Tool: Vite or Webpack. These combine many files into a few, make them smaller, and make them work in all browsers.
Output: A folder (usually dist/) with .js, .css, and image files. A web server or CDN serves these to the browser.

2. Java

Entry Point: A class with a public static void main() method, such as Main.java, or Application.java in Spring Boot
Dependencies: Maven (pom.xml) or Gradle (build.gradle)
Build Tool: The same Maven or Gradle. They both download libraries and build.
Output:
- .jar: runs directly with java -jar app.jar (the modern way)
- .war: deployed into a server like Tomcat (the older way)

3. Python

Python is interpreted. It reads and runs your .py files directly, so normally there is no real "build" step.

Entry Point: main.py (or whichever script you run first)
Dependencies: pip with requirements.txt, or newer tools like Poetry or uv with pyproject.toml
Build/Packaging Tool: Only needed in special cases:
- setuptools or Poetry, to publish a library for others
- PyInstaller, to make a standalone program for people without Python
Output: Usually just your source code plus its dependencies. Optionally a package on PyPI (a .whl file) or a .exe from PyInstaller.

4. Go

Go was built by Google to compile fast and to produce one self-contained file. Everything you need comes with Go itself.

Entry Point: main.go, specifically the main() function inside package main
Dependencies: Go Modules (go.mod and go.sum)
Build Tool: go build, which is built in
Output: One binary file that includes your code and all libraries. No runtime needed.

5. Rust

Rust focuses on speed and safety. One tool, Cargo, handles almost everything.

Entry Point: src/main.rs
Dependencies: Cargo. Libraries are called "crates" and are listed in Cargo.toml.
Build Tool: cargo build, which calls the rustc compiler for you
Output: One fast binary file, or a .wasm (WebAssembly) file that runs in browsers

6. C# / .NET

Modern C# works much like Java: code is compiled for a runtime, not directly for the machine.

Entry Point: Program.cs
Dependencies: NuGet, listed in the .csproj file
Build Tool: dotnet build (which uses MSBuild behind the scenes)
Output: A .dll file that runs on the .NET runtime, or a self-contained executable that bundles the runtime inside

Summary table

Language	Entry Point	Dependency Manager	Build Tool	Final Output	Needs runtime?
JavaScript	`index.html` / `index.js`	npm / yarn	Vite / Webpack	`dist/` folder (JS, CSS, assets)	Yes (browser)
Java	`Main.java`	Maven / Gradle	Maven / Gradle	`.jar` / `.war`	Yes (JVM)
Python	`main.py`	pip / Poetry / uv	Usually none (PyInstaller optional)	Source code, `.whl`, or `.exe`	Yes (Python)
Go	`main.go`	Go Modules	`go build`	Single binary	No
Rust	`main.rs`	Cargo	`cargo build`	Single binary / `.wasm`	No
C#	`Program.cs`	NuGet	`dotnet build`	`.dll` / executable	Usually (.NET)

Two things people often get wrong

Python .pyc files are not a deployment output. Python creates them automatically as a speed cache. You don't ship them.
In Java and Rust, one tool does two jobs. Maven/Gradle and Cargo both download dependencies and build. Go is similar with the go command. Only JavaScript clearly separates the two (npm + Vite).

Why this matters for DevOps

This is the knowledge you need when writing Dockerfiles and CI pipelines. The Final Output decides what goes into your container image:

Go / Rust: Copy just the binary into a tiny image (scratch or distroless). The result is very small and secure.
Java: Build the .jar, then copy it into an image that has a Java runtime (JRE).
Python: Use a Python base image, install dependencies, and copy in the source code.
JavaScript frontend: Build the dist/ folder, then serve it with Nginx. Node isn't needed in the final image.

This is why multi-stage Docker builds are common: stage 1 has all the build tools, and stage 2 contains only the final output.

originally published at https://github.com/nazmur96/devops-learning-journal/blob/main/foundations/how-code-goes-from-laptop-to-user.md

Kubernetes Networking, Explained Simply

MysticMc — Thu, 08 Oct 2026 10:47:47 +0000

0. Two words you need first

Pod: a running copy of your app. Pods come and go, and their addresses change.
Service: a stable name and address that always points to the right Pods, even when they change. Other parts of the system talk to the Service, not to Pods directly.

That's all the Kubernetes you need for the rest of this.

1. The big idea: sort tools by job, not by rivalry

When you see a list like ALB, NGINX, Traefik, Cilium, F5, it looks like they're all fighting each other. Most of them aren't. They do different jobs.

So don't ask "which tool is best?" Ask:

"What job needs doing, and which tool will do it?"

2. The 5 networking jobs

Think of a Kubernetes cluster like an office building:

#	Job	Simple question	Building analogy	Common tools
1	Pod networking (CNI)	How does each Pod get an address and talk to others?	Wiring and room numbers inside the building	AWS VPC CNI, Cilium, Calico, Flannel
2	External load balancer	Who receives traffic from the internet first?	The front door	AWS ALB, AWS NLB, F5, HAProxy
3	Routing rules (written)	How do I describe where traffic should go?	The sign on the wall: "Sales → 2nd floor"	Ingress (older), Gateway API (newer)
4	Routing implementation	Who actually follows those rules?	The receptionist who reads the sign and sends people the right way	AWS Load Balancer Controller, NGINX, Traefik, Kong, Cilium
5	Service-to-service control (mesh)	How do services inside talk to each other safely and reliably?	Internal security and hallway rules	Istio, Linkerd, Cilium

CNI stands for Container Network Interface. It's just the name for "the plugin that gives Pods their networking."

Important: Job 3 is just rules written down. Gateway API does nothing on its own. It needs a tool from Job 4 to make the rules real.

You pick one tool per job, and only for the jobs you actually need. A service mesh (Job 5), for example, is optional.

Why Gateway API instead of Ingress?

Both are ways to write routing rules. The difference:

Ingress can only describe simple things, like "this URL goes to that Service." For anything fancier (splitting traffic 90/10, matching on headers), every tool invented its own custom add-ons, so your rules only worked with that one tool.
Gateway API builds those features into the standard itself, so your rules work the same way no matter which tool follows them.

The popular community ingress-nginx controller was retired in March 2026, which is pushing many teams to switch to Gateway API now.

3. One key idea: "L4" vs "L7" front doors

You'll see these terms everywhere. They describe how much a load balancer looks at before passing traffic on.

Type	What it does	Mail analogy	AWS example
L4	Passes connections through without looking inside. Fast and simple.	A mail sorter that only reads the building address	NLB
L7	Opens the request and reads it (the URL, headers, etc.), then decides where to send it. Smarter.	A mail sorter that also reads "Attention: Sales department"	ALB

Keep this in mind. It explains why the projects below pick different front doors.

4. The example app

We'll build the same small online shop three different ways:

frontend   →  the website
api        →  the backend logic
payment    →  handles payments
database   →  stores data

About the database: it isn't part of the incoming-traffic story. Internet users never reach it directly. Only the api and payment services talk to it. In AWS setups it often lives outside the cluster as a managed service (Amazon RDS). So in the pictures below, it sits at the very end.

5. Project 1: The "let AWS do it" setup

Mindset: "I use Kubernetes, but I want AWS to handle as much networking as possible."

Very common in AWS-heavy companies.

Job	Tool
Pod networking	AWS VPC CNI
Front door	AWS ALB (L7)
Routing rules	Gateway API
Who makes the rules real	AWS Load Balancer Controller
Service-to-service	None yet (no mesh)

            INTERNET
                │
                ▼
            AWS ALB  ◄──── AWS Load Balancer Controller
                │          (reads your Gateway API rules
                │           and sets up the ALB to match)
                ▼
        ┌───────┴───────┐
        ▼               ▼
    frontend           api
                        │
                        ▼
                     payment
                        │
                        ▼
                    database
                 (Amazon RDS,
               outside the cluster)

Underneath: AWS VPC CNI gives every Pod a real IP from your AWS VPC

How a request travels. A user visits https://shop.example.com/api:

The request hits the AWS ALB.
Because the ALB is L7, it reads the URL and sees "/api goes to the api service."
The request reaches the api Pod.

Worth knowing: the AWS Load Balancer Controller is not in the path the traffic takes. It works behind the scenes: it reads your Gateway API rules and sets up the ALB to match them. The traffic itself goes ALB → Pod.

When would you add a service mesh later? When you start needing things like:

encrypted traffic between your own services (called mTLS)
automatic retries when a service briefly fails
detailed numbers on how each service is talking to the others

Until then, skipping the mesh keeps things simpler.

Why choose this setup: less to install and maintain yourself, because AWS runs the hard parts. The downside is that you're tied to AWS.

6. Project 2: AWS outside, open-source inside

Mindset: "We use AWS for the cloud, but we want the Kubernetes networking to not depend on AWS."

Job	Tool
Pod networking	Cilium
Front door	AWS NLB (L4)
Routing rules	Gateway API
Who makes the rules real	Cilium
Service-to-service	Cilium

            INTERNET
                │
                ▼
            AWS NLB        (L4: just passes traffic in)
                │
                ▼
             Cilium        (reads the URL and follows
                │           your Gateway API rules)
     ┌──────────┼──────────┐
     ▼          ▼          ▼
 frontend      api      payment
     └──────────┴──────────┘
                │
                ▼
            database

   Cilium also controls traffic and
   security between the services

Notice: one tool, Cilium, does many jobs at once:

Pod networking (CNI)
Network policy (who is allowed to talk to whom)
Following your Gateway API rules
Both simple (L4) and smart (L7) traffic handling

Why the NLB instead of the ALB? This is where L4 vs L7 matters. The NLB is a simple front door that just passes traffic through, and Cilium makes the smart routing decisions. If you used the ALB, it would do the routing itself, and that's exactly the AWS-specific part you're trying to avoid.

Why choose this setup: if you ever move off AWS, most of your Kubernetes networking (Cilium + Gateway API) comes with you. Only the NLB needs replacing.

7. Project 3: Mostly open-source, runs anywhere

Mindset: "The same platform has to run on AWS, Azure, our own servers, bare metal and private cloud."

Job	Tool
Pod networking	Cilium
Front door	HAProxy
Routing rules	Gateway API
Who makes the rules real	Traefik
Service-to-service	Istio

            INTERNET
                │
                ▼
            HAProxy        OUTSIDE the cluster
                │          (stable front door)
   - - - - - - -│- - - - - - - - - - - - -
                ▼
            Traefik        INSIDE the cluster
                │          (follows your Gateway API rules)
     ┌──────────┼──────────┐
     ▼          ▼          ▼
 frontend      api      payment
     └──────────┴──────────┘
                │
                ▼
            database

   Istio controls traffic between services
   (encryption, retries, monitoring)

Underneath: Cilium gives every Pod networking

Why two proxies in a row (HAProxy, then Traefik)? They do different jobs:

HAProxy sits outside the cluster. Its job is to be a stable front door with a fixed address. If a server inside the cluster dies, HAProxy just stops sending traffic there. It doesn't need to understand Kubernetes at all.
Traefik sits inside the cluster. It understands Kubernetes, reads your Gateway API rules, and knows which Pods are running right now.

Think of HAProxy as the building's front door and Traefik as the receptionist inside.

Why choose this setup: almost nothing here is tied to a cloud provider, so the same design works everywhere.

The cost: you run and maintain everything yourself. There are more moving parts, more to learn and more that can break.

8. All three side by side

Job	Project 1 (AWS-heavy)	Project 2 (mixed)	Project 3 (open-source)
Pod networking	AWS VPC CNI	Cilium	Cilium
Front door	AWS ALB (L7)	AWS NLB (L4)	HAProxy
Routing rules	Gateway API	Gateway API	Gateway API
Rule follower	AWS LB Controller	Cilium	Traefik
Service-to-service	None (yet)	Cilium	Istio
Tied to AWS?	A lot	A little	Barely
Effort to run	Lowest	Medium	Highest

Notice: Gateway API stays the same in all three. That's its whole point. It's a standard way to write routing rules, and you can swap out the tool that follows them.

9. Where does MetalLB fit?

People sometimes call MetalLB "Kubernetes' version of HAProxy." That's not quite right.

The problem it solves: in Kubernetes, you can create a Service of type: LoadBalancer, which basically means "give me an address the outside world can reach."

On AWS, Azure or GCP, the cloud automatically creates a load balancer and gives you that address.
On bare metal or your own servers, nobody does this. The Service just sits there stuck on <pending> forever.

MetalLB fills that gap. It hands out outside-reachable addresses to your LoadBalancer Services, doing the job the cloud would normally do.

So a better way to think of it:

MetalLB = "the cloud's load-balancer feature, for clusters that don't have a cloud."

How it connects to Project 3: when Project 3 runs on bare metal, something has to give the entry point a stable address. MetalLB is a common way to do that. It can be used alongside HAProxy, or in simpler setups it can replace the need for a separate outside proxy, giving Traefik its address directly.

In the 5-job list, MetalLB belongs to Job 2 (the front door), but only for clusters without a cloud provider.

10. One-sentence summary

Split networking into 5 jobs, pick one tool per job, and remember that the tools mostly work together rather than compete. How much you hand over to AWS versus run yourself is the real choice you're making.

originally published at https://github.com/nazmur96/devops-learning-journal/blob/main/networking/kubernetes-networking-explained.md

Getting AWS Secrets into EKS Pods with ESO and Pod Identity

MysticMc — Mon, 05 Oct 2026 13:54:14 +0000

So we have an app/microservice/pod which needs access to a secret that we
stored in AWS Secrets Manager, let's say the database password.

We don't want our app to talk to AWS at all. We want the app to just find the
password inside Kubernetes as a normal K8s Secret. So we bring in a middleman
to fetch it for us: ESO (External Secrets Operator).

Part 1: Setup (done once)

Step 1: Install ESO in the cluster

We install External Secrets Operator, usually with Helm, into its own namespace
(external-secrets). This creates the ESO pods and a ServiceAccount for them,
also called external-secrets. Now we have a courier living in our cluster,
but it has no AWS ID card yet.

EKS
 ├── App pod
 └── ESO pod  (ServiceAccount: external-secrets)

Step 2: Install the Pod Identity Agent

We install the EKS Pod Identity Agent add-on. It runs a small helper on every
node. Its job is to hand out AWS credentials to pods that are allowed to have
them. Think of it as the ID card office.

Step 3: Create an IAM role for ESO

We create an IAM role, say ESO-Secrets-Reader:

Permissions policy: "you can read the secret my-app/database" (GetSecretValue, DescribeSecret, limited to only the secrets ESO needs).
Trust policy: "I trust EKS Pod Identity (pods.eks.amazonaws.com) to hand me out to pods."

Step 4: Connect the role to ESO's ServiceAccount

We create a Pod Identity association that tells EKS:

namespace: external-secrets + ServiceAccount: external-secrets
                    ↓
            IAM role: ESO-Secrets-Reader

Meaning: "any pod running with this ServiceAccount gets this role." Now ESO has
an ID card.

Tip: if ESO was already running before you created the association,
restart the ESO pods. Pod Identity sets up the credential wiring when a pod
starts, so old pods won't pick it up.

Part 2: Telling ESO what to do

Step 5: Create a SecretStore

This tells ESO where to look: "AWS Secrets Manager, region
eu-central-1." There are no access keys in here. ESO uses its Pod Identity
credentials automatically.

Step 6: Create an ExternalSecret

This tells ESO what to fetch: "Get my-app/database from that store,
create a K8s Secret called database-secret in my app's namespace, and check
for changes every hour."

Part 3: What happens automatically

Step 7: ESO gets its credentials

ESO needs to call AWS, so the AWS SDK inside ESO asks the Pod Identity Agent
for credentials. The agent checks the association, gets temporary credentials
for ESO-Secrets-Reader, and gives them to ESO. They expire and get refreshed
automatically. No access keys are stored anywhere.

Step 8: ESO fetches the secret

ESO calls Secrets Manager with those credentials and gets the password.

Step 9: ESO creates the K8s Secret

ESO creates a normal Kubernetes Secret called database-secret. If someone
changes the password in AWS later, ESO notices on its next refresh and updates
it.

Step 10: The app reads the secret

The app's YAML just says "give me DB_PASSWORD from Secret database-secret,"
as an env variable or a file. The app has no IAM role, no AWS credentials, and
no idea AWS exists.

The picture to remember

Pod Identity Agent ──gives temp creds──► ESO pod
                                          │
                                          │ fetch
                                          ▼
                                   Secrets Manager
                                          │
                                          │ password
                                          ▼
                                    ESO creates
                                          │
                                          ▼
                                 K8s Secret (database-secret)
                                          │
                                          │ reads
                                          ▼
                                       App pod

The whole thing in one line

Install ESO and the Pod Identity Agent → give ESO an AWS role through a Pod
Identity association → tell ESO where to look (SecretStore) and what to fetch
(ExternalSecret) → ESO copies the secret into a K8s Secret → the app reads it.

The analogy

Secrets Manager is a bank vault. ESO is a courier we hire (Step 1). The Pod
Identity Agent is the office that issues ID cards (Step 2). The IAM role is the
permission slip that says what the courier can pick up (Step 3), and the
association assigns that slip to our courier (Step 4). We tell the courier
which bank (SecretStore) and which box (ExternalSecret). The courier picks up
the cash and puts it in a locker inside our building (the K8s Secret), and our
app just opens the locker.

Hands-on: step-by-step template

Goal: an app in EKS reads a secret from AWS Secrets Manager without having
any AWS credentials itself.

Prerequisites: a running EKS cluster, plus aws, kubectl, and helm
installed and configured.

Step 0: Set your variables

export CLUSTER_NAME=my-cluster
export AWS_REGION=eu-central-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

Step 1: Create a secret in AWS Secrets Manager

This is the secret our app needs.

aws secretsmanager create-secret \
  --name my-app/database \
  --region $AWS_REGION \
  --secret-string '{"username":"admin","password":"S3cr3t!"}'

Step 2: Install ESO (the courier)

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

helm install external-secrets external-secrets/external-secrets \
  --namespace external-secrets \
  --create-namespace

This creates the ESO pods and a ServiceAccount named external-secrets.

Step 3: Install the Pod Identity Agent (the ID card office)

aws eks create-addon \
  --cluster-name $CLUSTER_NAME \
  --addon-name eks-pod-identity-agent

Check that it's running on every node:

kubectl get daemonset eks-pod-identity-agent -n kube-system

Step 4: Create an IAM role for ESO (the permission slip)

Trust policy: lets EKS Pod Identity hand this role to pods.

cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "pods.eks.amazonaws.com" },
      "Action": ["sts:AssumeRole", "sts:TagSession"]
    }
  ]
}
EOF

aws iam create-role \
  --role-name ESO-Secrets-Reader \
  --assume-role-policy-document file://trust-policy.json

Permissions policy: allows reading only our app's secrets.

cat > permissions-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:${AWS_REGION}:${ACCOUNT_ID}:secret:my-app/*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name ESO-Secrets-Reader \
  --policy-name read-my-app-secrets \
  --policy-document file://permissions-policy.json

If your secret is encrypted with a custom KMS key instead of the AWS default,
also allow kms:Decrypt on that key.

Step 5: Connect the role to ESO's ServiceAccount (give the courier the slip)

aws eks create-pod-identity-association \
  --cluster-name $CLUSTER_NAME \
  --namespace external-secrets \
  --service-account external-secrets \
  --role-arn arn:aws:iam::${ACCOUNT_ID}:role/ESO-Secrets-Reader

Then restart ESO so its pods pick up the new identity. Pods only get the
credential wiring when they start.

kubectl rollout restart deployment -n external-secrets

Step 6: Tell ESO where to look (ClusterSecretStore)

# cluster-secret-store.yaml
apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: aws-secrets-manager
spec:
  provider:
    aws:
      service: SecretsManager
      region: eu-central-1   # change to your region

There's no auth section and no access keys. ESO automatically uses the
credentials Pod Identity gives it.

kubectl apply -f cluster-secret-store.yaml

If you're on an older ESO version, use external-secrets.io/v1beta1 instead of
v1.

Step 7: Tell ESO what to fetch (ExternalSecret)

# external-secret.yaml
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: database-secret
  namespace: my-app
spec:
  refreshInterval: 1h            # how often ESO checks AWS for changes
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: database-secret        # the K8s Secret ESO will create
  data:
    - secretKey: username        # key name inside the K8s Secret
      remoteRef:
        key: my-app/database     # secret name in AWS
        property: username       # JSON field inside it
    - secretKey: password
      remoteRef:
        key: my-app/database
        property: password

kubectl create namespace my-app
kubectl apply -f external-secret.yaml

Step 8: The app reads the K8s Secret (opens the locker)

# app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: busybox
          command: ["sh", "-c", "echo App started; sleep 3600"]
          env:
            - name: DB_USERNAME
              valueFrom:
                secretKeyRef:
                  name: database-secret
                  key: username
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: database-secret
                  key: password

kubectl apply -f app.yaml

The app has no IAM role and no AWS credentials. It just reads a normal K8s
Secret.

Step 9: Verify it works

# 1. Did ESO sync the secret? Look for STATUS = SecretSynced, READY = True
kubectl get externalsecret -n my-app

# 2. Does the K8s Secret exist with the right value?
kubectl get secret database-secret -n my-app \
  -o jsonpath='{.data.password}' | base64 -d

# 3. Does the app see it?
kubectl exec -n my-app deploy/my-app -- printenv DB_USERNAME

Troubleshooting

ExternalSecret shows AccessDenied: check the association exists (aws eks list-pod-identity-associations --cluster-name $CLUSTER_NAME), confirm the namespace and ServiceAccount names match exactly, and restart the ESO pods.
ResourceNotFound: the secret name or region in AWS doesn't match remoteRef.key or the store's region.
Secret changed in AWS but the app still has the old value: ESO updated the K8s Secret, but env vars are only read when a pod starts. Restart the app, mount the secret as a volume instead, or use a tool like Reloader to restart pods automatically.

Cleanup

kubectl delete namespace my-app
helm uninstall external-secrets -n external-secrets
aws eks delete-pod-identity-association --cluster-name $CLUSTER_NAME \
  --association-id <id-from-list-command>
aws iam delete-role-policy --role-name ESO-Secrets-Reader --policy-name read-my-app-secrets
aws iam delete-role --role-name ESO-Secrets-Reader
aws secretsmanager delete-secret --secret-id my-app/database --force-delete-without-recovery

originally published at https://github.com/nazmur96/devops-sre-authentication/blob/main/posts/eso-eks-pod-identity.md

HD-101 — The first pull request

MysticMc — Tue, 25 Aug 2026 14:08:50 +0000

HD-101 — The first pull request

Builds: nothing. Teaches: why the next six tickets exist.

The ticket

Add a feature to the helpdesk CLI. Don't push to main — open a pull request.

What you do

git switch -c hd-101-priority-filter
# ... write the code ...
git add -A
git commit -m "feat: filter tickets by priority"
git push -u origin hd-101-priority-filter

gh pr create --base main --head hd-101-priority-filter \
  --title "HD-101: filter tickets by priority" \
  --body "Adds --priority to the list command."

Then merge it.

What actually happened

The PR merged. Green tick, satisfying. And nothing had checked anything.

There were no tests running, no required reviewers, no status checks. The PR was a
change of scenery, not a gate. Anyone could have merged anything.

That is the entire point of this ticket. You are supposed to feel how empty it is.

The two words that cause the most confusion

Every PR has a base and a head:

Word	Means
base	Destination. Where the code lands.
head	Source. Where the code comes from.

--base main --head hd-101-priority-filter reads: this branch ends up in main.

Get these backwards and you will open a PR proposing to merge main into your
feature branch, which looks almost right and is completely wrong. It happens to
everyone at least once. It happened here — see mistakes.md.

Also: a PR's head has nothing to do with git's HEAD pointer. Same word,
unrelated meanings. Git's HEAD is "where I am standing right now"; a PR's head is
"the branch being proposed".

What to look at before moving on

Open the merged PR and look at the checks section. It's empty. Remember that.

Next: HD-102 — Continuous integration

originally published at https://github.com/nazmur96/git-promotion-ladder/blob/main/docs/hd-101-first-pull-request.md

5 Docker Scenarios Every Developer Should Practice (With Fixes & Best Practices)

MysticMc — Tue, 21 Apr 2026 20:56:35 +0000

So you know the basics of Docker — docker run, docker build, maybe some docker compose up. But do you know what happens when things break?

This guide walks you through 5 real-world Docker scenarios that will sharpen your skills around debugging, security, storage, and production-readiness.

Scenario 1: The Broken Build 🔨

Goal

Fix a broken Dockerfile, then optimize it to be 10x smaller and production-ready.

Setup

app.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello():
    return "Hello from Docker!"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

requirements.txt

Flask==2.3.0

❌ The Broken Dockerfile

FROM ubuntu:latest

RUN apt-get update
RUN apt-get install python3

COPY . /opt/app
RUN pip install -r requirements.txt

USER root

CMD python /opt/app/app.py

Tasks

1. Troubleshoot the Build

Run:

docker build -t broken-app .

There are at least 3 issues hiding in that Dockerfile:

pip is never installed
apt-get install is missing the -y flag (hangs waiting for input)
COPY happens before dependency install — busting the cache on every change

2. Fix Layer Caching

Copy requirements.txt first, install deps, then copy the rest of the app. This way, changing app.py won't trigger a full pip install on every build.

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . /opt/app

3. Optimize the Image

Switch from ubuntu:latest to a slim base:

FROM python:3.12-slim

WORKDIR /opt/app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 5000
CMD ["python", "app.py"]

Target: < 150MB image size ✅

4. Security Hardening

# Run as non-root
USER 1001

Run with a read-only filesystem:

docker run --read-only --tmpfs /tmp myapp:latest

Scenario 2: The Ghost Data 👻

Goal

Understand Docker's storage lifecycle and how to make data actually persist.

Tasks

1. Run an Ephemeral Container

docker run -d --name web-test -p 8080:80 nginx

2. Write Data Inside the Container

docker exec -it web-test bash
echo "hello" > /usr/share/nginx/html/test.txt

Visit http://localhost:8080/test.txt — it's there!

3. Destroy & Recreate

docker stop web-test
docker rm web-test
docker run -d --name web-test2 -p 8080:80 nginx

The file is gone. Why?

Because the container filesystem is ephemeral — it only lives as long as the container does.

4. Named Volume Persistence

docker volume create web-data

docker run -d \
  --name web-test \
  -p 8080:80 \
  -v web-data:/usr/share/nginx/html \
  nginx

5. Verify Persistence

docker exec -it web-test bash
echo "persistent data" > /usr/share/nginx/html/test.txt

Stop and remove the container, then start a new one with the same volume — your file will still be there. 🎉

6. Cleanup

docker system prune -f

Note: system prune removes stopped containers, dangling images, and unused networks — but not named volumes unless you add --volumes.

Scenario 3: The Flaky Database Connection 🐘

Goal

Fix service startup dependency issues in Docker Compose.

The Broken `docker-compose.yml`

version: '3'

services:
  web:
    build: .
    ports:
      - "5000:5000"
    environment:
      - DB_HOST=postgres
    depends_on:
      - postgres

  postgres:
    image: postgres:15
    environment:
      - POSTGRES_PASSWORD=secret

Tasks

1. Run the Stack

docker compose up

The problem: depends_on only waits for the container to start, not for Postgres to be ready to accept connections. Your web app crashes on startup.

2. Add a Healthcheck to Postgres

postgres:
  image: postgres:15
  environment:
    - POSTGRES_PASSWORD=secret
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U postgres"]
    interval: 5s
    timeout: 5s
    retries: 10

3. Fix `depends_on` with a Condition

web:
  depends_on:
    postgres:
      condition: service_healthy

Now your web service won't start until Postgres passes its healthcheck. ✅

4. Move Secrets to `.env`

.env

POSTGRES_PASSWORD=secret

docker-compose.yml

environment:
  - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

5. Keep Secrets Out of Git

.gitignore

.env

Never commit .env files. Ever.

Scenario 4: The Evil Image Scanner 🔍

Goal

Find and fix vulnerabilities hiding in your Docker images.

Tasks

1. Build a Vulnerable Image

FROM nginx:1.21.0

2. Install Trivy

brew install aquasecurity/trivy/trivy

Or on Linux:

curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

3. Scan the Image

trivy image nginx:1.21.0

You'll see a wall of HIGH and CRITICAL CVEs. This is what ships to production when nobody checks.

4. Fix the Base Image

FROM nginx:1.25-bookworm

Or go even lighter:

FROM nginx:alpine

5. Rescan

trivy image nginx:1.25-bookworm

Expected: 0 CRITICAL vulnerabilities ✅

Make image scanning part of your CI/CD pipeline — not an afterthought.

Scenario 5: The Limited Resource Box 📦

Goal

Run containers safely under strict resource constraints and enable offline portability.

Tasks

1. Build the Optimized Image

Use the hardened image from Scenario 1.

2. Run with Resource Limits

docker run -d \
  --memory=256m \
  --cpus=0.5 \
  --read-only \
  --tmpfs /tmp \
  myapp:latest

Flag	What it does
`--memory=256m`	Hard cap on RAM usage
`--cpus=0.5`	Limits to half a CPU core
`--read-only`	Prevents filesystem writes
`--tmpfs /tmp`	Mounts writable in-memory temp dir

3. Verify the Restrictions

docker exec -it <container_id> bash
touch /etc/test
# Permission denied ✅

Monitor resource usage live:

docker stats

4. Export the Image

docker save -o myapp.tar myapp:latest

5. Simulate an Offline Machine

docker rmi myapp:latest

6. Restore the Image

docker load -i myapp.tar

7. Run Without Internet

docker run myapp:latest

Works fully offline. 🚀 Great for air-gapped environments, demos, or CI runners without registry access.

What You've Learned 🎓

After completing all five scenarios, you now have hands-on experience with:

✅ Dockerfile debugging & optimization — fixing real build errors and shrinking image sizes
✅ Layer caching strategies — speeding up builds without reinstalling dependencies
✅ Volume persistence — understanding ephemeral vs. persistent storage
✅ Compose healthchecks — preventing race conditions between services
✅ Image vulnerability scanning — catching CVEs before they reach production
✅ Runtime security hardening — non-root users, read-only filesystems, resource limits
✅ Offline container portability — shipping containers without a registry

Want more? Drop a comment and I can turn this into a full GitHub repo with solutions, or expand each scenario into its own deep-dive post.

⚙️ My first CI/CD pipeline: From git push to production in 10 minutes

MysticMc — Thu, 02 Apr 2026 19:45:56 +0000

Remember the old days?

You write code. You test it manually (maybe). You open FileZilla. You drag and drop files to a server. You pray.

Then someone yells: "Who deployed on a Friday?!"

Those days are dead.

CI/CD pipelines are the reason modern developers ship code 10x faster with 90% fewer bugs. And the best part? You can set one up in 10 minutes. For free.

Let me show you.

What is CI/CD? (The 30-second explanation)

CI = Continuous Integration – Every time you push code, automatically test it.

CD = Continuous Delivery/Deployment – If tests pass, automatically deploy it.

In practice:

git push origin main
   ↓
[Automatic] Run tests
   ↓
[Automatic] Build the app
   ↓
[Automatic] Deploy to server
   ↓
You get a notification: "✅ Deployment successful"

You never touch a server. You never run scp or FTP. You just push code.

The 10-Minute Challenge

By the end of this guide, you will have:

· A simple Node.js/Express app (or your own project)
· A GitHub repository
· A GitHub Actions workflow that:
· Runs tests automatically
· Deploys to a free hosting service (Render.com – no credit card)

Total time: ~10 minutes. I'll wait.

What You'll Need (All Free)

Tool Why
GitHub account Hosts your code + runs CI/CD
Render.com account Free hosting (similar to Heroku)
A simple app We'll make one in 2 minutes

No credit card required. No servers to manage.

Step 1: The App (2 minutes)

Create a new folder and a simple Express app:

mkdir my-cicd-app
cd my-cicd-app
npm init -y
npm install express

Create index.js:

const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

app.get('/', (req, res) => {
  res.json({ message: 'CI/CD works! 🚀' });
});

app.get('/health', (req, res) => {
  res.status(200).send('OK');
});

// A simple test endpoint
app.get('/add/:a/:b', (req, res) => {
  const a = parseInt(req.params.a);
  const b = parseInt(req.params.b);
  res.json({ result: a + b });
});

app.listen(PORT, () => {
  console.log(`App running on port ${PORT}`);
});

Create a test file test.js (we'll use Node's built-in assert):

const assert = require('assert');

// Simple tests that will run in CI
console.log('Running tests...');

// Test 1: Addition works
function add(a, b) { return a + b; }
assert.strictEqual(add(2, 3), 5);
console.log('✅ Test 1 passed');

// Test 2: String test
assert.strictEqual(typeof 'hello', 'string');
console.log('✅ Test 2 passed');

console.log('🎉 All tests passed!');

Update package.json with a test script:

{
  "scripts": {
    "start": "node index.js",
    "test": "node test.js"
  }
}

Test it locally:

npm test          # Should show "All tests passed!"
npm start         # Visit http://localhost:3000

Step 2: Push to GitHub (2 minutes)

Create a repository on GitHub (don't initialize with README – we have our own).

git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/YOUR_USERNAME/my-cicd-app.git
git branch -M main
git push -u origin main

Step 3: Create the CI/CD Pipeline (3 minutes)

This is where the magic happens. GitHub Actions reads a file in .github/workflows/ and runs it.

Create this folder and file:

mkdir -p .github/workflows

Create .github/workflows/deploy.yml:

name: Deploy to Production

# When should this run?
on:
  push:
    branches: [ main ]  # Every push to main branch
  workflow_dispatch:    # Also allow manual trigger

# What environment variables do we need?
env:
  NODE_VERSION: '18'

# Jobs run in parallel by default
jobs:
  # JOB 1: Test
  test:
    name: Run Tests
    runs-on: ubuntu-latest  # Free Linux runner

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}

      - name: Install dependencies
        run: npm ci  # ci is faster and stricter than install

      - name: Run tests
        run: npm test

  # JOB 2: Deploy (only if tests passed)
  deploy:
    name: Deploy to Render
    runs-on: ubuntu-latest
    needs: test  # Wait for test job to succeed

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to Render
        uses: johnbeynon/render-deploy-action@v1
        with:
          service-id: ${{ secrets.RENDER_SERVICE_ID }}
          api-key: ${{ secrets.RENDER_API_KEY }}

What this does:

On every git push to main:
Spin up a fresh Linux machine (free)
Run npm test
If tests pass → deploy to Render
If tests fail → stop (no deploy)

Step 4: Hosting on Render (3 minutes)

Render is like the old Heroku (but with a free tier that actually works).

Go to render.com and sign up with GitHub.
Click "New +" → "Web Service"
Connect your GitHub repository (my-cicd-app)
Fill in the settings: · Name: my-cicd-app · Environment: Node · Build Command: npm install · Start Command: npm start · Plan: Free
Click "Create Web Service"

Render will deploy your app once manually. Wait for the green "Live" badge.

You'll get a URL like: https://my-cicd-app.onrender.com

Visit it. You should see your JSON message.

Step 5: Connect GitHub Actions to Render (2 minutes)

Now we need to give GitHub Actions permission to deploy to Render.

Get your Render API Key:

Go to Render Dashboard → Account Settings (top right)
Scroll to "API Keys" → Click "Create API Key"
Name it github-actions → Copy the key (starts with rnd_)

Get your Render Service ID:

Go to your Web Service page on Render
Look at the URL: https://dashboard.render.com/web/srv-abc123def
The srv-abc123def part is your Service ID

Add them as GitHub Secrets:

Go to your GitHub repository → Settings → Secrets and variables → Actions
Click "New repository secret"
Add RENDER_API_KEY → paste your API key
Add RENDER_SERVICE_ID → paste your Service ID

Step 6: Trigger Your First Pipeline (1 minute)

Make a small change to trigger the pipeline:

# Change the message in index.js
res.json({ message: 'My first CI/CD pipeline! 🎉' });

# Commit and push
git add .
git commit -m "Test CI/CD pipeline"
git push origin main

Now go to your GitHub repository → Actions tab.

You'll see a workflow running:

Deploy to Production
  ├── Run Tests (yellow → green)
  └── Deploy to Render (yellow → green)

When both turn green ✅, visit your Render URL. Your new message is live.

You just did CI/CD. 🚀

What Just Happened? (The Diagram)

Your laptop
    │
    │ git push origin main
    ▼
GitHub (Actions)
    │
    │ Spins up runner
    ▼
┌─────────────────────────────────────┐
│  CI Pipeline (Test)                 │
│  ├── npm ci                         │
│  ├── npm test                       │
│  └── ✅ All tests passed            │
└─────────────────────────────────────┘
    │
    │ Tests pass → trigger CD
    ▼
┌─────────────────────────────────────┐
│  CD Pipeline (Deploy)               │
│  ├── Call Render API                │
│  ├── Render pulls code              │
│  ├── npm install                    │
│  ├── npm start                      │
│  └── ✅ Live at your URL            │
└─────────────────────────────────────┘
    │
    ▼
Production server (Render)

Common Variations (Adapt to Your Stack)

For a Python (Django/Flask) app:

# .github/workflows/deploy.yml
- name: Setup Python
  uses: actions/setup-python@v4
  with:
    python-version: '3.11'

- name: Install dependencies
  run: |
    pip install -r requirements.txt
    pip install pytest

- name: Run tests
  run: pytest

- name: Deploy
  run: |
    # Render handles Python automatically
    # Or use: flyctl deploy, railway up, etc.

For a React/Vite static site:

- name: Install dependencies
  run: npm ci

- name: Build
  run: npm run build

- name: Deploy to Netlify
  uses: nwtgck/actions-netlify@v2
  with:
    publish-dir: './dist'
    production-branch: main
  env:
    NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_TOKEN }}
    NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

For a Docker container:

- name: Build Docker image
  run: docker build -t myapp .

- name: Push to Docker Hub
  run: |
    echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
    docker push myusername/myapp:latest

- name: Deploy to DigitalOcean
  uses: appleboy/ssh-action@v1
  with:
    host: ${{ secrets.HOST }}
    username: ${{ secrets.USERNAME }}
    key: ${{ secrets.SSH_KEY }}
    script: docker pull myusername/myapp && docker-compose up -d

Pro Tips (From Someone Who Broke Production)

Always test before deploying (duh)

The needs: test line ensures you never deploy broken code. Add a failing test and watch the pipeline stop.

// Add this to test.js – it will FAIL
assert.strictEqual(1, 2);
console.log('This line never runs');

Push it. Watch the pipeline fail at the test stage. Deploy never happens. You just saved production.

Use npm ci instead of npm install

· npm install can update package-lock.json (unexpected changes)
· npm ci installs exactly what's in package-lock.json (reproducible builds)

Always use npm ci in CI.

Add a "staging" environment

For real projects, deploy to staging first:

on:
  push:
    branches: [ main ]     # Deploys to staging
    branches: [ production ] # Deploys to production

Add notifications

Get a Slack/Discord message when deploy finishes:

- name: Send Slack notification
  uses: slackapi/slack-github-action@v1
  with:
    payload: |
      {
        "text": "✅ Deployed to production!"
      }
  env:
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

Manual approval for production (for serious teams)

deploy-prod:
  needs: test
  environment: production  # Requires approval in GitHub
  runs-on: ubuntu-latest
  steps:
    - name: Deploy to production
      run: ./deploy.sh

Then go to GitHub → Settings → Environments → Add protection rule.

Troubleshooting (When Things Go Wrong)

Symptom Most likely fix
Workflow doesn't trigger Check branch name: main vs master
Tests fail but work locally Different Node version? Add .nvmrc file
Deploy step fails Wrong Render Service ID or API key
"Module not found" Forgot npm ci step?
"Permission denied" GitHub Actions needs write permissions → Settings → Actions → General → Workflow permissions

What You Just Learned

✅ CI = Automatic testing on every push
✅ CD = Automatic deployment if tests pass
✅ GitHub Actions = Free CI/CD runners
✅ Render = Free hosting with API deploys
✅ Secrets = Store API keys safely

You can now add CI/CD to any project in ~10 minutes.

Next Steps (Level Up)

Add more tests – Unit tests, integration tests
Add a database – Render has free PostgreSQL
Add a staging environment – Deploy to staging first, then production
Add end-to-end tests – Cypress or Playwright
Try other platforms – Vercel, Netlify, Railway, Fly.io

The Ultimate Test

Break something on purpose:

// Add this to index.js – a hidden bug
app.get('/broken', (req, res) => {
  throw new Error('Oops');  // This will crash the server
});

Push it. Watch the pipeline deploy it (tests passed, right?). Then visit /broken and watch it fail.

Now fix it. Push again. Watch the pipeline fix production automatically.

That's the power of CI/CD. You're not afraid to deploy anymore. Because if something breaks, you fix it and push again. No panic. No Friday deploys. Just code.

Your 10-Minute Challenge Recap

· Created an Express app
· Pushed to GitHub
· Created .github/workflows/deploy.yml
· Signed up for Render
· Added API keys as GitHub Secrets
· Made a change and watched the pipeline run

You did it. 🎉

Now go add CI/CD to your real project. Your future self (and your team) will thank you.

What stack do you want to see a CI/CD example for next? Drop a comment (Django, Spring Boot, Next.js, Go, Rust...).

Follow for more DevOps-for-beginners content.

🚪 Authentication vs. Authorization – The Bouncer Analogy (Clear up the confusion forever)

MysticMc — Thu, 02 Apr 2026 19:36:53 +0000

I can't tell you how many times I've seen these two words used interchangeably.

Even experienced developers sometimes slip up:

"We need to add Google Auth so users can authorize with their email."

No. That's authentication.

"The JWT token authenticates whether the user is an admin."

No. That's authorization.

They sound similar. They work together. But they are not the same thing.

And mixing them up leads to security holes, confused code, and embarrassing bugs.

Here's the one analogy that makes it stick forever.

The Bouncer Analogy 🚪

Imagine you're at a nightclub.

Step 1: Authentication (Getting past the front door)

You walk up to the bouncer. He asks:

"Do you have an ID?"

You show your driver's license. He checks the photo. He scans it. He confirms:

"Okay, you are who you say you are. You're on the guest list. Come in."

That's authentication. You proved your identity. You're in the club.

Authentication answers: "Are you who you claim to be?"

Step 2: Authorization (Getting into VIP)

Now you're inside the club. You see the VIP section – better drinks, better view, actual seats that aren't sticky.

You try to walk in. Another bouncer stops you:

"Whoa there. This is VIP. Do you have a wristband?"

You show your black wristband (which you paid $500 for). He checks it and says:

"Cool. You're authorized. Go ahead."

That's authorization. Your identity is already confirmed. Now we're checking what you're allowed to do.

Authorization answers: "Are you allowed to do this specific thing?"

The Table That Finally Makes It Click

Authentication Authorization
Question it answers "Who are you?" "What can you do?"
When it happens First (at login) After (on each request)
What it proves Identity Permissions
How it works Passwords, biometrics, security keys Roles, permissions, policies
Tells you "You are Bob" "Bob can delete posts"
Bouncer analogy Checking your ID at the door Checking your VIP wristband
HTTP Status Code 401 Unauthorized (ironically named) 403 Forbidden

Side note: Yes, HTTP 401 says "Unauthorized" but actually means "unauthenticated." It's a historical mistake that confuses everyone. Just remember: 401 = Login first. 403 = You're logged in but not allowed.

Real Web Examples

Example 1: Logging into Gmail

Authentication: You type your email + password. Google checks it's really you. (Success → you get a session cookie or JWT token)
Authorization: You try to delete an email. Google checks: "Does this user have 'delete' permission for this email?" (Yes, it's your own email)

Same user, same login, but authorization happens on every single action.

Example 2: Google Drive sharing

· Authentication: You log into your Google account.
· Authorization: You try to open a shared document. Google checks: "Is this user on the 'can view' list?" If yes → authorized. If no → 403 error.

You are authenticated (Google knows it's you), but not authorized (you don't own that doc).

Example 3: Admin dashboard

// Authentication: Did the user log in?
if (!req.user) {
  return res.status(401).json({ error: "Please log in first" });
}

// Authorization: Is the logged-in user an admin?
if (req.user.role !== "admin") {
  return res.status(403).json({ error: "Admins only" });
}

// If we reach here, user is BOTH authenticated AND authorized
res.send("Welcome to the admin panel");

See the difference? Two checks, two different purposes.

The Technologies (What actually powers authN and authZ)

Now let's connect the theory to the actual code you'll write.

Authentication Technologies (Proving who you are)

Technology What it does When to use
Passwords + Hash (bcrypt) User provides secret; you compare hashed version Most apps (standard)
JWT (JSON Web Token) Encoded token containing user ID + signature Stateless APIs, mobile apps
Sessions (with cookies) Server stores user data; cookie acts as key Traditional web apps (Rails, PHP, Node with express-session)
OAuth 2.0 "Login with Google/GitHub/Facebook" Letting third parties prove identity
Biometrics Fingerprint, FaceID, passkeys Mobile apps, high-security
2FA / MFA Password + one-time code from phone Any app with sensitive data

Authentication result: You get a credential (session cookie, JWT token, API key) that you send with every subsequent request.

Authorization Technologies (What you're allowed to do)

Technology What it does When to use
RBAC (Role-Based Access Control) Users have roles (admin, editor, viewer); roles have permissions Most business apps (simplest)
ABAC (Attribute-Based Access Control) Permissions based on attributes (time of day, user location, resource owner) Complex systems (healthcare, finance)
ACL (Access Control Lists) Each resource has a list of who can access it File systems, legacy apps
Policies (Casbin, OPA) Declarative rules: "user can edit post if user.id == post.authorId" Fine-grained permissions

Authorization result: A yes/no answer for each action. No tokens. Just logic.

The Confusion: JWT, Sessions, Cookies, localStorage

This is where beginners get lost. Let me untangle it.

What stores your authentication state?

After you log in, you need to remember that you're authenticated for future requests.

Option 1: Sessions (Server-side)

1. You log in.
2. Server creates a session record in its database (or Redis).
3. Server sends you a cookie containing a session ID.
4. You send that cookie with every request.
5. Server looks up the session ID to know who you are.

Option 2: JWT (Client-side)

1. You log in.
2. Server creates a JWT token (contains your user ID, expiration, signature).
3. Server sends you the token.
4. You store it in localStorage or an HTTP-only cookie.
5. You send the token in the Authorization header with every request.
6. Server verifies the signature (no database lookup needed).

Which one should you use?

Sessions JWT
Where is data stored? Server (database/Redis) Client (token itself)
Can you revoke instantly? ✅ Yes (delete session from DB) ❌ No (token valid until expiration)
Scales how? Need shared session store (Redis) Stateless (any server can verify)
Best for... Traditional web apps Mobile apps, microservices, SPAs

My advice for beginners: Start with sessions + HTTP-only cookies. It's simpler and more secure by default. Move to JWT only when you have a reason (e.g., mobile app, separate API server).

localStorage vs. cookies (Security warning!)

This is critical.

Storage method Accessible by JavaScript? Vulnerable to XSS? HttpOnly option?
localStorage ✅ Yes (any script can read it) ❌ Yes (high risk) ❌ No
Regular cookie ✅ Yes ❌ Yes ❌ No
HttpOnly cookie ❌ No (JS cannot read it) ✅ No (much safer) ✅ Yes

Rule of thumb:

· Never store authentication tokens in localStorage if you care about security. Any XSS vulnerability = attacker steals every user's token.
· Use HttpOnly cookies for sessions or JWTs. They can't be read by JavaScript.

// BAD (vulnerable to XSS)
localStorage.setItem("token", userJWT);

// GOOD (more secure)
// Set cookie on server with:
Set-Cookie: token=xyz; HttpOnly; Secure; SameSite=Strict

OAuth 2.0 – The special case

OAuth is often called "authentication," but that's not quite right.

OAuth is actually authorization that implies authentication.

Here's how it works:

You click "Login with Google."
Google asks: "This app wants to see your email and name. Allow?"
You say yes.
Google tells your app: "This user is bob@gmail.com" (authentication info) AND "Here's a token to access their Google Drive" (authorization).

OAuth solves: "Let me prove who I am without giving you my password, and also let me give you limited access to my data."

Common confusion: People call OAuth "social login" (authentication), but OAuth was designed for delegated authorization (like "let this app post to my Twitter"). The login part is a bonus.

Common Real-World Scenarios

Scenario 1: You're logged into Netflix but can't watch a specific movie

· Authentication: ✅ You logged in. Netflix knows it's you.
· Authorization: ❌ Your plan doesn't include that movie (or it's region-locked).

Error message: "This title is not available in your region." (403 Forbidden)

Scenario 2: You try to delete a comment on Reddit that isn't yours

· Authentication: ✅ You're logged in.
· Authorization: ❌ You didn't write that comment.

Error message: "You cannot delete this comment." (403)

Scenario 3: You open a private GitHub repo without logging in

· Authentication: ❌ GitHub has no idea who you are.
· Authorization: ⏸️ Not even checked because you're not authenticated.

Error message: "Not Found" (404 – GitHub does this on purpose to hide private repos exist). But technically it's a 401.

The 5-Minute Implementation (Node.js + Express)

Here's a minimal example showing both concepts:

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

// Fake database
const users = [
  { id: 1, email: 'alice@example.com', password: 'alice123', role: 'admin' },
  { id: 2, email: 'bob@example.com', password: 'bob123', role: 'viewer' }
];

const posts = [
  { id: 1, title: 'Post 1', authorId: 1 },
  { id: 2, title: 'Post 2', authorId: 2 }
];

// ---------- AUTHENTICATION ----------
// Login endpoint – proves who you are
app.post('/login', (req, res) => {
  const { email, password } = req.body;
  const user = users.find(u => u.email === email && u.password === password);

  if (!user) {
    return res.status(401).json({ error: 'Invalid credentials' }); // 401 = unauthenticated
  }

  // Create a session (in real life, use express-session)
  req.session.userId = user.id;
  res.json({ message: 'Logged in!' });
});

// Check authentication middleware
function isAuthenticated(req, res, next) {
  if (!req.session.userId) {
    return res.status(401).json({ error: 'Please log in first' });
  }
  next();
}

// ---------- AUTHORIZATION ----------
// Check authorization middleware (role-based)
function isAdmin(req, res, next) {
  const user = users.find(u => u.id === req.session.userId);
  if (user.role !== 'admin') {
    return res.status(403).json({ error: 'Admins only' }); // 403 = forbidden
  }
  next();
}

// Check authorization (ownership)
function isOwner(req, res, next) {
  const postId = parseInt(req.params.id);
  const post = posts.find(p => p.id === postId);
  const user = users.find(u => u.id === req.session.userId);

  if (post.authorId !== user.id && user.role !== 'admin') {
    return res.status(403).json({ error: 'You can only edit your own posts' });
  }
  next();
}

// ---------- ROUTES ----------
// Anyone can view (no authentication needed)
app.get('/posts', (req, res) => {
  res.json(posts);
});

// Authenticated only (any logged-in user)
app.post('/posts', isAuthenticated, (req, res) => {
  // Create a new post
  res.json({ message: 'Post created' });
});

// Authorization: must be admin OR owner
app.put('/posts/:id', isAuthenticated, isOwner, (req, res) => {
  res.json({ message: 'Post updated' });
});

// Authorization: admin only
app.delete('/posts/:id', isAuthenticated, isAdmin, (req, res) => {
  res.json({ message: 'Post deleted' });
});

See the pattern?

Authentication happens first (isAuthenticated).
Authorization happens second (isAdmin, isOwner).
You can be authenticated but not authorized (403).
You can be neither (401).

The Security Checklist

When building auth, use this mental checklist:

Question Check
Are passwords hashed with bcrypt (not plain text)? ☐
Is HTTPS enabled everywhere? ☐
Are session cookies marked HttpOnly + Secure? ☐
Do you have rate limiting on login attempts? ☐
Does every protected endpoint check authentication FIRST? ☐
Does every sensitive endpoint check authorization SECOND? ☐
Are you using the correct HTTP status codes (401 vs 403)? ☐
Are JWT tokens (if used) stored in HttpOnly cookies, not localStorage? ☐

Quick Reference Card (Save This)

┌─────────────────────────────────────────────────────────────┐
│  AUTHENTICATION                     AUTHORIZATION           │
│  "Who are you?"                     "What can you do?"      │
│                                                             │
│  First (login)                      After (every action)    │
│  Passwords, JWT, OAuth              Roles, permissions      │
│  HTTP 401 (Unauthorized)            HTTP 403 (Forbidden)    │
│                                                             │
│  Bouncer at the door 🚪             Bouncer at VIP 🎟️        │
│  "Show ID"                           "Show wristband"       │
└─────────────────────────────────────────────────────────────┘

Your Turn

Go check your own code (or a project you're working on):

Do you have endpoints that check authentication?
Do you have separate checks for authorization?
Are you using 401 vs 403 correctly?
Are your tokens in localStorage? (Move them if yes!)

Leave a comment with your biggest "aha moment" or your worst auth-related bug story.

Follow for more security deep dives (next up: JWT vs. Sessions – which one actually wins?)

TL;DR: Authentication = proving you're you (login). Authorization = proving you're allowed to do the thing (permissions). One happens first, one happens on every request. Mix them up and hackers win.

The 80/20 Rule for Learning Any New Technology (Stop Reading Manuals)

MysticMc — Thu, 02 Apr 2026 19:22:45 +0000

I've seen the same pattern repeat itself for over a decade.

A junior engineer gets assigned a new tech stack – let's say React, or Docker, or Rust. Their first instinct?

They buy a 700-page book. Or start a 40-hour video course.

Two weeks later, they're burned out, confused, and still can't build anything.

Meanwhile, a senior engineer picks up the same technology and ships a working feature by Friday.

The difference isn't intelligence. It's not experience.

It's the 80/20 Rule.

What is the 80/20 Rule (Pareto Principle)?

The Pareto Principle says:

80% of the results come from 20% of the effort.

In learning any new technology:

· 20% of the features will be used 80% of the time.
· 80% of the documentation is edge cases, deprecated methods, or advanced optimizations you will never need as a beginner.

The trick is: Identify that 20% first. Learn it deeply. Ignore the rest until you actually need it.

The Wrong Way (What most beginners do)

Let's say you want to learn Docker.

❌ The 100% approach:

Read the entire Docker documentation (600+ pages).
Watch a 12-hour "Docker Masterclass" on YouTube.
Learn about every command: docker network, docker volume, docker swarm, docker stack.
Try to memorize all flags for docker run.
Give up when you hit "OverlayFS internals."

✅ The 80/20 approach:

Learn 5 commands: docker build, docker run, docker ps, docker stop, docker rm.
Understand 2 concepts: Dockerfile + image vs. container.
Build one thing: "Containerize my Node.js app."
Ship it. Learn docker-compose only when you need two containers.

Same technology. 90% less time. Actually shipping code.

The 80/20 Framework (4 Steps)

Step 1: Find the "Core 20%" before you write a single line

Ask three questions:

Question Example (Learning React)
What do I actually need to build? "A todo app with form inputs and a list"
What 3-5 concepts power 90% of that? Components, props, state, useEffect, JSX
What can I safely ignore for now? Context API, useReducer, memo, custom hooks, SSR

Research for 20 minutes, not 20 hours. Skim the table of contents. Look at 3 "Getting Started" tutorials. Spot the overlap. That overlap is your 20%.

Step 2: Build a "Vertical Slice" immediately

Don't learn horizontally (all about X). Learn vertically (a tiny working thing).

Horizontal learning (bad):

Chapter 1: Variables
Chapter 2: Loops
Chapter 3: Functions
Chapter 4: Objects
... (2 weeks later) ... Chapter 12: Build a project

Vertical learning (good):

1. Write "Hello World" (5 min)
2. Add a button that changes text (10 min)
3. Add an input field (10 min)
4. Add a second page (20 min)
→ You now know 80% of what you need for basic apps.

The goal is not mastery. The goal is a working feedback loop.

Step 3: Learn just-in-time, not just-in-case

This is the biggest mindset shift.

Just-in-case (slow) Just-in-time (fast)
"I should learn all of Git before I start." "I'll learn git commit when I need to save."
"Let me read the entire SQL chapter on JOINs." "I have two tables. Let me Google 'SQL JOIN example'."
"I better understand Kubernetes architecture first." "My Docker container needs to scale. Time to learn pods."

Your brain remembers what it uses. If you learn it before you need it, you'll forget it. If you learn it because you need it, it sticks.

Step 4: Stop at "Good Enough" (for now)

Here's a secret senior devs know:

You don't need to be an expert. You need to be productive.

Define your "exit criteria" before you start:

· ✅ "I can build a CRUD app with authentication."
· ❌ "I understand every internal optimization."

When you hit your criteria, stop the tutorial. Start building your real project. You will learn the remaining 20% (the hard parts) when you break something in production at 2 AM. That's fine. That's real learning.

Real Examples: The 20% for Popular Technologies

Here's the cheat sheet you actually need.

Git (80% of what you'll ever do)

git add .
git commit -m "message"
git push origin main
git pull origin main
git clone <url>
git status
git log --oneline

Ignore: git rebase, git reflog, git bisect, git filter-branch

Docker (80% of daily work)

# Dockerfile basics
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["npm", "start"]

Commands: docker build, docker run, docker ps, docker stop, docker rm

Ignore: Docker Swarm, custom networks, volumes (until you need persistence)

React (80% of components)

// 1. Functional component
function MyComponent({ name }) {
  // 2. useState for local state
  const [count, setCount] = useState(0)

  // 3. useEffect for side effects
  useEffect(() => {
    document.title = `Clicked ${count} times`
  }, [count])

  // 4. JSX (HTML in JavaScript)
  return (
    <button onClick={() => setCount(count + 1)}>
      {name} clicked {count} times
    </button>
  )
}

Ignore: useReducer, useContext, custom hooks, memo, forwardRef, Portals

Python (for scripting/data)

# 1. Lists and dicts
my_list = [1, 2, 3]
my_dict = {"key": "value"}

# 2. Loops and conditionals
for item in my_list:
    if item > 1:
        print(item)

# 3. Functions
def my_function(param):
    return param * 2

# 4. List comprehensions
squares = [x**2 for x in range(10)]

# 5. Importing libraries
import pandas as pd

Ignore: Classes (for data work), decorators, async/await, metaclasses

SQL (for querying)

-- 1. SELECT with WHERE
SELECT name, email FROM users WHERE age > 18;

-- 2. JOIN (INNER is 90% of joins)
SELECT users.name, orders.total
FROM users
JOIN orders ON users.id = orders.user_id;

-- 3. GROUP BY with aggregation
SELECT department, COUNT(*), AVG(salary)
FROM employees
GROUP BY department;

-- 4. INSERT/UPDATE/DELETE
INSERT INTO users (name) VALUES ('Bob');
UPDATE users SET age = 30 WHERE name = 'Bob';
DELETE FROM users WHERE name = 'Bob';

Ignore: Window functions, triggers, stored procedures, indexing internals

Regular Expressions (just enough)

\d      # any digit (0-9)
\w      # any letter/number/underscore
.       # any character
+       # one or more
*       # zero or more
?       # zero or one
{3}     # exactly 3 times
[abc]   # a, b, or c
^       # start of string
$       # end of string

This covers 90% of regex needs. Ignore lookaheads, lookbehinds, backreferences.

The Anti-Patterns (What to avoid)

❌ Tutorial Hell

You finish 5 courses but can't build a project without hand-holding.

Fix: Delete the tutorial after 30 minutes. Try to build. Get stuck. Google the error. Repeat.

❌ The "Perfect Setup" Trap

You spend 3 days configuring your editor, themes, and dotfiles before writing code.

Fix: Use the default settings. Write code. Suffer a little. Then customize that one thing that hurts.

❌ Memorizing Syntax

You create flashcards for every function.

Fix: Use Google, ChatGPT, or man pages. Your brain is for patterns, not syntax. I've written Python for 10 years and still Google python list comprehension every single time.

❌ Reading Release Notes

You read "What's new in TypeScript 5.3" before you know TypeScript 1.0.

Fix: Ignore versions until you hit a specific limitation. Use the LTS (Long Term Support) and forget about it.

The 80/20 Learning Timeline (Example: Learning AWS in 1 week)

Day 80/20 Focus What you ignore
Day 1 Create an AWS account, launch an EC2 instance (virtual server) IAM roles, VPC networking, pricing calculators
Day 2 SSH into EC2, install Nginx, serve a "Hello World" page Load balancers, auto-scaling, security groups (beyond basics)
Day 3 Store a file in S3 (bucket + upload + public URL) S3 lifecycle policies, cross-region replication, Glacier
Day 4 Set up a database with RDS (Postgres), connect from EC2 Read replicas, performance insights, backup windows
Day 5 Deploy a simple Node.js app that uses S3 + RDS CloudFormation, Terraform, Lambda, API Gateway

Result: In 5 days, you can build a real app on AWS. You are not an expert. You don't need to be. You are productive.

The Mindset Shift (Read this twice)

Here's the truth most tutorials won't tell you:

You will never "finish" learning a technology.

There is no graduation day. There is no certificate that makes you an expert.

The goal is not to know everything.

The goal is to know enough to build what you want, and learn the rest when you need it.

The 80/20 rule isn't about being lazy. It's about being strategic. It's about recognizing that:

· 80% of the documentation is for edge cases you'll never hit.
· 80% of your time will be spent on 20% of the features.
· 80% of your learning should happen while building, not before.

Your 30-Minute Challenge

Right now, pick a technology you've been "meaning to learn" but avoiding.

Set a timer for 30 minutes.

Minutes 0-5: Find the official "Quickstart" or "Getting Started" guide. Skim it.
Minutes 5-10: Identify the 3-5 core commands/concepts. Write them down.
Minutes 10-25: Build the most minimal thing possible. "Hello World" is fine.
Minutes 25-30: Break it on purpose. Then fix it.

You will know more in 30 minutes than most people learn in 2 weeks of reading.

Now go break something. 🚀

TL;DR (The 80/20 of this article)

· Learn 20% of features that give you 80% of results.
· Build a tiny working thing before you understand it fully.
· Learn just-in-time, not just-in-case.
· Stop at "good enough for now" – mastery comes from real projects.
· Google is your memory. Don't memorize syntax.

What technology have you been avoiding? Do the 30-minute challenge right now and report back in the comments.

Follow for more pragmatic, no-fluff learning guides.

Git vs. GitHub: The 5-minute guide for absolute beginners

MysticMc — Thu, 02 Apr 2026 19:08:40 +0000

If you're new to coding, you've probably heard people say:

"Just push it to GitHub."

Or:

"Make sure you commit your changes."

And if you're like most beginners, you quietly nodded… while secretly thinking: "Wait… are Git and GitHub the same thing?"

You are not alone. This is the most common confusion for new developers.

Here's the truth in one sentence:

Git is the tool. GitHub is the website where you put the tool's work.

Let me explain in 5 minutes (or less).

The 2-Second Summary

	Git	GitHub
What is it?	A program on your computer	A website in the cloud
What does it do?	Tracks changes to your code	Hosts your Git repositories online
Do you need internet?	❌ No (works offline)	✅ Yes
Is it free?	✅ Yes (always)	✅ Yes for public repos (paid for private team features)
Who makes it?	Linus Torvalds (same guy who made Linux)	Microsoft (acquired in 2018)

The Analogy: Writing a Book 📚

Imagine you're writing a novel.

Git is your "Save & Track Changes" button (locally)

You write on your laptop. Every time you hit Save, Git takes a snapshot. You can:

Go back to page 37 from yesterday.
See exactly what words you deleted.
Try a crazy experiment (kill off the main character!) without losing the original.

All of this happens on your own computer. No internet required.

GitHub is the library (cloud hosting)

Now you want to:

Share your book with a co-author.
Show your progress to the world.
Make sure your laptop exploding doesn't erase 6 months of work.

So you upload your Git project to GitHub. It's like putting your book in a public library (or a private locker). Others can read it, suggest changes, or download their own copy.

This requires the internet.

What Git actually does (the 3 commands you need)

Git tracks your code using repositories (folders with a special .git hidden folder). Here's the basic workflow:

# 1. You change a file (index.html)
# 2. You stage it (tell Git "hey, pay attention to this")
git add index.html

# 3. You commit it (take a permanent snapshot)
git commit -m "Fixed the broken button"

# 4. Repeat 100 times. You now have 100 snapshots.

That's it. Git never touches the internet. It's just a smart "undo" button on steroids.

What GitHub actually does (the 3 things you need)

GitHub takes your local Git repository and:

Hosts it online – So you don't lose it if your computer dies.
Lets others collaborate – Multiple people can push changes to the same repo.
Adds project management tools – Issue tracking, pull requests, code reviews, CI/CD.

# After you've committed locally, you send it to GitHub:
git push origin main

# Now your code is on GitHub.com. Anyone can see it (if public).

Common beginner mistakes (and how to fix them)

❌ "I deleted my project folder. But I pushed to GitHub yesterday, so I'm safe!"

Not exactly. GitHub has your code, but you still need to git clone it back down. It's not magic. You have to explicitly download it.

✅ Fix: git clone https://github.com/yourname/yourrepo.git

❌ "I made changes on GitHub.com (edited a file in the browser) and now my local version is different."

This creates a merge conflict. GitHub has version A, your laptop has version B. Git doesn't know which is correct.

✅ Fix: git pull origin main before you start working. Always.

❌ "Git and GitHub are the same company, right?"

Nope. Git was created in 2005 by Linus Torvalds (Linux guy). GitHub launched in 2008 as a startup that built a website around Git. Microsoft bought GitHub for $7.5 billion in 2018.

Alternatives to GitHub:

GitLab (self-hosted option)
Bitbucket (Atlassian)
SourceForge (the old guard)

But they all use Git underneath. Git is the engine. GitHub is just one car brand.

Visual timeline of a real workflow

[Your laptop]                    [GitHub cloud]
     |                                |
     | 1. Write code                  |
     | 2. git add .                   |
     | 3. git commit -m "..."         |
     |                                |
     | 4. git push -----------------> | 5. Code appears online
     |                                |
     | 6. Friend clones or forks      |
     |    the repo from GitHub         |
     |                                |
     | 7. git pull <------------------| 8. Get their changes
     |                                |

Internet is only needed for steps 4, 6, and 8. Everything else works offline.

Why you need BOTH (not one or the other)

If you ONLY use Git (no GitHub)	If you ONLY use GitHub (no Git locally)
✅ You have version history	✅ Your code is backed up online
✅ You can undo mistakes	✅ Others can see your work
❌ No cloud backup	❌ You need internet for everything
❌ Hard to collaborate	❌ You can't work offline
❌ Computer dies = code dies	❌ You're just editing files in a browser (not real dev work)

The pro move: Use Git locally for daily work. Push to GitHub periodically for backup and collaboration.

Your first 10 minutes with Git + GitHub

Here's a concrete starter plan:

Step 1: Install Git

Mac: brew install git or download from git-scm.com
Windows: Download from git-scm.com (Git Bash included)
Linux: sudo apt install git (Ubuntu/Debian)

Step 2: Configure your identity (one time)

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Step 3: Create a GitHub account

Go to github.com and sign up (free).

Step 4: Create a repo on GitHub

Click the "+" icon → "New repository" → name it "my-first-repo" → check "Add a README" → Create.

Step 5: Clone it to your computer

git clone https://github.com/yourusername/my-first-repo.git
cd my-first-repo

Step 6: Make a change

Open the README.md file. Add a line: "I understand Git vs. GitHub now!"

Step 7: Commit and push

git add README.md
git commit -m "Added my realization"
git push origin main

Step 8: Refresh GitHub.com

See your change live. 🎉

The "Aha!" moment explained

Here's how you'll know you truly understand:

Git is to GitHub as your camera roll is to Instagram.

Your camera roll (Git) stores all your photos locally. You can edit, delete, and organize them offline.
Instagram (GitHub) is where you upload some of those photos to share with the world.
You can delete Instagram and still have your photos. You can delete your camera roll and lose everything (unless Instagram had a copy).

Never trust the cloud as your only copy. Always have Git locally.

FAQ (from actual beginners)

"Do I need to learn Git before using GitHub?"

Yes, but only the basics (add, commit, push, pull, clone). You can learn those in 30 minutes.

"Can I use GitHub without using Git?"

Technically yes (you can edit files directly on GitHub.com). But that's like editing a website using only Notepad. Professionals don't do this.

"What's a 'fork'?"

A copy of someone else's GitHub repository that lives under your GitHub account. You can modify it without affecting the original.

"What's a 'pull request'?"

You saying: "Hey, I changed your code. Here are my changes. Want to pull them into your project?"

"Is GitHub safe for proprietary code?"

Yes, but you need a private repository (paid on some plans, free on GitHub for small teams). For top-secret stuff, companies use self-hosted GitLab.

Final cheat sheet (bookmark this)

# Git commands (work offline)
git init                 # Start tracking a folder
git add file.txt         # Stage a file
git commit -m "message"  # Take a snapshot
git log                  # See your history
git diff                 # See what changed
git checkout [commitID]  # Go back in time

# GitHub commands (need internet)
git clone [url]          # Download a repo from GitHub
git push origin main     # Upload your commits to GitHub
git pull origin main     # Download latest changes from GitHub
git remote -v            # See which GitHub URL you're connected to

Your turn

Now go do this:

Open your terminal.
Create a folder called git-practice.
Run git init inside it.
Create a file called hello.txt.
Run git add . then git commit -m "first commit".
Go to GitHub, create a new repo (don't add a README this time).
Follow the "...or push an existing repository from the command line" instructions.

You just became a real developer. 🚀

Found this helpful? Leave a comment with your biggest Git or GitHub facepalm moment. We've all been there.

Want more beginner guides? Drop a follow and I'll cover branching, merging, and fixing merge conflicts next.

🚀 Beginner’s Guide: TCP vs. UDP – Which One Should You Use?

MysticMc — Thu, 02 Apr 2026 18:46:23 +0000

If you’ve ever looked at a networking diagram or tried to debug a slow API, you’ve probably seen the acronyms TCP and UDP. They sound similar, but they are fundamentally different.

Think of them as two different ways to send a letter (or a package) across the internet.

In this beginner-friendly guide, we’ll break down:

What TCP and UDP actually are.
The "Mail Analogy" (visual thinking).
Key differences in speed vs. reliability.
When to use which in your projects.

Let’s dive in! 🏊‍♂️

The OSI Model (The 2-second intro)

Without getting too theoretical, the internet works in layers. TCP and UDP live at the Transport Layer (Layer 4). Their job is simple: Take data from your app, package it up, and send it to another computer.

But how they package it is where the magic happens.

The Analogy: Mailing a Book 📖

Imagine you want to send a 1,000-page book to a friend.

TCP = Registered Mail (With tracking & receipts)

You go to the post office. You tear the book into 1,000 individual pages. You number each page.

Send: You mail page 1. Your friend texts you: "Got page 1."
Send: You mail page 2. Your friend texts: "Got page 2."
Oh no! Page 5 gets lost. Your friend texts: "I’m missing page 5." You re-send page 5.
Result: Your friend receives every single page, in perfect order, before reading the book.

UDP = Standard Mail (Fire & forget)

You rip out the 1,000 pages, shove them into envelopes without numbering them, and dump them in the mailbox.

Send: You don't care if they arrive.
Send: You don't care what order they arrive in.
Result: Your friend gets 980 pages, out of order, 10 seconds faster. If a page is missing, he just reads around it.

The Technical Definitions

TCP (Transmission Control Protocol)

Nickname: "The Reliable One"
Handshake: Requires a 3-way handshake (SYN, SYN-ACK, ACK) before sending data.
Error checking: Yes. If data is corrupted or lost, TCP asks for it again.
Ordering: Yes. Packets are reassembled in the exact order sent.
Speed: Slower (due to overhead).

UDP (User Datagram Protocol)

Nickname: "The Fast One"
Handshake: No handshake. Just sends data immediately.
Error checking: Minimal (checksum only). No retransmission.
Ordering: No. Packets are processed as they arrive (or not at all).
Speed: Very fast.

Code Snippet (Python example)

Here is a simple way to visualize the difference in code:

# TCP: You wait for confirmation
import socket
tcp_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
tcp_socket.connect(("google.com", 80))  # <-- Blocks until connection is made
tcp_socket.send(b"GET / HTTP/1.1\r\n\r\n")
data = tcp_socket.recv(1024)  # <-- Waits for guaranteed data

# UDP: Just throw it into the void
udp_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
udp_socket.sendto(b"Hello world", ("192.168.1.1", 9999))
# No connection. No confirmation. Just vibes.

Head-to-Head Comparison

Feature	TCP	UDP
Connection	Connection-oriented	Connectionless
Reliability	✅ High (Retransmits lost data)	❌ Low (No retransmission)
Ordering	✅ Preserves order	❌ No order guarantee
Speed	🐢 Slower	🚀 Faster
Header Size	20-60 bytes	8 bytes
Congestion Control	Yes (slows down if network is busy)	No (keeps blasting)
Broadcast/Multicast	❌ No	✅ Yes

Real-World Examples (When to use which)

Use TCP when:

Browsing the web (HTTP/HTTPS). You cannot have missing chunks of a webpage.
Sending an email (SMTP, IMAP). Missing a sentence changes the meaning.
Transferring a file (FTP, SFTP). One wrong byte corrupts a ZIP file.
Connecting to a database (PostgreSQL, MySQL). You need accurate queries.

Use UDP when:

Live Video Streaming (YouTube Live, Zoom, Twitch). You’d rather have a slightly blurry frame than wait for a missing packet to retransmit (which would cause buffering).
Online Gaming (Call of Duty, Fortnite). If you lose one packet about player position, don't ask for it again—just update the next position. Speed > Perfect accuracy.
DNS Lookups. Translating google.com to an IP address requires one tiny request and reply. UDP is perfect because it's fast and connectionless.
VoIP (Phone calls). "Can you hear me now?" is better than "Waiting for packet #42..."

Pro Tip: Even Zoom and YouTube actually use TCP for the control signals (login, chat) but UDP for the actual video/audio stream. You can use both!

The "Gotcha" for Beginners

"If UDP is faster, why don't we always use it?"

Because reliability matters more than speed for most things.

Imagine buying something on Amazon using UDP:

You click "Buy." The packet gets lost.
Your credit card gets charged (packet arrived).
The confirmation email never arrives (packet lost).
You have no idea if the order worked.

With TCP, the browser keeps asking, "Did you get my request?" until it gets a "Yes."

Summary Cheat Sheet

If you need...	Choose...
100% accuracy	✅ TCP
Resending lost data	✅ TCP
Ordered packets	✅ TCP
Speed above all else	🚀 UDP
Live streaming / Gaming	🚀 UDP
Broadcasting to many devices	🚀 UDP

Final Takeaway

TCP is polite: "Hello, are you there? Okay, I will send page 1. Did you get it? Okay, here is page 2..."

UDP is reckless: "HERE IS PAGE 1, PAGE 2, PAGE 5, PAGE 3... GOOD LUCK!"

Now that you know the difference, go look at your favorite app. Is it using TCP or UDP? (Hint: netstat -an on your terminal can tell you!).

Happy coding! 🖥️

Found this helpful? Leave a like or comment below. What protocol confused you the most when you started?

Struggling to break into Devops!

MysticMc — Wed, 01 Apr 2026 13:58:38 +0000

Most engineers don’t struggle because they’re undisciplined.
They struggle because the way DevOps is taught mirrors the way a library is organized: everything is available, but nothing is connected. You finish a Docker course and move to Kubernetes. You finish Kubernetes and start Terraform. Each thing makes sense on its own. None of it prepares you for the moment someone puts an incident in front of you and asks what you see.

That gap, between knowing tools and thinking in systems , is where most careers stall. And almost no one tells you it exists until you’re already stuck in it.

Everything on this page exists to close that gap deliberately.

Start Here
The DevOps Operating System
The structured path from confusion to a hireable engineer

It’s a 6-week curriculum built around one progression: reading → building → understanding → explaining → getting hired. The first four phases give you a working local environment, Linux, Git, Docker, and Kubernetes running on MicroK8s. After that, the curriculum moves you into realistic production scenarios: real world tickets, infrastructure tasks, and a capstone enterprise system you build end-to-end.

By the end, you won’t need someone to walk you through a debugging session. You’ll already know what to look for, and how to explain what you found.

If You’re Not Ready for That Yet
Start with these. They’re free. They’re the same resources engineers have used to get clear, get confident, and get interviews.

Free DevOps Resume Template. DevOps resumes fail because they list tools instead of demonstrating judgment. This template is structured around what hiring managers actually look for: evidence that you understand real infrastructure and can demonstrate operational judgment under real constraints, not just coursework.

Real-World DevOps Project Portfolio The question that ends most interviews isn’t technical. It’s “Can you show me something you built and debugged?” This portfolio gives you production-style projects across CI/CD, Kubernetes, and cloud infrastructure, the kind that answer that question before it’s asked.

GitHub Troubleshooting Toolkit: When something breaks in production, the engineers who stay calm aren’t calmer by nature. They have a method. This toolkit gives you a repeatable diagnostic process so that “the system is down” becomes a starting point, not a crisis.

For Engineers Ready to Go Deeper
The Kubernetes Detective: A pod is crashing. kubectl logs shows nothing useful. Three engineers are watching you, and you have no idea where to start. This guide is the systematic debugging method that turns that moment from panic into a process. It's what separates engineers who guess from engineers who diagnose.

The DevOps Interview Decoder. Candidates fail interviews not because of a lack of knowledge, but because they can’t articulate how systems actually work under pressure. This framework closes that gap. Engineers who have used it have landed roles exceeding $170K globally, not because it’s a script, but because it teaches you to think out loud like someone who has already seen production.

AI for DevOps: AI won’t replace engineers. It will replace engineers who treat it as a search engine. This guide covers 47 tested prompts for troubleshooting, automating learning, and recovering hours every week, built for engineers who want to operate faster, not just differently.

Stay Close
Weekly Newsletter Every week: a breakdown of a real production incident, an architecture lesson, a cost-saving tactic used inside actual companies, and occasionally an honest account of something that went badly and what it taught. No hype. No listicles. Signal only.
Sign Up Here

You don’t need more courses.

You need fewer distractions, better systems, and one structured path that connects what you’re learning to what production actually looks like.

🔖 Tip: Bookmark this page. I update it regularly with new tools, labs, and frameworks.

DEV Community: MysticMc

Why Can't My App Connect to My Database?

The big idea first

Part 1: Security groups (gate 1)

What is a security group?

What's in a rule?

The "Type" dropdown is just a shortcut

Part 2: Who can connect? (the source)

What does 0.0.0.0/0 mean?

Does that mean anyone can log in?

Safer options for SSH

Part 3: Ports

What happens when you open a port?

Why big port ranges are dangerous

Part 4: Connecting an app server to a database server

Option A: allow the app server's IP (works, but annoying)

Option B: allow a security group (better)

Part 5: The 4 gates in detail

Gate 1: Security group

Gate 2: Is PostgreSQL listening?

Gate 3: PostgreSQL's visitor list (pg_hba.conf)

Gate 4: Username and password

Part 6: Reading error messages

Part 7: Two commands to test

Test 1: Can I reach the port? (gates 1–2)

Test 2: Can I log in? (all 4 gates)

Part 8: Troubleshooting checklist

Quick recap

Good to know later (skip for now)

How Code Goes from Your Laptop to the User

The big idea

Two families of languages

Language by language

1. JavaScript (frontend)

2. Java

3. Python

4. Go

5. Rust

6. C# / .NET

Summary table

Two things people often get wrong

Why this matters for DevOps

Kubernetes Networking, Explained Simply

0. Two words you need first

1. The big idea: sort tools by job, not by rivalry

2. The 5 networking jobs

Why Gateway API instead of Ingress?

3. One key idea: "L4" vs "L7" front doors

4. The example app

5. Project 1: The "let AWS do it" setup

6. Project 2: AWS outside, open-source inside

7. Project 3: Mostly open-source, runs anywhere

8. All three side by side

9. Where does MetalLB fit?

10. One-sentence summary

Getting AWS Secrets into EKS Pods with ESO and Pod Identity

Part 1: Setup (done once)

Step 1: Install ESO in the cluster

Step 2: Install the Pod Identity Agent

Step 3: Create an IAM role for ESO

Step 4: Connect the role to ESO's ServiceAccount

Part 2: Telling ESO what to do

Step 5: Create a SecretStore

Step 6: Create an ExternalSecret

Part 3: What happens automatically

Step 7: ESO gets its credentials

Step 8: ESO fetches the secret

Step 9: ESO creates the K8s Secret

Step 10: The app reads the secret

The picture to remember

The whole thing in one line

The analogy

Hands-on: step-by-step template

Step 0: Set your variables

Step 1: Create a secret in AWS Secrets Manager

Step 2: Install ESO (the courier)

Step 3: Install the Pod Identity Agent (the ID card office)

Step 4: Create an IAM role for ESO (the permission slip)

Step 5: Connect the role to ESO's ServiceAccount (give the courier the slip)

Step 6: Tell ESO where to look (ClusterSecretStore)

What does `0.0.0.0/0` mean?

Gate 3: PostgreSQL's visitor list (`pg_hba.conf`)

The Broken `docker-compose.yml`

3. Fix `depends_on` with a Condition

4. Move Secrets to `.env`