DEV Community: Yousuf Basir

Secure Linux Server Setup & Application Deployment

Yousuf Basir — Thu, 18 Dec 2025 14:00:47 +0000

A Practical, Opinionated Guide for Real Production Servers

Deploying an application is easy.
Deploying it securely, so that one compromised app does not take down your entire server, requires discipline and structure.

This guide documents the exact process we follow to prepare a fresh Linux server, deploy databases and applications, and keep the system secure, isolated, and maintainable.

This is not theory.
This is a battle-tested setup suitable for real production servers.

What This Guide Is For

This setup works for:

Node.js backends (NestJS, Express, Fastify)
Next.js (standalone build)
Static frontends (React / Vite)
Databases (PostgreSQL, MongoDB, Redis) using Docker
Reverse proxy with HTTPS (Caddy / Nginx)

Core Security Philosophy

Before commands, understand the rules:

Root is not an app runtime
One app = one service user
Humans deploy, services run
Databases are private by default
Reverse proxy is the only public entry point
Assume one app will eventually be compromised

Our goal is simple:

If one application is hacked, everything else must remain safe.

Step 1 — Create a Non-Root Admin User

On a fresh server, you usually start as root.

Create a normal admin user (example: dev):

adduser dev
usermod -aG sudo dev

Why?

Root SSH access is dangerous
Using sudo is auditable
Accidents are easier to recover from

Step 2 — Harden SSH Access

Generate SSH key (on your local machine)

ssh-keygen -t ed25519

Copy the public key to the server:

mkdir -p /home/dev/.ssh
nano /home/dev/.ssh/authorized_keys

Fix permissions:

chown -R dev:dev /home/dev/.ssh
chmod 700 /home/dev/.ssh
chmod 600 /home/dev/.ssh/authorized_keys

Disable dangerous SSH options

Edit SSH config:

sudo nano /etc/ssh/sshd_config

Ensure:

PermitRootLogin no
PubkeyAuthentication yes

Disable password login:

Match all
    PasswordAuthentication no

Reload SSH safely:

sudo systemctl reload ssh

Step 3 — Enable Firewall (UFW)

Allow only what’s required:

sudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

Check:

sudo ufw status verbose

Only ports 22, 80, 443 should be public.

Step 4 — Install Docker (Admin User Only)

Docker is treated as root-equivalent.

Only the admin user (dev) may use Docker
Application users never touch Docker

Install Docker from the official repository (not apt docker.io).

After installation:

sudo usermod -aG docker dev

Re-login and verify:

docker ps

🚫 Never add service users to the docker group.

Step 5 — Run Databases Securely in Docker

Key rules for databases

Never expose DB ports publicly
Bind to 127.0.0.1 only
Use Docker volumes
Access from local machine via SSH tunneling

Example: PostgreSQL (secure)

docker run -d \
  --name postgres \
  --restart unless-stopped \
  -e POSTGRES_USER=appuser \
  -e POSTGRES_PASSWORD=STRONG_PASSWORD \
  -e POSTGRES_DB=appdb \
  -v pgdata:/var/lib/postgresql \
  -p 127.0.0.1:5432:5432 \
  postgres:18

Verify:

ss -tulpn | grep 5432

Expected:

127.0.0.1:5432

Important note on port binding:
We explicitly bind database ports to 127.0.0.1 because Docker does not honor UFW rules for published ports. Docker inserts its own iptables rules, so if a container port is mapped to 0.0.0.0, it will be publicly accessible even if UFW blocks that port. Binding to 127.0.0.1 ensures the database is reachable only from the server itself and never exposed to the internet.

Step 6 — Access Databases via SSH Tunnel

From your local machine:

ssh -N -L 5432:127.0.0.1:5432 dev@SERVER_IP

Now connect locally using:

Host: 127.0.0.1
Port: 5432

🔐 Encrypted, private, safe.

Step 7 — One GitHub Deploy Key per Repository

For each private repository, we generate a dedicated SSH deploy key on the server (as the admin user):

ssh-keygen -t ed25519 -C "deploy-myapp"

Use a unique filename per repository:

~/.ssh/id_ed25519_myapp

Add the public key to:

GitHub → Repository → Settings → Deploy keys

Grant read-only access and clone the repository using an SSH alias (not HTTPS).

👉 For the full, step-by-step explanation (SSH config, aliases, and examples), see:
https://dev.to/yousufbasir/securely-managing-github-access-on-production-servers-20l3

Step 8 — Create a Service User (Per App)

Each app runs as its own locked-down user:

sudo adduser \
  --system \
  --no-create-home \
  --group \
  --shell /usr/sbin/nologin \
  svc-myapp

This user:

cannot SSH
has no shell
has no sudo
owns only its app directory

Step 9 — Clone & Build as Admin User

cd /var/apps
git clone git@github.com-myapp:org/repo.git
cd repo

npm ci
npm run build
npm prune --production

Humans build.
Services only run.

Step 10 — Environment Variables (Build-time vs Runtime)

In production, environment variables are never committed to Git.
They are managed by the system and injected only when required.

We store runtime environment variables in a system-managed file:

/etc/systemd/system/myapp.env

This file is owned by root and loaded by systemd at runtime.

Special case: Next.js public environment variables

If a Next.js project uses variables starting with NEXT_PUBLIC_, those must be available at build time, because the Next.js compiler embeds them into the generated JavaScript.

In that case, we explicitly inject the env file when building:

sudo -E bash -c '
  set -a
  source /etc/systemd/system/myapp.env
  set +a

  npm run build
'

If there are no NEXT_PUBLIC_* variables, this step is not required—runtime injection via systemd is enough.

Next.js standalone build (required asset copy)

When building Next.js as a standalone application, we must also copy static assets manually so the app can run without the full .next directory.

After next build, we run:

mkdir -p .next/standalone/.next
cp -r .next/static .next/standalone/.next/
cp -r public .next/standalone/

Why this is needed:

The standalone output contains only server code
Static files (_next/static, public/) are not included automatically
Without this step, the app will run but assets will 404

This produces a fully self-contained Node.js app that can be started via systemd.

Step 11 — Transfer Ownership to Service User

After build:

sudo chown -R svc-myapp:svc-myapp /var/apps/myapp
sudo chmod -R o-rwx /var/apps/myapp

At this point, even dev should get permission denied — that’s intentional.

Step 12 — Run the App with systemd (Hardened)

Example systemd service:

[Unit]
Description=My Application
After=network.target

[Service]
User=svc-myapp
Group=svc-myapp
WorkingDirectory=/var/apps/myapp
EnvironmentFile=/etc/systemd/system/myapp.env

ExecStart=/usr/bin/node dist/main.js
Restart=always
RestartSec=3

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/apps/myapp
PrivateTmp=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictNamespaces=true
LockPersonality=true
RestrictSUIDSGID=true
CapabilityBoundingSet=
AmbientCapabilities=
UMask=0077

[Install]
WantedBy=multi-user.target

Enable and start:

sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp

Step 13 — Static Frontend Builds (React / Vite)

Static frontend apps (React, Vite, etc.) do not run via systemd.

They are built once and served directly by the reverse proxy.

Injecting environment variables at build time

For static apps, public variables (e.g. VITE_*) must be injected during the build.

We place the env file in the project root:

.env.production

Then build explicitly:

npm run build

The build output (HTML, JS, CSS, assets) is now fully static and contains the injected values.

Granting Caddy read access

Caddy runs as its own user and needs read-only access to the static build folder.

Example:

sudo chown -R svc-frontend:svc-frontend /var/apps/frontend
sudo chmod -R 755 /var/apps/frontend/dist

Why we do this:

Caddy must read static files
No write access is needed
Prevents accidental or malicious file modification

Static apps have no runtime, no open ports, and no background process—this significantly reduces attack surface.

Step 14 — Reverse Proxy Configuration (Caddy)

Caddy is the only public entry point to the server.
All applications—dynamic or static—are exposed through it.

Example: Node.js app running via systemd

The app runs internally on a private port (e.g. 127.0.0.1:5000).

Caddyfile:

api.example.com {
    reverse_proxy 127.0.0.1:5000
}

Notes:

The app port is not exposed publicly
Firewall blocks direct access
Only Caddy can reach it

This applies to NestJS, Next.js (standalone), Express, etc.

Example: Static frontend site

The static build lives at:

/var/apps/frontend/dist

Caddyfile:

app.example.com {
    root * /var/apps/frontend/dist
    encode gzip zstd
    try_files {path} {path}/ /index.html
    file_server
}

What this does:

Serves static files directly
Supports client-side routing (SPA)
Enables compression
No Node.js process required

Why this architecture matters

Only ports 80 and 443 are public
Apps never bind directly to the internet
Static sites have zero runtime risk
Dynamic apps are isolated behind systemd and firewall

This clean separation keeps the server secure, observable, and easy to reason about.

Step 15 — Updating an App Safely

sudo chown -R dev:dev /var/apps/myapp

cd /var/apps/myapp
git pull
npm ci
npm run build
npm prune --production

sudo chown -R svc-myapp:svc-myapp /var/apps/myapp
sudo chmod -R o-rwx /var/apps/myapp

sudo systemctl restart myapp

🚫 Never sudo git pull.

What This Setup Protects Against

Privilege escalation
Lateral movement between apps
Accidental data leaks
Exposed databases
Root-level compromise from app bugs

Even if one app is hacked:

The system survives. Other apps survive. Data survives.

Final Thoughts

Security is not about tools.
It’s about clear boundaries and boring defaults.

This setup avoids complexity, avoids magic, and relies on Linux doing what it already does best.

That’s how small teams run production servers professionally.

If you follow this guide end-to-end, your server will already be more secure than most production environments.

Happy (and secure) deploying 🚀

Securely Managing GitHub Access on Production Servers

Yousuf Basir — Thu, 18 Dec 2025 13:28:51 +0000

This guide shows the correct, production-safe way to let a server clone and update private GitHub repositories using deploy keys and SSH aliases.

This approach works for:

single servers
multiple apps on one server
teams with shared infrastructure
long-lived production environments

Why This Matters

Common mistakes:

Using HTTPS with personal access tokens
Using one SSH key for all repositories
Logging in to GitHub from servers
Giving write access when read-only is enough

These mistakes increase blast radius.

Our goal:

If a server or key is compromised, only one repository is affected — nothing else.

Core Rules

We follow these rules strictly:

One repository = one SSH key
Servers never use personal GitHub accounts
Deploy keys are read-only
SSH aliases decide which key is used
HTTPS is never used on production servers

Step 1 — Generate a Deploy Key (Server Side)

Generate a new SSH key:

ssh-keygen -t ed25519 -C "deploy-myapp"

When prompted for the file name, do not use the default key.

Use a repository-specific name:

/home/dev/.ssh/id_ed25519_myapp

Leave the passphrase empty.

This creates:

~/.ssh/id_ed25519_myapp
~/.ssh/id_ed25519_myapp.pub

Each repository must have its own unique key.

Step 2 — Configure an SSH Alias

When multiple SSH keys exist, Git needs help choosing the right one.
We solve this using SSH aliases.

Edit the SSH config file:

nano ~/.ssh/config

Add a new section:

Host github.com-myapp
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_myapp
  IdentitiesOnly yes

What this does:

github.com-myapp is an alias (not a real domain)
It forces SSH to use id_ed25519_myapp
Prevents Git from trying the wrong key

This is mandatory once you have more than one deploy key.

Step 3 — Add the Deploy Key to GitHub

On GitHub:

Open the repository
Go to Settings → Deploy keys
Click Add deploy key
Paste the public key:

cat ~/.ssh/id_ed25519_myapp.pub

Give it a clear name (e.g. prod-server)
Enable read-only access

Deploy keys are repository-scoped by design — this is a security feature.

Step 4 — Clone Using the SSH Alias (Not HTTPS)

❌ Do not use HTTPS
❌ Do not use the default GitHub SSH URL

Instead, clone using the alias:

git clone git@github.com-myapp:your-org/myapp.git

What happens here:

github.com-myapp matches the SSH config
SSH selects the correct deploy key
The server can access only this repository

Step 5 — Consistent Naming (Strongly Recommended)

To avoid confusion, keep names aligned:

Item	Example
SSH alias	`github.com-myapp`
Key file	`id_ed25519_myapp`
Repo name	`myapp`

This becomes critical when managing many applications on the same server.

Why This Setup Is Secure

No personal GitHub accounts on servers
No long-lived access tokens
No shared SSH keys
One compromised key affects only one repo
Access can be revoked instantly from GitHub

This is least-privilege access, applied correctly.

How This Fits Into a Secure Deployment Workflow

In a hardened server setup:

Admin users clone and build apps
Service users never touch Git
Deploy keys are read-only
Runtime environments are isolated

This keeps code access, runtime access, and system access clearly separated.

Final Thoughts

Secure infrastructure is about boundaries, not convenience.

Using deploy keys with SSH aliases is slightly more work upfront —
but it prevents an entire class of security failures later.

If your production server ever needs GitHub access,
this is the correct way to do it.

Introduction to Satellite Remote Sensing and Vegetation Indices

Yousuf Basir — Sat, 30 Aug 2025 18:54:51 +0000

Note: This article was generated with the help of ChatGPT (an AI by OpenAI). The content is based on my questions and the AI’s explanations, structured into an article format.

Remote sensing is the science of observing Earth from space using satellites. Instead of needing huge cameras in orbit, satellites use special sensors that record reflected sunlight or emitted energy across different parts of the electromagnetic spectrum (visible, infrared, thermal, radar). These measurements are then processed into images and indices that help us understand vegetation, water, soil, climate, and urban areas.

🛰️ How Do Satellites Capture Images from Space?

You might wonder: how can satellites, orbiting hundreds of kilometers above Earth, capture detailed images without giant lenses?

Pushbroom Scanning: Instead of taking a single photo, satellites scan the ground line by line as they move, building images piece by piece.
Sensitive Detectors: They use advanced CCD/CMOS arrays to record different wavelengths (blue, red, near-infrared, shortwave infrared, etc.).
Telescopic Optics: Satellites rely on long focal lengths and narrow fields of view, not massive lenses.
Synthetic Aperture Radar (SAR): Radar satellites simulate very large antennas using satellite motion, producing high-resolution images even at night or through clouds.

These techniques make it possible to achieve ground resolutions from 30 meters (Landsat) to as fine as 30 cm (WorldView satellites).

🌱 Key Vegetation and Water Indices

Satellite sensors capture multiple spectral bands. By combining them in ratios, scientists create indices that highlight specific land surface properties. Some of the most important ones are:

NDVI (Normalized Difference Vegetation Index) → Measures plant greenness and vigor.
EVI (Enhanced Vegetation Index) → Similar to NDVI but reduces atmospheric effects; good for dense forests.
LAI (Leaf Area Index) → Estimates how much leaf surface covers the ground; linked to biomass and photosynthesis.
LSWI (Land Surface Water Index) → Indicates soil and vegetation water content.
NDMI (Normalized Difference Moisture Index) → Detects canopy moisture and stress.
NDWI (Normalized Difference Water Index) → Maps open water bodies like lakes and rivers.
NBR (Normalized Burn Ratio) → Detects burned or fire-damaged areas.
NDBI (Normalized Difference Built-up Index) → Distinguishes urban/built-up areas from vegetation.

Each index highlights a different aspect of the land, and combining them gives a more complete picture of ecosystems.

📊 What Can We Learn from These Indices?

With time-series data (e.g., weekly averages), we can:

Track vegetation growth and decline across seasons.
Estimate crop yield and forest biomass.
Detect water stress, droughts, or floods.
Monitor phenology (start, peak, and end of growing seasons).
Map urban expansion or deforestation.

These insights are vital for agriculture, forestry, climate research, and disaster management.

📡 Which Satellites Provide These Indices?

Different sensors are optimized for different applications:

Landsat (NASA/USGS) → General purpose, long historical record (30 m resolution).
Sentinel-2 (ESA) → High-resolution (10 m), excellent for agriculture thanks to red-edge bands.
MODIS (NASA) → Daily global monitoring, useful for time-series analysis.
Hyperspectral Sensors (e.g., PRISMA, EnMAP) → Hundreds of narrow bands, ideal for detailed vegetation and geology studies.
SAR Satellites (e.g., Sentinel-1, RADARSAT) → Radar imaging, works day/night and through clouds.

✅ Conclusion

Remote sensing makes it possible to study our planet from space with incredible detail — without giant cameras. By using line scanning, sensitive detectors, telescopic optics, and radar techniques, satellites capture the data needed to calculate powerful indices like NDVI, LSWI, and NDMI. These indices help us monitor vegetation health, water availability, soil conditions, urban growth, and environmental change.

A Beginner’s Guide to Satellite Data and Vegetation Indices (NDVI, EVI & Beyond)

Yousuf Basir — Tue, 26 Aug 2025 19:11:19 +0000

Note: This article was generated with the help of ChatGPT (an AI by OpenAI). The content is based on my questions and the AI’s explanations, structured into an article format.

Introduction

Satellite data analysis—often called Remote Sensing or Earth Observation—is a powerful way to understand our planet. From monitoring crops to tracking droughts, satellites provide a bird’s-eye view of Earth in different wavelengths of light.

If you’re new, terms like NDVI, EVI, vegetation index, or spectral bands can feel confusing. In this article, we’ll break down the essentials in a simple way.

1. What Satellites Actually Capture

Satellites don’t directly capture “NDVI images” or “vegetation maps.” Instead, they record reflectance: how much light is reflected from Earth’s surface in different parts of the electromagnetic spectrum.

Each part of the spectrum is stored as a separate band, which is just a grayscale image:

Blue, Green, Red bands – visible light, similar to our eyes.
Near Infrared (NIR) – invisible to us, but plants reflect it strongly.
Shortwave Infrared (SWIR) – useful for soil and water content.

👉 Each band looks black-and-white on its own, but carries unique information about the surface.

2. From Grayscale to Color Composites

A single band is grayscale, but by combining bands, we can create color composites:

True Color (RGB): Red → Red channel, Green → Green channel, Blue → Blue channel → looks like a normal photo.
False Color: Swap in NIR for Red → vegetation appears bright red, making it easy to detect.

These composites are not “photos” in the traditional sense—they are visualizations of band data.

3. What Are Vegetation Indices?

Vegetation indices are mathematical formulas that combine bands to highlight plant health.

NDVI (Normalized Difference Vegetation Index)

Formula: (NIR – Red) / (NIR + Red)

Healthy, dense vegetation: values close to +1
Sparse vegetation: 0.2 – 0.5
Bare soil: near 0.0
Water/snow/cloud: negative values

EVI (Enhanced Vegetation Index)

A refined version of NDVI, correcting for soil and atmosphere, useful in dense forests.

Other Indices

NDWI: water detection
SAVI: adjusts NDVI for soil background
Chlorophyll Indices (GCI, MCARI): measure plant pigments

👉 These indices aren’t captured by satellites—they are calculated from bands.

4. Why Do NDVI Maps Look So Colorful?

Raw NDVI is just a grayscale layer (values from –1 to +1). To make interpretation easier, software assigns color palettes:

Green = healthy vegetation
Yellow/Orange = moderate vegetation
Red = stressed or bare land
Blue/Black = water or no data

The colors are symbolic, not physical—they’re chosen by analysts for readability.

5. One Sensor, Many Indices

A common beginner misunderstanding is: “Do satellites have one sensor for NDVI, another for EVI, etc.?”

The answer: No.

A single satellite instrument (like Sentinel-2’s MSI or Landsat’s OLI) captures multiple bands.
Indices are then derived mathematically using different band combinations.

This means the same dataset can generate NDVI, EVI, NDWI, and many others.

6. Why This Matters

Understanding these basics helps you:

Interpret satellite maps correctly (colors ≠ raw reality).
Choose the right index for your application (NDVI for crops, NDWI for water, etc.).
Avoid misconceptions (indices are not directly captured, but derived).

7. Next Steps for Beginners

If you’re starting in geo data analysis:

Learn Remote Sensing Basics – bands, resolutions, reflectance.
Explore Free Tools – QGIS (desktop) or Google Earth Engine (cloud).
Practice NDVI – compute it using Sentinel-2 or Landsat data.
Move to Coding – Python libraries (rasterio, geopandas, earthengine-api).
Specialize – agriculture, forestry, hydrology, or climate studies.

Conclusion

At its core, satellite data is grayscale reflectance measurements across spectral bands. Indices like NDVI and EVI are not directly sensed—they’re derived by combining bands. The colorful maps we see are just visual representations of these numbers.

By grasping this foundation, you can start making sense of Earth observation data and unlock its potential for real-world applications.

Managing Multiple SSH Servers Across Windows & macOS with SSH Config & Tmux

Yousuf Basir — Wed, 20 Aug 2025 11:06:51 +0000

If you work with multiple servers — some requiring .pem keypairs and others with password authentication — you know how quickly it becomes messy. Add in the fact that you might switch between Windows at home and macOS at work, and suddenly managing SSH connections can feel like juggling knives.

In this article, I’ll show you how to organize your SSH access across both Windows and macOS using:

OpenSSH (built-in on both OS)
~/.ssh/config (for managing profiles)
Multiplexing (to speed up connections)
tmux (to keep sessions alive even if your laptop disconnects)

Let’s dive in 👇

1. Install OpenSSH

macOS → Already installed, just open Terminal.
Windows 10/11 → OpenSSH is included, but if missing:

  Settings → Apps → Optional Features → Add a Feature → OpenSSH Client

Now you can run:

ssh user@server-ip

2. Use `~/.ssh/config` for Profiles

Instead of typing long commands, store servers in a config file:

Windows path → C:\Users\<YourUser>\.ssh\config
macOS/Linux path → ~/.ssh/config

Example:

# Server with PEM key
Host project-server
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/project-server.pem

# Server with password login
Host db-server
    HostName 198.51.100.20
    User root
    PreferredAuthentications password

# GitHub shortcut
Host github.com
    User git
    IdentityFile ~/.ssh/github_id_rsa

Now you can connect with simple commands:

ssh project-server
ssh db-server

3. Handling Password Servers

Configs don’t store passwords for security reasons. Options:

On macOS/Linux:

  brew install hudochenkov/sshpass/sshpass
  sshpass -p 'mypassword' ssh db-server

Or better: set up key-based login:

  ssh-copy-id user@db-server

(Now you won’t need the password every time 🚀)

4. Speed Up Connections with Multiplexing

Add this to your ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

✅ First connection = normal login
✅ Next connections (within 10 mins) = instant, no re-auth

5. Keep Sessions Alive with `tmux`

On any server, install tmux:

sudo apt install tmux   # Ubuntu/Debian
brew install tmux       # macOS

Usage:

tmux new -s mysession      # start session
Ctrl+b d                   # detach but keep running
tmux attach -t mysession   # reattach later

Now your scripts and processes survive even if your laptop disconnects.

6. Sync Configs Between Machines

To keep everything consistent across Windows and macOS:

Store ~/.ssh/config and .pem files in a private Git repo or encrypted cloud storage.
Copy or symlink them into ~/.ssh on each machine.

✅ Final Thoughts

By combining:

SSH config for organizing servers,
Multiplexing for faster connections, and
tmux for persistent sessions,

…you get a portable, reliable, and cross-platform SSH workflow that works seamlessly on Windows and macOS.

No more remembering IPs, juggling .pem files, or retyping passwords. Just:

ssh project-server

And you’re in! 🎉

💬 What about you? Do you use a GUI-based SSH manager (like Termius or MobaXterm), or do you prefer CLI setups like this one?

Fixing “Service Account Key Creation is Disabled” in Google Cloud Console

Yousuf Basir — Sun, 10 Aug 2025 12:03:07 +0000

When working with Google Cloud and products like Google Earth Engine, you may run into this frustrating error:

Service account key creation is disabled
An organisation policy that blocks service account key creation has been enforced on your organisation.

This guide walks through why this happens, how to diagnose it, and the exact steps to fix it — based on a real-world scenario.

Understanding the Problem

Google Cloud service account keys allow code running outside GCP (like a backend server) to authenticate securely.
However, they also pose a security risk if leaked.

Many organisations block key creation by enforcing an Organisation Policy Constraint:

Legacy constraint: iam.disableServiceAccountKeyCreation
Managed constraint (newer): iam.managed.disableServiceAccountKeyCreation

When either one is active and enforced at the organisation level, all projects inherit the restriction.
This means even if you are a Project Owner, you can’t create JSON keys until the policy is overridden.

Why Both Policies Matter

Google is migrating from the legacy constraint to the managed constraint, but during the transition:

Both constraints are evaluated for security.
Disabling just one is not enough — if the other remains active, the block continues.

That’s why some users disable the new constraint, but still see the error when creating keys — the legacy one is still active.

Diagnosing the Issue

Switch to your project in the Google Cloud Console.
Navigate to:

   IAM & Admin → Organisation policies

Search for "Disable service account key creation".
If you see two entries:

One with .managed in the ID (new)
One without .managed (legacy)
1. Check the Enforcement state:
If Active, the policy is blocking you.

Fixing the Policy

Step 1 — Make Sure You Have the Right Role

You need:

Organisation Policy Administrator (roles/orgpolicy.policyAdmin) or
Organisation Administrator (roles/resourcemanager.organizationAdmin)

If you only have project-level roles, you won’t be able to override an inherited policy.

Step 2 — Override the Managed Constraint

Switch to your project.
Go to:

   IAM & Admin → Organisation policies

Search for:

   iam.managed.disableServiceAccountKeyCreation

Click it → Manage policy.
Choose:

Override parent’s policy
Set Enforcement to Off.
1. Save.

Step 3 — Override the Legacy Constraint

Still in the project view, search for:

   iam.disableServiceAccountKeyCreation

Click it → Manage policy.
Choose:

Override parent’s policy
Set Enforcement to Off.
1. Save.

Step 4 — Ensure Project Access

Even with the policy disabled, you must have the right project-level permissions:

Service Account Admin (roles/iam.serviceAccountAdmin)
or Editor (roles/editor)

Without these, you may see:

Missing permissions: iam.serviceAccounts.list

when trying to open the Service Accounts page.

Creating the Service Account Key

Once both constraints are set to Not enforced for your project:

Go to:

   IAM & Admin → Service accounts

Open your service account.
Go to the Keys tab.
Click:

   Add key → Create new key → JSON

Download and store the key securely.

Security Best Practices

Never commit your JSON key to GitHub or public storage.
Store it in a secure secret manager.
Rotate or delete unused keys regularly.
Consider using Workload Identity Federation to avoid storing keys entirely.

Conclusion

The “Service account key creation is disabled” error is usually caused by organisation policies.
The tricky part is that both the legacy and the managed constraint can block you — disabling only one won’t work.

By:

Overriding both constraints at the project level, and
Ensuring you have the right project permissions,

…you can generate the JSON key and move forward with your development.

Setting Up Redis with Docker: A Step-by-Step Guide

Yousuf Basir — Fri, 14 Mar 2025 19:03:25 +0000

Redis, an open-source, in-memory data structure store, is widely used as a database, cache, message broker, and streaming engine. In this guide, I'll walk you through deploying Redis using Docker, ensuring data persistence and remote connectivity.

Prerequisites

Before starting, ensure you have:

A VPS or server with Linux installed
Docker installed and running
Basic familiarity with command line interfaces
SSH access to your server

Step 1: Pull the Redis Image

First, let's download the official Redis image from Docker Hub:

docker pull redis:latest

This fetches the latest Redis image. If you need a specific version, replace latest with the version number (e.g., redis:7.0).

Step 2: Create a Directory for Data Persistence

To ensure your Redis data survives container restarts or removal, create a directory for data persistence:

mkdir -p ~/redis_data

Step 3: Run the Redis Container

Now, deploy Redis with appropriate settings for security and persistence:

docker run -d \
  --name redis \
  -p 6379:6379 \
  -v ~/redis_data:/data \
  --restart always \
  redis:latest \
  redis-server --requirepass your_strong_redis_password

Let's examine each part of this command:

-d: Runs the container in detached mode
--name redis: Names the container "redis" for easy reference
-p 6379:6379: Maps the container's Redis port to the host's port
-v ~/redis_data:/data: Mounts the host directory for data persistence
--restart always: Ensures automatic restart after system reboots
redis-server --requirepass your_strong_redis_password: Starts Redis with password protection

Step 4: Verify the Installation

To confirm Redis is running properly:

docker ps

You should see your Redis container in the list of running containers.

Step 5: Connecting to Redis

To connect to your Redis instance locally:

docker exec -it redis redis-cli

Once connected, authenticate using:

AUTH your_strong_redis_password

For remote connections, use:

redis-cli -h your_server_ip -p 6379 -a your_strong_redis_password

Or programmatically with a Redis URI:

redis://default:your_strong_redis_password@your_server_ip:6379

Step 6: Setting Up Persistence

Redis offers different persistence options. By default, the Redis Docker image uses the RDB (Redis Database) persistence model, which takes snapshots of your dataset at specified intervals.

To enable AOF (Append Only File) persistence for more durability, modify your run command:

docker run -d \
  --name redis \
  -p 6379:6379 \
  -v ~/redis_data:/data \
  --restart always \
  redis:latest \
  redis-server --requirepass your_strong_redis_password --appendonly yes

The --appendonly yes option enables AOF persistence, which logs every write operation.

Step 7: Configuring Redis with a Custom Configuration File

For more advanced configurations, create a custom Redis configuration file:

mkdir -p ~/redis_config

Create a file named redis.conf in this directory:

nano ~/redis_config/redis.conf

Add your configuration settings, for example:

requirepass your_strong_redis_password
appendonly yes
maxmemory 256mb
maxmemory-policy allkeys-lru

Run Redis with your custom configuration:

docker run -d \
  --name redis \
  -p 6379:6379 \
  -v ~/redis_data:/data \
  -v ~/redis_config/redis.conf:/usr/local/etc/redis/redis.conf \
  --restart always \
  redis:latest \
  redis-server /usr/local/etc/redis/redis.conf

Step 8: Security Recommendations

Network Security: Restrict access to port 6379

   ufw allow from trusted_ip_address to any port 6379

Strong Authentication: Use complex passwords for Redis
Binding: In production environments, consider binding Redis to localhost and using an SSH tunnel for remote connections
Regular Backups: Set up automated backups with a cron job

   crontab -e
   # Add this line to create daily backups
   0 3 * * * docker exec redis redis-cli -a your_strong_redis_password SAVE

Step 9: Monitoring Redis

To monitor your Redis instance:

docker exec -it redis redis-cli -a your_strong_redis_password INFO

This provides comprehensive information about your Redis server, including memory usage, client connections, and persistence status.

Conclusion

You've successfully deployed Redis using Docker with data persistence and remote connectivity. This containerized approach offers flexibility, isolation, and easy management of your Redis instance.

Whether you're using Redis as a cache, message broker, or primary database, this setup provides a solid foundation for your applications.

Remember to adjust configurations based on your specific requirements and regularly monitor your Redis instance for optimal performance.

Happy caching!

Note: Always replace placeholder values like your_strong_redis_password and your_server_ip with your actual secure credentials and server information.

Installing MongoDB Using Docker: A Complete Guide

Yousuf Basir — Fri, 14 Mar 2025 19:02:21 +0000

Docker provides an excellent way to run MongoDB without installing it directly on your system. This approach offers better isolation, easier version management, and simpler setup. In this guide, I'll walk you through setting up MongoDB with Docker, including common pitfalls and their solutions.

Prerequisites

Docker installed on your system
Basic knowledge of terminal/command line
Root or sudo access to your machine

Step 1: Pull the MongoDB Image

First, pull the latest MongoDB image from Docker Hub:

docker pull mongo:latest

This command downloads the official MongoDB image maintained by MongoDB, Inc.

Step 2: Create Directories for Persistent Storage

Before running MongoDB, you need to create directories for persistent data storage:

mkdir -p ~/mongodb_data
mkdir -p ~/mongodb_backup

Step 3: Set Proper Permissions

This is a critical step that many guides miss! MongoDB inside the container runs as a non-root user (typically with UID 999), and it needs proper permissions to write to the mounted volumes:

# Set ownership to the MongoDB user (typically 999:999 in the container)
sudo chown -R 999:999 ~/mongodb_data
sudo chown -R 999:999 ~/mongodb_backup

# Set restrictive permissions for security
sudo chmod 700 ~/mongodb_data
sudo chmod 700 ~/mongodb_backup

Skipping this step is a common cause of authentication failures and connection issues.

Step 4: Run MongoDB Container

Now, run the MongoDB container with the following parameters:

docker run -d \
  --name mongodb \
  -p 27017:27017 \
  -v ~/mongodb_data:/data/db \
  -v ~/mongodb_backup:/backup \
  -e MONGO_INITDB_ROOT_USERNAME=admin \
  -e MONGO_INITDB_ROOT_PASSWORD=yoursecurepassword \
  --restart always \
  mongo:latest

Let's break down this command:

-d: Runs the container in detached mode (background)
--name mongodb: Names the container "mongodb" for easy reference
-p 27017:27017: Maps the container's port 27017 to the host's port 27017
-v ~/mongodb_data:/data/db: Mounts the local directory for persistent data storage
-v ~/mongodb_backup:/backup: Mounts a directory for database backups
-e MONGO_INITDB_ROOT_USERNAME=admin: Sets the root username
-e MONGO_INITDB_ROOT_PASSWORD=yoursecurepassword: Sets the root password
--restart always: Ensures the container restarts automatically with the system
mongo:latest: Specifies the image to use

Step 5: Verify the Installation

Check if the container is running properly:

docker ps | grep mongodb

You should see your MongoDB container in the list.

Step 6: Connect to MongoDB

Connect to your MongoDB instance using the MongoDB shell:

docker exec -it mongodb mongosh admin --username admin --password yoursecurepassword --authenticationDatabase admin

If you successfully connect, you'll see the MongoDB shell prompt.

Troubleshooting Common Issues

1. Authentication Failed Error

If you see MongoServerError: Authentication failed, check:

Whether you're using the correct username and password
If the container has fully initialized (check logs with docker logs mongodb)
The permissions on your data directory

2. Permission Issues with Mounted Volumes

This is the most common problem when setting up MongoDB with Docker. If MongoDB can't write to the mounted volumes properly, it will fail to initialize or authenticate.

The solution is to correctly set ownership and permissions as shown in Step 3.

3. Container Won't Start or Keeps Restarting

Check the logs:

docker logs mongodb

Look for specific error messages related to permissions, port conflicts, or other initialization issues.

Backing Up Your MongoDB Database

To create a backup:

docker exec -it mongodb mongodump --username admin --password yoursecurepassword --authenticationDatabase admin --out /backup/$(date +%Y%m%d)

This command will create a backup in your ~/mongodb_backup directory with the current date as the folder name.

Restoring a Backup

To restore from a backup:

docker exec -it mongodb mongorestore --username admin --password yoursecurepassword --authenticationDatabase admin /backup/20250323

Replace 20250323 with the actual backup folder name.

Conclusion

Docker provides a clean, isolated environment for running MongoDB without the complexity of a direct installation. By following these steps—especially the often-overlooked permission settings—you can have a robust MongoDB instance running in minutes.

The key lessons:

Always set proper permissions on mounted volumes
Use meaningful container names for easy management
Implement persistent storage for data safety
Configure authentication for security

With this setup, you have a production-ready MongoDB instance that's easy to maintain, backup, and upgrade.

Never Type Your SSH Password Again: A Complete Guide to SSH Key Authentication

Yousuf Basir — Sun, 17 Nov 2024 10:59:56 +0000

Are you tired of typing your password every time you connect to a remote server via SSH? In this guide, I'll show you how to set up SSH key-based authentication, a more secure and convenient way to connect to your servers.

What is SSH Key Authentication?

Before diving into the setup, let's understand what SSH keys are. Think of SSH keys as a pair of locks and keys:

You have a public key (the lock) that you put on the server
You keep a private key (the key) on your computer
When you connect, your private key proves your identity to the server without needing a password

Step-by-Step Setup Guide

1. Generate Your SSH Key Pair

First, you'll need to create your SSH key pair. Open your terminal and run:

ssh-keygen -t ed25519

When you run this command:

It will ask where to save the key (press Enter for default location)
It will ask for a passphrase (press Enter twice for no passphrase)
The default location is ~/.ssh/id_ed25519 (private key) and ~/.ssh/id_ed25519.pub (public key)

💡 Pro Tip: Using ed25519 is recommended as it's more secure and modern than older alternatives like RSA.

2. Copy Your Public Key to the Server

There are two ways to do this:

Method 1: Using ssh-copy-id (Recommended)

ssh-copy-id username@remote_host

This is the easiest method as it handles everything automatically.

Method 2: Manual Copy

If ssh-copy-id isn't available, you can do it manually:

cat ~/.ssh/id_ed25519.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

3. Set Proper Permissions

SSH is particular about security permissions. On the remote server, run:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Troubleshooting

If you're still being prompted for a password, check these common issues:

File Permissions: Incorrect permissions are a common cause. Double-check them:

   ls -la ~/.ssh

SSH Server Configuration: Ensure key authentication is enabled in /etc/ssh/sshd_config:

   PubkeyAuthentication yes

SELinux/AppArmor: If you're using these security systems, they might be blocking key authentication.

Security Best Practices

Use Strong Keys: Always use ED25519 or RSA with at least 4096 bits
Protect Your Private Key: Never share your private key or upload it anywhere
Consider Using a Passphrase: For additional security, add a passphrase to your key
Regular Key Rotation: Consider generating new keys periodically

Additional Tips

Creating Configuration Shortcuts

You can make SSH even more convenient by adding entries to your ~/.ssh/config file:

Host myserver
    HostName server.example.com
    User username
    IdentityFile ~/.ssh/id_ed25519

Then you can simply type:

ssh myserver

Using SSH Agent

If you do use a passphrase, you can avoid typing it repeatedly by using ssh-agent:

eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519

Conclusion

Setting up SSH key authentication is a one-time investment that pays off in both security and convenience. No more password prompts, and you get better security! It's a win-win situation.

Remember: while this setup is more convenient, it's crucial to keep your private key secure. If someone gets access to your private key, they can access all servers that trust that key.

Last updated: November 2024

Allow remote access to postgresql database

Yousuf Basir — Sat, 22 Jun 2024 15:35:33 +0000

Allowing remote access to your PostgreSQL database can be necessary for various reasons, such as connecting from different servers or enabling remote management.

Step 1: Modify the PostgreSQL Configuration File

First, you need to modify the PostgreSQL configuration file to allow connections from remote hosts. This file is typically located in /etc/postgresql/<version>/main/postgresql.conf. Replace <version> with your PostgreSQL version number.

For example, if you are using PostgreSQL version 13, you would run:

sudo nano /etc/postgresql/13/main/postgresql.conf

Locate the following line:

#listen_addresses = 'localhost'

Uncomment this line and change 'localhost' to '*' to allow connections from any IP address:

listen_addresses = '*'

Step 2: Configure Client Authentication

Next, you need to configure PostgreSQL to accept remote connections by editing the pg_hba.conf file, which controls client authentication.

Open the pg_hba.conf file:

sudo nano /etc/postgresql/13/main/pg_hba.conf

Add the following line at the end of the file to allow connections from any IP address using MD5 password authentication:

host    all             all             0.0.0.0/0               md5

Step 3: Restart PostgreSQL Service

For the changes to take effect, you need to restart the PostgreSQL service. Use the following command:

sudo systemctl restart postgresql

Step 4: Configure Your Firewall

Ensure your firewall allows incoming connections on PostgreSQL's default port (5432). If you are using UFW (Uncomplicated Firewall), you can allow connections to this port by running:

sudo ufw allow 5432/tcp

Step 5: Verify Remote Access

To verify that your PostgreSQL database is accessible remotely, you can use a PostgreSQL client tool like psql from a remote machine. For example:

psql -h <your_server_ip> -U <your_username> -d <your_database>

Replace <your_server_ip>, <your_username>, and <your_database> with your server’s IP address, PostgreSQL username, and database name, respectively.

Security Considerations

Allowing remote access to your PostgreSQL database opens up potential security risks. Here are a few best practices to mitigate these risks:

Use Strong Passwords: Ensure that all your PostgreSQL user accounts have strong passwords.
Restrict IP Addresses: Instead of allowing connections from any IP address, restrict access to specific IP addresses or ranges by modifying the pg_hba.conf file.
Enable SSL: Configure PostgreSQL to use SSL for encrypted connections.
Regular Updates: Keep your PostgreSQL installation and all related packages up to date to ensure you have the latest security patches.

Conclusion

By following these steps, you can configure your PostgreSQL database to allow remote connections. Always remember to balance accessibility with security to protect your data. With the proper configuration and security measures, remote access can be both convenient and safe.

Setting Up Nginx with Certbot for HTTPS on Your Web Application

Yousuf Basir — Sat, 22 Jun 2024 14:18:05 +0000

Securing your web application with HTTPS is crucial for protecting data integrity and privacy. This guide will walk you through the steps to set up Nginx as a reverse proxy and use Certbot to obtain a free SSL certificate from Let's Encrypt.

Prerequisites

Before you begin, ensure you have the following:

A domain name pointing to your server's IP address.
A server running Ubuntu (or any other Linux distribution).
Nginx installed on your server.

Step 1: Configure Nginx

First, we need to set up Nginx to proxy requests to our web application. Open your Nginx configuration file or create a new one for your domain:

sudo nano /etc/nginx/sites-available/my.website.com

Add the following configuration:

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

  server_name my.website.com www.my.website.com;

  location / {
    proxy_pass http://localhost:5173;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

This configuration listens for HTTP requests on port 80 and proxies them to your web application running on localhost:5173.

Step 2: Enable the Nginx Configuration

Create a symbolic link to enable the configuration:

sudo ln -s /etc/nginx/sites-available/my.website.com /etc/nginx/sites-enabled/

Test the Nginx configuration for syntax errors:

sudo nginx -t

If the test is successful, reload Nginx to apply the changes:

sudo systemctl reload nginx

Step 3: Install Certbot

Certbot is a tool that automates the process of obtaining and renewing SSL certificates from Let's Encrypt. Install Certbot and the Nginx plugin:

sudo apt update
sudo apt install certbot python3-certbot-nginx

Step 4: Obtain an SSL Certificate

Run Certbot to obtain an SSL certificate and configure Nginx to use it:

sudo certbot --nginx

Follow the interactive prompts. Certbot will:

Detect your Nginx configuration.
Allow you to select the domain you want to secure.
Automatically obtain and install the SSL certificate.
Modify your Nginx configuration to redirect HTTP traffic to HTTPS.

Certbot will update your Nginx configuration to something like this:

server {
  listen 80;
  listen [::]:80;
  server_name my.website.com www.my.website.com;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;

  server_name my.website.com www.my.website.com;

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

  location / {
    proxy_pass http://localhost:5173;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
}

Step 5: Verify HTTPS

After Certbot completes, verify that your site is accessible via HTTPS by navigating to your website url (e.g. https://my.website.com ) in your browser.

Conclusion

You have successfully set up Nginx as a reverse proxy for your web application and secured it with an SSL certificate from Let's Encrypt using Certbot. This setup not only secures your web application but also improves its trustworthiness and SEO ranking.

For further reading and additional configurations, you may refer to the following resources:

Automating Next.js Application Deployment with GitHub Actions

Yousuf Basir — Thu, 28 Sep 2023 18:17:47 +0000

Are you ready to supercharge your Next.js application deployment? With GitHub Actions, the process becomes a breeze, and I'm here to guide you through it step by step. Even if you're new to this, don't worry! We'll make it easy and fun.

Step 1: Setting Up Secrets

The first thing you need to do is head over to your GitHub repository. From there, navigate to "Secrets and Variables" under the "Actions" tab. We'll set up three secrets that will help automate our deployment:

HOST: This is your server's IP address.
USERNAME: Enter your server's username.
SSH_PRIVATE_KEY: See step 2 and 3

Don't fret; it's easier than it sounds. These secrets will allow GitHub Actions to securely communicate with your server.

Step 2: Generating an SSH Key

Now, let's generate an SSH key. SSH keys are like digital fingerprints that help authenticate your server and GitHub. Open your terminal and follow these simple commands:

cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C "youremail@email.com"

The -t flag is for specifying type of key. Here we are generating RSA key
- The -b flag sets the key length, which determines the key's strength. Here we are generating 4096 bit key
- The -c flag is is used to add a comment or label to the key. It's not required but can be helpful for identifying the key's purpose or owner.

You'll be prompted to name your key. Let's call it github_action and you can leave the passphrase empty.

Step 3: Adding the Public Key to GitHub

Run ls, and you'll see two newly generated files: github_action and github_action.pub. Run:

cat github_action

This will display your private key. Copy the content and head back to your repository settings, specifically "Secrets and Variables" under "Actions." Add the private key content to the SSH_PRIVATE_KEY secret.

Step 4: Adding the Private Key to GitHub Secrets

We're almost there!
Back in your terminal, let's copy the public key:

cat github_action.pub

Now, go to your GitHub repository settings and select "SSH and GPG Keys" from the left navigation bar. Click "New SSH Key" and paste your public key. This step allows your server to communicate securely with your GitHub repository.

Step 5: Authorizing Your Public Key on the Server

Now, let's make sure your server recognizes your public key. Run this command on your server:

cat github_action.pub >> authorized_keys

This command appends your public key to the list of authorized keys on your server, granting access for automated deployments.

Step 6: Creating GitHub Actions Workflow

The final step is to automate the deployment process. Create a GitHub Actions workflow by adding an action YAML file inside the .github/workflows directory in your repository.

Specify the event name as "push," define the branch name, and outline the action steps in your workflow script. This tells GitHub Actions when to trigger automatic deployments.

Here is an example GitHub Action for automating Next.js deployment. Customize with your repository name, branch name, application directory, and PM2 service name on your server

name: Deployment Workflow

# Trigger this workflow on pushes to the specified branch
on:
  push:
    branches:
      - your-branch-name

jobs:
  deploy:
    runs-on: ubuntu-latest

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

      - name: Install dependencies
        run: npm install

      - name: Build Next.js app
        run: npm run build

      - name: SSH Deploy
        # Use the 'appleboy/ssh-action' action for SSH deployment
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.HOST }} # Your server's IP address
          username: ${{ secrets.USERNAME }} # Your server's username
          key: ${{ secrets.SSH_PRIVATE_KEY }} # Your server's SSH private key
          script: |
            cd /path/to/your/application/directory # Specify the path to your app directory on the server
            git pull
            npm install
            npm run build
            pm2 restart your-pm2-service-name # Replace with your PM2 service name

And that's it! 🚀

From now on, whenever you push changes to your specified branch, GitHub Actions will automatically kick off the deployment process.
Happy coding! ☕

DEV Community: Yousuf Basir

Secure Linux Server Setup & Application Deployment

What This Guide Is For

Core Security Philosophy

Step 1 — Create a Non-Root Admin User

Why?

Step 2 — Harden SSH Access

Generate SSH key (on your local machine)

Disable dangerous SSH options

Step 3 — Enable Firewall (UFW)

Step 4 — Install Docker (Admin User Only)

Step 5 — Run Databases Securely in Docker

Key rules for databases

Example: PostgreSQL (secure)

Step 6 — Access Databases via SSH Tunnel

Step 7 — One GitHub Deploy Key per Repository

Step 8 — Create a Service User (Per App)

Step 9 — Clone & Build as Admin User

Step 10 — Environment Variables (Build-time vs Runtime)

Special case: Next.js public environment variables

Next.js standalone build (required asset copy)

Step 11 — Transfer Ownership to Service User

Step 12 — Run the App with systemd (Hardened)

Step 13 — Static Frontend Builds (React / Vite)

Injecting environment variables at build time

Granting Caddy read access

Step 14 — Reverse Proxy Configuration (Caddy)

Example: Node.js app running via systemd

Example: Static frontend site

Why this architecture matters

Step 15 — Updating an App Safely

What This Setup Protects Against

Final Thoughts

Securely Managing GitHub Access on Production Servers

Why This Matters

Core Rules

Step 1 — Generate a Deploy Key (Server Side)

Step 2 — Configure an SSH Alias

Step 3 — Add the Deploy Key to GitHub

Step 4 — Clone Using the SSH Alias (Not HTTPS)

Step 5 — Consistent Naming (Strongly Recommended)

Why This Setup Is Secure

How This Fits Into a Secure Deployment Workflow

Final Thoughts

Introduction to Satellite Remote Sensing and Vegetation Indices

🛰️ How Do Satellites Capture Images from Space?

🌱 Key Vegetation and Water Indices

📊 What Can We Learn from These Indices?

📡 Which Satellites Provide These Indices?

✅ Conclusion

A Beginner’s Guide to Satellite Data and Vegetation Indices (NDVI, EVI & Beyond)

Introduction

1. What Satellites Actually Capture

2. From Grayscale to Color Composites

3. What Are Vegetation Indices?

NDVI (Normalized Difference Vegetation Index)

EVI (Enhanced Vegetation Index)

Other Indices

4. Why Do NDVI Maps Look So Colorful?

5. One Sensor, Many Indices

6. Why This Matters

7. Next Steps for Beginners

Conclusion

Managing Multiple SSH Servers Across Windows & macOS with SSH Config & Tmux

1. Install OpenSSH

2. Use ~/.ssh/config for Profiles

3. Handling Password Servers

4. Speed Up Connections with Multiplexing

5. Keep Sessions Alive with tmux

6. Sync Configs Between Machines

✅ Final Thoughts

Fixing “Service Account Key Creation is Disabled” in Google Cloud Console

Understanding the Problem

Why Both Policies Matter

Diagnosing the Issue

Fixing the Policy

Step 1 — Make Sure You Have the Right Role

Step 2 — Override the Managed Constraint

Step 3 — Override the Legacy Constraint

Step 4 — Ensure Project Access

2. Use `~/.ssh/config` for Profiles

5. Keep Sessions Alive with `tmux`