DEV Community: Udara Dananjaya

🔐 Running a Persistent Database SSH Tunnel as a Windows Service (SSH & Plink)

Udara Dananjaya — Thu, 12 Mar 2026 05:04:14 +0000

When working with private cloud infrastructure, databases are often not directly accessible from the internet. Instead, access is allowed through a bastion host (jump server).

A common solution is to create an SSH tunnel that securely forwards a local port to the remote database.

However, running the tunnel manually every time can be inconvenient. A better approach is to run the tunnel as a Windows service, so it automatically starts and runs in the background.

This guide explains how to create a persistent database tunnel on Windows using:

🔹 SSH client
🔹 Plink (PuTTY command-line tool)
🔹 Windows Service Control (sc)

🧠 Understanding SSH Tunneling

An SSH tunnel securely forwards network traffic through an encrypted SSH connection.

Example architecture:

Local Application
        │
        │ localhost:1522
        ▼
SSH Tunnel
        │
        ▼
Bastion Server
        │
        ▼
Remote Database (database.internal:1521)

Your application connects to localhost, while the SSH tunnel securely forwards traffic to the remote database.

🖥 Example SSH Tunnel Command

ssh -N -i key.pem -L localhost:1522:database.internal:1521 -o ServerAliveInterval=15 -o ServerAliveCountMax=3 user@bastion-host

Parameter Explanation

ssh
🔹 Secure Shell client used to establish encrypted connections.

-N
🔹 Do not execute remote commands.
Useful when SSH is used only for tunneling.

-i key.pem
🔹 Specifies the private key file used for authentication.

-L localhost:1522:database.internal:1521
🔹 Creates a local port forwarding rule.

Breakdown:

localhost
🔹 Bind the tunnel to the local machine.

1522
🔹 Local port used by applications.

database.internal
🔹 Remote database host reachable from the SSH server.

1521
🔹 Database service port.

-o ServerAliveInterval=15
🔹 Sends keep-alive packets every 15 seconds.

-o ServerAliveCountMax=3
🔹 SSH closes the connection after 3 failed keep-alive checks.

user@bastion-host
🔹 SSH login user and bastion host address.

⚙ Creating a Windows Service for the Tunnel

Windows includes a built-in tool called Service Control (sc) that allows you to create and manage services.

To create a service that runs the SSH tunnel:

sc create DatabaseTunnel binPath= "cmd.exe /c ssh -N -i C:\keys\key.pem -L localhost:1522:database.internal:1521 -o ServerAliveInterval=15 -o ServerAliveCountMax=3 user@bastion-host" start= auto

Explanation

sc create
🔹 Creates a new Windows service.

DatabaseTunnel
🔹 Service name.

binPath=
🔹 The command executed by the service.

cmd.exe /c
🔹 Runs the command through the Windows command interpreter.

start= auto
🔹 Starts the service automatically when Windows boots.

⚠ Important rule:

There must always be a space after = in sc commands.

🔧 Starting and Managing the Service

Start the tunnel service:

sc start DatabaseTunnel

Stop the service:

sc stop DatabaseTunnel

Delete the service:

sc delete DatabaseTunnel

🔌 Connecting to the Database

After the service starts, applications can connect using the local port.

Example connection:

Host
localhost

Port
1522

The SSH tunnel automatically forwards the connection to the remote database.

🧰 Alternative Method Using Plink (PuTTY)

Another common approach on Windows is using PuTTY's command-line tool called **Plink.

Plink is lightweight and widely used in automation scripts.

Example Plink Tunnel Command

plink -ssh -i key.ppk -N -L localhost:1522:database.internal:1521 user@bastion-host

Parameter Explanation

plink
🔹 Command-line SSH client from PuTTY.

-ssh
🔹 Specifies that the connection should use SSH.

-i key.ppk
🔹 Private key file in PuTTY .ppk format.

-N
🔹 Do not start a remote shell.

-L localhost:1522:database.internal:1521
🔹 Local port forwarding configuration.

user@bastion-host
🔹 SSH login credentials.

Creating a Windows Service Using Plink

sc create DatabaseTunnel binPath= "cmd.exe /c plink -ssh -i C:\keys\key.ppk -N -L localhost:1522:database.internal:1521 user@bastion-host" start= auto

This will start the tunnel automatically when the system boots.

🚀 Advantages of Running the Tunnel as a Service

Running the tunnel as a Windows service provides several benefits:

✔ Automatic startup after system reboot
✔ No manual SSH commands required
✔ Stable persistent database connection
✔ Easy management using Windows tools
✔ Works well for CI/CD and automation servers

📌 Final Thoughts

SSH tunnels provide a secure and flexible way to access private databases without exposing them to the public internet.

By running the tunnel as a Windows service, you can ensure the connection remains available even after system restarts.

This technique is especially useful for:

🔹 Development environments
🔹 Secure database access
🔹 DevOps automation
🔹 Cloud infrastructure management

With just a few commands, you can transform a simple SSH tunnel into a reliable background service on Windows.

How to Use a Public GitHub Repository as a Maven Dependency

Udara Dananjaya — Sun, 14 Dec 2025 11:36:05 +0000

Apache Maven is the backbone of most Java projects, and GitHub Packages provides a convenient way to host and distribute Maven artifacts. Even when your repository is public, there are a few important steps required to make everything work smoothly.

In this article, we’ll walk through how to configure Maven to consume a public package from GitHub Packages, step by step.

Why GitHub Packages for Maven?

GitHub Packages allows you to:

Host Maven artifacts alongside your source code
Control access to packages
Keep dependencies close to your repositories
Integrate seamlessly with GitHub Actions

One important thing to note upfront:
👉 GitHub Packages requires authentication even for public Maven packages.

Prerequisites

Before you begin, make sure you have:

A GitHub account
A public repository that publishes Maven packages
Maven installed locally
Basic familiarity with pom.xml

Step 1: Create a GitHub Personal Access Token (PAT)

GitHub Packages only supports classic personal access tokens.

Create a token with the following scope:

read:packages (required to download packages)

If you plan to publish packages as well, also include:

write:packages

Keep this token safe — you’ll use it as your Maven password.

Step 2: Authenticate Maven with GitHub Packages

Maven reads credentials from the ~/.m2/settings.xml file.

Create or edit this file:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                              http://maven.apache.org/xsd/settings-1.0.0.xsd">

  <servers>
    <server>
      <id>github</id>
      <username>YOUR_GITHUB_USERNAME</username>
      <password>YOUR_PERSONAL_ACCESS_TOKEN</password>
    </server>
  </servers>

</settings>

📌 The <id> value (github) is important — Maven will use it to match credentials with repositories.

Step 3: Add the GitHub Maven Repository

Now tell Maven where to find the packages.

Option 1: Use a specific repository

Add this to your project’s pom.xml:

<repositories>
  <repository>
    <id>github</id>
    <url>https://maven.pkg.github.com/OWNER/REPOSITORY</url>
  </repository>
</repositories>

Example:

https://maven.pkg.github.com/mewan/my-public-repo

⚠️ GitHub requires the repository owner name to be lowercase, even if the actual username contains uppercase letters.

Option 2: Use all repositories under an owner

If you consume multiple packages from the same GitHub user or organization:

<repositories>
  <repository>
    <id>github</id>
    <url>https://maven.pkg.github.com/OWNER/*</url>
  </repository>
</repositories>

This approach is often more flexible.

Step 4: Add the Dependency

Once the repository is configured, add the dependency like any other Maven artifact:

<dependencies>
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>my-library</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

Make sure:

The package version exists in GitHub Packages
The artifactId is lowercase (GitHub enforces this)

Step 5: Build the Project

Run Maven as usual:

mvn clean install

If authentication and configuration are correct, Maven will download the package from GitHub Packages and include it in your build.

Common Pitfalls

Here are a few common issues developers run into:

❌ Assuming public packages don’t need authentication
❌ Mismatched <id> values between settings.xml and pom.xml
❌ Using uppercase letters in artifactId
❌ Incorrect GitHub Packages URL

Double-checking these details can save a lot of time.

Final Thoughts

Using GitHub Packages as a Maven registry is a powerful way to manage dependencies, especially when your code already lives on GitHub. While the authentication requirement for public packages may feel surprising, once configured, the workflow is smooth and reliable.

If you’re already using GitHub Actions, this setup integrates nicely into CI/CD pipelines as well.

Happy coding 🚀

Automating Vue.js App Deployment to Firebase Hosting with GitHub Actions Without npm firebase-tools

Udara Dananjaya — Mon, 27 Oct 2025 05:51:23 +0000

Deploying a web app efficiently is a game-changer for developers. For my financial project management system (PMS) built with Vue.js, I wanted to streamline deployments using Firebase Hosting and GitHub Actions, but without relying on the firebase-tools npm package for initialization. This approach is useful if you want to avoid installing additional npm dependencies or prefer manual configuration for more control. Below, I’ll walk you through the process I used to set up automated deployments, leveraging GitHub Actions for CI/CD and Firebase Hosting for a fast, scalable static site.

This guide assumes you’re comfortable with GitHub, Firebase, and basic terminal commands, and it mirrors the steps I took to achieve a seamless pipeline. We’ll manually configure Firebase, set up GitHub Actions workflows, and automate builds and deployments—all without npm install firebase-tools.

Prerequisites

Before starting, ensure you have:

Node.js and npm installed (for building your app, e.g., npm run build).
A GitHub repository for your project (mine is a Vue.js app, but this works for any static site).
A Firebase project created in the Firebase Console.
Your app’s build output in a dist folder (common for Vue CLI projects).
A local Git repository synced with GitHub.
A Firebase service account JSON key (downloadable from Firebase Console).

Step 1: Set Up Firebase Hosting Manually

Without the Firebase CLI, we’ll configure Firebase Hosting by creating the necessary files manually.

Create `firebase.json`

In your project root (e.g., the deployment folder), create a firebase.json file to define Hosting settings. For a Vue.js single-page app (SPA), I used:

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

public: Specifies the dist folder, where npm run build outputs your app.
ignore: Excludes files from deployment (e.g., config and hidden files).
rewrites: Routes all URLs to index.html for SPA functionality.

Create `.firebaserc`

To link your project to Firebase, create a .firebaserc file in the root:

{
  "projects": {
    "default": "your-project-id"
  }
}

Replace your-project-id with your Firebase project ID from the Firebase Console (e.g., finagle-pms-test in my case). You can find it under Project settings > General.

Update `.gitignore`

Add Firebase-related files to .gitignore to avoid committing sensitive data:

.firebase/
firebaserc
node_modules/

If .gitignore doesn’t exist, create it. This ensures your local Firebase cache and node modules aren’t pushed to GitHub.

Generate a Service Account Key

Go to the Firebase Console.
Navigate to Project settings > Service accounts.
Click Generate new private key to download a JSON file (e.g., your-project-id-firebase-adminsdk-xyz.json).
Store this securely—you’ll need it for GitHub Actions.

Step 2: Test Your Build Locally

Ensure your app builds correctly:

npm run build

This should generate a dist folder with your static assets (e.g., index.html, JS, and CSS files). If you’re using Vue CLI, this is typically configured out of the box. Verify dist/index.html exists, as Firebase Hosting will serve it.

Step 3: Set Up GitHub Actions for CI/CD

Without firebase-tools, we’ll manually create GitHub Actions workflows to build and deploy to Firebase Hosting. These workflows will handle pull request previews and live deployments on merge.

Add Service Account Key to GitHub Secrets

Go to your GitHub repository: https://github.com/your-org/your-repo.
Navigate to Settings > Secrets and variables > Actions > New repository secret.
Name the secret FIREBASE_SERVICE_ACCOUNT_YOUR_PROJECT_ID (replace YOUR_PROJECT_ID with your Firebase project ID, e.g., FINAGLE_PMS_TEST).
Paste the entire JSON content of the service account key you downloaded.

Create Workflow for Pull Requests

In your project root, create a folder: .github/workflows/firebase-hosting-pull-request.yml. Add:

name: Deploy to Firebase Hosting on PR

on:
  push:
    branches:
      - master  # Deploy to live when changes are pushed to master
  pull_request:
    branches:
      - master  # Deploy to preview on PRs targeting master
permissions:
  checks: write
  contents: read
  pull-requests: write

jobs:
  build_and_deploy‎:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_YOUR_PROJECT_ID }}'
          projectId: your-project-id
  # Conditional for the event type
          channelId: ${{ github.event_name == 'push' && 'live' || 'pr' }}  # 'live' for push to master, 'pr' for pull request

Replace your-project-id with your Firebase project ID. This workflow:

Triggers on pull requests to the master branch.
Checks out code, sets up Node.js, installs dependencies, and builds the app.
Deploys to a Firebase Hosting preview channel using the service account.

Create Workflow for Live Deployment

Create another file: .github/workflows/firebase-hosting-merge.yml:

name: Deploy to Firebase Hosting on merge
'on':
  push:
    branches:
      - master
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_YOUR_PROJECT_ID }}'
          channelId: live
          projectId: your-project-id

This triggers on pushes to master, deploying to the live Firebase Hosting channel.

Step 4: Push and Test the Workflows

Commit and push your changes:

git add .
git commit -m "Add Firebase Hosting config and GitHub Actions workflows"
git push origin master

Create a feature branch and open a pull request. Check the Actions tab in your GitHub repo to see the PR workflow run. It will:

Build your app (npm run build).
Deploy to a Firebase Hosting preview URL (visible in the Action logs).

Merge the PR, and the merge workflow will deploy to the live site.

Step 5: Verify Deployment

After the workflows run:

Preview: Find the preview URL in the GitHub Actions logs (e.g., https://your-project-id--preview-channel.web.app).
Live: Visit your live site (e.g., https://your-project-id.web.app) after merging.

Ensure your Vue.js app loads correctly, with all routes handled by index.html.

Troubleshooting

Build fails? Verify npm run build works locally and outputs to dist.
Secret errors? Double-check the service account key in GitHub Secrets.
404 on routes? Confirm the rewrites rule in firebase.json.
Permission issues? Ensure the service account has Firebase Hosting Admin permissions in the Firebase Console.
Vue-specific: If using environment variables, add them to GitHub Secrets and reference them in the workflow (e.g., env: VUE_APP_API_KEY: ${{ secrets.VUE_APP_API_KEY }}).

Why This Approach Wins

This setup streamlined my PMS deployments without relying on firebase-tools. It’s lightweight, avoids extra npm dependencies, and gives you full control over configuration. Firebase Hosting offers a global CDN, free SSL, and generous free tier, while GitHub Actions provides cost-free CI/CD for public repos. Previews on PRs catch issues early, and live deploys are instant on merge.

Try this for your next project! What’s your favorite way to automate deployments? Share below.

Originally published on October 15, 2025. Crafted with Vue.js and Firebase Hosting.

Effortless Vue.js Deployment with Firebase Hosting and GitHub Actions (No firebase-tools)

Udara Dananjaya — Mon, 27 Oct 2025 05:07:08 +0000

Effortless Vue.js Deployment with Firebase Hosting and GitHub Actions

Deploying a web app shouldn’t feel like wrestling a bear. For my financial project management system (PMS) built with Vue.js, I wanted a fast, automated deployment pipeline using Firebase Hosting and GitHub Actions—without the firebase-tools npm package. This approach keeps things lightweight, skips extra dependencies, and gives you full control. Whether you’re deploying a Vue.js app or any static site (React, Angular, Svelte, you name it), this guide will get you a seamless CI/CD setup.

TL;DR

Set up automated deployments to Firebase Hosting using GitHub Actions, no firebase-tools required. Manually configure Firebase, create a single GitHub Actions workflow, and use a service account for preview and live deploys. Perfect for fast, cost-free pipelines.

Why This Setup?

Firebase Hosting offers a global CDN, free SSL, and a generous free tier (10GB storage, 360MB/day transfer). GitHub Actions provides 2,000 free CI/CD minutes/month for public repos. Together, they deliver instant previews on pull requests and live deploys on merge—all without installing extra npm packages.

Prerequisites

Node.js and npm (for npm run build).
A GitHub repo with a static site (e.g., Vue.js outputting to dist).
A Firebase project (Firebase Console).
A Firebase service account JSON key.
A local Git repo synced with GitHub.

Step 1: Configure Firebase Hosting Manually

No Firebase CLI? No problem. We’ll set up Hosting with two simple files.

Create `firebase.json`

In your project root, add firebase.json:

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

public: Points to your build output (dist for Vue CLI).
ignore: Skips config and hidden files.
rewrites: Routes all URLs to index.html for single-page apps.

Create `.firebaserc`

Link your project to Firebase:

{
  "projects": {
    "default": "your-project-id"
  }
}

Find your project ID in Firebase Console > Project settings > General (e.g., finagle-pms-test).

Update `.gitignore`

Add:

.firebase/
.firebaserc
node_modules/

This keeps sensitive files out of GitHub.

Get a Service Account Key

In Firebase Console, go to Project settings > Service accounts.
Click Generate new private key to download a JSON file (e.g., your-project-id-firebase-adminsdk-xyz.json).
Store it securely—you’ll need it for GitHub Actions.

Step 2: Test Your Build

Run:

npm run build

Check that it generates a dist folder with index.html and assets. This is your app’s static output, ready for Firebase Hosting.

Step 3: Set Up GitHub Actions CI/CD

We’ll use a single workflow to handle both pull request previews and live deploys.

Add Service Account to GitHub Secrets

Go to your GitHub repo: https://github.com/your-org/your-repo.
Navigate to Settings > Secrets and variables > Actions > New repository secret.
Name it FIREBASE_SERVICE_ACCOUNT_YOUR_PROJECT_ID (e.g., FIREBASE_SERVICE_ACCOUNT_FINAGLE_PMS_TEST).
Paste the service account JSON content.

Create Workflow

In .github/workflows/firebase-hosting.yml, add:

name: Deploy to Firebase Hosting

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

permissions:
  checks: write
  contents: read
  pull-requests: write

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_YOUR_PROJECT_ID }}'
          projectId: your-project-id
          channelId: ${{ github.event_name == 'push' && 'live' || 'pr-${{ github.event.number }}' }}

Replace your-project-id with your Firebase project ID. This workflow:

Triggers on pushes to main (live deploy) or pull requests (preview).
Builds your app (npm run build).
Deploys to Firebase Hosting: live site for pushes, unique preview channels (e.g., pr-123) for PRs.

Note: Use Node.js 20 or adjust node-version to match your app’s requirements.

Step 4: Push and Test

Commit and push:

git add .
git commit -m "Add Firebase Hosting and GitHub Actions CI/CD"
git push origin main

Create a pull request to test the preview deploy. Check the Actions tab in GitHub for logs. Merge the PR to deploy live.

Step 5: Verify Deployment

Preview: Find the preview URL in the GitHub Actions logs (e.g., https://your-project-id--pr-123.web.app).
Live: Visit your live site (e.g., https://your-project-id.web.app) after merging.

Ensure all routes load correctly, handled by index.html.

Troubleshooting

Build fails? Run npm run build locally to debug.
404 on routes? Verify rewrites in firebase.json.
Secret errors? Check the service account JSON in GitHub Secrets.
Permissions? Ensure the service account has Firebase Hosting Admin rights.
Environment variables? Add them to GitHub Secrets and reference in the workflow (e.g., env: VUE_APP_API_KEY: ${{ secrets.VUE_APP_API_KEY }}).

Why This Wins

This setup is lean, dependency-free, and cost-effective. Firebase’s free tier and GitHub Actions’ free minutes make it ideal for indie devs or small teams. Preview channels catch issues before they hit production, and live deploys are lightning-fast.

What’s your favorite deployment trick? Share your CI/CD setup in the comments!

Originally published on October 27, 2025. Built with Vue.js and Firebase Hosting.

Complete Guide: Automating Deployment with GitHub Webhooks, Nginx, and Shell Scripts

Udara Dananjaya — Mon, 27 Oct 2025 04:51:51 +0000

In this guide, we will walk through how to set up an automated deployment system for your project hosted on GitHub. By leveraging GitHub webhooks, nginx, curl, shell scripts, and systemd, we will create a deployment pipeline that automatically triggers the deployment of your application to a VPS whenever you push to your repository. This method requires no programming language and can be set up with basic configuration and shell scripts.

Setting Up GitHub Webhook
Configuring Your VPS
- Installing Nginx
- Creating the Webhook Handler Script
- Setting Up Nginx to Trigger the Webhook
Testing the Webhook Endpoint
Automating the Deployment
Monitoring Logs
Conclusion

1. Setting Up GitHub Webhook

Steps to Set Up the Webhook:

Go to your GitHub repository:
- Navigate to your GitHub repository.
- Go to the Settings tab.
Add a Webhook:
- Under Settings, scroll down to Webhooks and click Add Webhook.
Configure Webhook Settings:
- Payload URL: Set this to the URL where your VPS will listen for incoming requests. Example: http://your-vps-ip/webhook.
- Content Type: Choose application/json.
- Secret: Set a secret key to validate the authenticity of requests (e.g., my-secret-key).
- Events: Select the Push events option. This ensures that the webhook is triggered when a push is made to your repository.
- Click Add Webhook to save the configuration.

Now, your GitHub repository will send a payload to your VPS every time you push changes to the repository.

2. Configuring Your VPS

2.1 Installing Nginx (Web Server)

You need nginx to listen for incoming requests to the /webhook URL and trigger the webhook handler script.

Install nginx:

Run the following commands to install nginx if it is not already installed:

   sudo apt update
   sudo apt install -y nginx

Start and enable nginx:

Ensure nginx is running:

   sudo systemctl start nginx
   sudo systemctl enable nginx

Verify nginx installation:

You can verify nginx is running by visiting your VPS IP in a browser or running:

   sudo systemctl status nginx

2.2 Creating the Webhook Handler Script

This script will be responsible for handling the webhook requests and performing the necessary deployment actions, such as pulling the latest code from the GitHub repository, installing dependencies, and restarting the application.

Create the handler script:

Create a shell script, for example, /var/www/webhook-handler.sh:

   sudo nano /var/www/webhook-handler.sh

Add the following script content:

   #!/bin/bash

   # Log the webhook trigger
   echo "$(date): Webhook triggered" >> /var/log/webhook.log

   # Verify GitHub secret (for security)
   read -r body
   received_signature=$(echo "$body" | openssl dgst -sha256 -hmac "my-secret-key" | awk '{print $2}')
   github_signature=$(echo "$HTTP_X_HUB_SIGNATURE_256" | cut -d= -f2)

   if [[ "$received_signature" != "$github_signature" ]]; then
       echo "$(date): Invalid signature" >> /var/log/webhook.log
       exit 1
   fi

   # Run deployment commands
   cd /path/to/project || exit
   git pull origin development >> /var/log/webhook.log 2>&1
   npm install >> /var/log/webhook.log 2>&1
   npm run build >> /var/log/webhook.log 2>&1
   sudo systemctl restart your-app.service >> /var/log/webhook.log 2>&1

   echo "$(date): Deployment completed" >> /var/log/webhook.log

Replace /path/to/project with the actual directory path of your project on the VPS.
Replace your-app.service with the name of the systemd service managing your app (if using systemd).

Make the script executable:

   sudo chmod +x /var/www/webhook-handler.sh

2.3 Setting Up Nginx to Trigger the Webhook Script

Now, you will configure nginx to listen to the /webhook URL and trigger the handler script.

Open the nginx configuration:

Open the nginx configuration file to edit:

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

Add the following location block:

In the server block, add the following:

   location /webhook {
       alias /var/www/webhook-handler.sh;
       fastcgi_param HTTP_X_HUB_SIGNATURE_256 $http_x_hub_signature_256;
       include fastcgi_params;
       fastcgi_pass 127.0.0.1:9000;
   }

This tells nginx to trigger the webhook handler script when it receives a request at /webhook.

Reload nginx:

Apply the changes to nginx:

   sudo systemctl reload nginx

3. Testing the Webhook Endpoint

To verify that everything is set up correctly, you can send a test request to your webhook URL using curl.

Send a test request:

Replace your-vps-ip with your actual VPS IP address, and use your secret key:

   curl -X POST http://your-vps-ip/webhook -H "X-Hub-Signature-256: sha256=my-test-key" -d "{}"

Check the logs:

If everything is working correctly, you should see a log entry indicating that the webhook was triggered. Check the logs by running:

   tail -f /var/log/webhook.log

You should see entries like:

   Sat Dec 15 15:30:00 UTC 2024: Webhook triggered
   Sat Dec 15 15:30:10 UTC 2024: Deployment completed

4. Automating the Deployment

Once the webhook is triggered, the handler script will execute the following deployment steps:

Pull the latest code from the development branch.
Install dependencies (e.g., npm install).
Build the project (e.g., npm run build).
Restart the application using systemd (systemctl restart).

This entire process is automated, and the app will be deployed without any manual intervention once a push occurs on the GitHub repository.

5. Monitoring Logs

After deployment, you can monitor the logs for any issues or to ensure everything is running smoothly:

View the webhook log:

To monitor the output from the webhook handler script, you can run:

   tail -f /var/log/webhook.log

This will allow you to see real-time updates whenever a new deployment is triggered.

6. Conclusion

By following this guide, you have successfully set up an automated deployment pipeline using GitHub webhooks, nginx, curl, shell scripts, and systemd. This method allows you to deploy your application to a VPS automatically when changes are pushed to your GitHub repository, all without writing custom code.

This setup is ideal for developers who want to automate their deployments using a simple, effective, and low-code solution. It provides a streamlined process for ensuring that your application is always up to date and running smoothly on your server.

Setting Up a Secure Web Server Proxy

Udara Dananjaya — Mon, 27 Oct 2025 04:50:12 +0000

In secure environments, ensuring traffic is routed safely while maintaining HTTPS-only connections is critical. This guide outlines how to configure a web server to act as an intermediary, enabling secure public access to SSH and SCP services on an internal server.

Server Roles and Tools

Web Server: Acts as the gateway for public users. Runs both nginx and httpd for HTTPS handling and reverse proxy configurations.
Internal Server: Provides SSH access and also runs nginx and httpd for HTTPS services.

Flow Overview

Public User [HTTPS] ➔ Accesses the web server.
Web Server [HTTPS] ➔ Proxies traffic securely to the internal server.
Internal Server [SSH via localhost] ➔ Enables SSH and SCP access through the web server.

1. Configuring HTTPS on the Internal Server

1.1 Generate a Self-Signed SSL Certificate

If your internal server does not have an SSL certificate:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/internal_server.key -out /etc/ssl/certs/internal_server.crt

Place the certificate and key in secure directories like /etc/ssl/.

1.2 Configure Apache (`httpd`) for HTTPS

Edit the Apache configuration file:

sudo nano /etc/httpd/conf.d/ssl.conf

Add or modify the following:

<VirtualHost *:443>
    ServerName internal-server-ip
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/internal_server.crt
    SSLCertificateKeyFile /etc/ssl/private/internal_server.key

    <Directory /var/www/html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Restart the httpd service:

sudo systemctl restart httpd

1.3 Configure Nginx (Optional)

If using nginx on the internal server instead of Apache, configure it as follows:

server {
    listen 443 ssl;
    server_name internal-server-ip;

    ssl_certificate /etc/ssl/certs/internal_server.crt;
    ssl_certificate_key /etc/ssl/private/internal_server.key;

    location / {
        proxy_pass http://localhost:application_port;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Restart the nginx service:

sudo systemctl restart nginx

1.4 Restrict Access to the Internal Server

Use a firewall to allow only the web server to access the internal server:

sudo ufw allow from web-server-ip to any port 443
sudo ufw allow from web-server-ip to any port 22
sudo ufw enable

2. Configuring the Web Server as a Reverse Proxy

2.1 Install and Configure HTTPS

If nginx is not installed:

sudo apt update
sudo apt install nginx

Generate or install an SSL certificate for the web server:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/web_server.key -out /etc/ssl/certs/web_server.crt

2.2 Set Up the Reverse Proxy

Edit the Nginx configuration file:

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

Add the following:

server {
    listen 443 ssl;
    server_name web-server-ip;

    ssl_certificate /etc/ssl/certs/web_server.crt;
    ssl_certificate_key /etc/ssl/private/web_server.key;

    location / {
        proxy_pass https://internal-server-ip;
        proxy_ssl_verify off; # Optional for self-signed certs
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Enable the configuration:

sudo ln -s /etc/nginx/sites-available/reverse_proxy /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

3. Enabling SSH Access via the Web Server

3.1 Set Up an SSH Tunnel

On the internal server, establish a reverse SSH tunnel to the web server:

ssh -R 2222:localhost:22 user@web-server-ip

This forwards port 2222 on the web server to port 22 on the internal server.

3.2 Automate the Tunnel

To make the tunnel persistent, add the following to the internal server's SSH config (~/.ssh/config):

Host web-server
    HostName web-server-ip
    User user
    ServerAliveInterval 60
    RemoteForward 2222 localhost:22

3.3 Access the Internal Server via the Web Server

From a public machine, SSH into the internal server through the web server:

ssh -p 2222 user@web-server-ip

3.4 Transfer Files to the Internal Server Using SCP

To securely copy files to the internal server via the web server:

scp -P 2222 your_file user@web-server-ip:/path/on/internal-server

4. Accessing the Internal Server from Public Internet

To securely access the internal server from the public internet, always connect to the web server first via HTTPS. The web server proxies traffic to the internal server. For SSH and file transfer:

Establish a tunnel as described in Step 3.1.
Use the web server’s public-facing IP address and the specified port to access the internal server through SSH or SCP.

Security Best Practices

Restrict Access:
- Use firewalls to limit traffic between servers.
- Allow only trusted IPs to access the web server’s HTTPS port.
Use Strong SSL/TLS Configurations:
- Configure Nginx and Apache to use strong ciphers and protocols:
```
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!MD5;
```
Enable Logging:
- Monitor logs on both servers to detect suspicious activity:
  - Apache: /var/log/httpd/access_log
  - Nginx: /var/log/nginx/access.log

Setting Up a Secure Proxy for Web and App Servers

Udara Dananjaya — Mon, 27 Oct 2025 04:49:20 +0000

In modern web infrastructures, ensuring secure communication between servers is crucial, especially when dealing with sensitive environments. In this guide, we’ll walk through setting up a secure, HTTPS-based reverse proxy between a web server and an app server, while also enabling SSH and SCP access to the app server via the web server.

Server Roles and Tools

App Server: Hosts the application and has httpd (Apache) installed to handle HTTPS traffic. It also supports nginx for reverse proxy setups and provides SSH for administrative access.
Web Server: Acts as a gateway for public users. It runs nginx for reverse proxy and supports httpd for additional configurations.

Flow Overview

The communication flow for this setup is as follows:

Public User [HTTPS] ➔ Accesses the web server.
Web Server [HTTPS] ➔ Proxies traffic securely to the app server.
App Server [HTTPS] ➔ Handles application requests.
App Server [SSH as localhost] ➔ Provides secure administrative access via the web server.

Step 1: Setting Up HTTPS on the App Server

1.1 Generate a Self-Signed SSL Certificate

If your app server doesn’t already have an SSL certificate:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/app_server.key -out /etc/ssl/certs/app_server.crt

Place the certificate and key in secure directories, such as /etc/ssl/.

1.2 Configure Apache (`httpd`) for HTTPS

Edit the Apache configuration file:

sudo nano /etc/httpd/conf.d/ssl.conf

Add or modify the following:

<VirtualHost *:443>
    ServerName app-server-ip
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/app_server.crt
    SSLCertificateKeyFile /etc/ssl/private/app_server.key

    <Directory /var/www/html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Restart the httpd service:

sudo systemctl restart httpd

1.3 Configure Nginx (Optional)

If you prefer using nginx on the app server instead of Apache, configure it as follows:

server {
    listen 443 ssl;
    server_name app-server-ip;

    ssl_certificate /etc/ssl/certs/app_server.crt;
    ssl_certificate_key /etc/ssl/private/app_server.key;

    location / {
        proxy_pass http://localhost:your_application_port;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Restart the nginx service:

sudo systemctl restart nginx

1.4 Restrict Access to the App Server

Use a firewall to allow only the web server to access the app server’s HTTPS and SSH ports:

sudo ufw allow from web-server-ip to any port 443
sudo ufw allow from web-server-ip to any port 22
sudo ufw enable

Step 2: Configuring the Web Server as a Reverse Proxy

2.1 Install Nginx and Configure HTTPS

If not already installed:

sudo apt update
sudo apt install nginx

Generate or install an SSL certificate for the web server. For a self-signed certificate:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/web_server.key -out /etc/ssl/certs/web_server.crt

2.2 Set Up the Reverse Proxy

Edit the Nginx configuration:

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

Add the following:

server {
    listen 443 ssl;
    server_name web-server-ip;

    ssl_certificate /etc/ssl/certs/web_server.crt;
    ssl_certificate_key /etc/ssl/private/web_server.key;

    location / {
        proxy_pass https://app-server-ip;
        proxy_ssl_verify off; # Optional if using self-signed certs
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Enable the configuration:

sudo ln -s /etc/nginx/sites-available/reverse_proxy /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

Step 3: Enabling SSH Access to the App Server

Since direct SSH access to the app server isn’t exposed, use the web server as an intermediary.

3.1 Set Up an SSH Tunnel

On the app server, establish a reverse SSH tunnel to the web server:

ssh -R 2222:localhost:22 user@web-server-ip

This command forwards port 2222 on the web server to port 22 on the app server.

3.2 Automate the Tunnel

To make the tunnel persistent, add the following to the app server’s SSH config (~/.ssh/config):

Host web-server
    HostName web-server-ip
    User user
    ServerAliveInterval 60
    RemoteForward 2222 localhost:22

3.3 Access the App Server via the Web Server

From a public machine, SSH into the app server through the web server:

ssh -p 2222 user@web-server-ip

3.4 Transfer Files to the App Server Using SCP

To securely copy files to the app server via the web server:

scp -P 2222 your_file user@web-server-ip:/path/on/app-server

Step 4: Accessing the App Server from Public Internet

To securely access your app server from the public internet, always connect to the web server first via HTTPS. The web server handles all public traffic and securely proxies the requests to the app server. For SSH and file transfer:

Establish a tunnel as described in Step 3.1.
Use the web server’s public-facing IP address and specified port to access the app server through SSH or SCP.

Security Best Practices

Restrict Access:
- Use firewalls (ufw or iptables) to limit traffic between servers.
- Allow only trusted IPs to access the web server’s HTTPS port.
Use Strong SSL/TLS Configurations:
- Configure Nginx and Apache to use strong ciphers and protocols:
```
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!MD5;
```
Enable Logging:
- Monitor logs on both servers to detect suspicious activity.
  - Apache: /var/log/httpd/access_log
  - Nginx: /var/log/nginx/access.log
Regular Updates:
- Keep your servers and software updated to patch security vulnerabilities.
SSH Security:
- Use key-based authentication for SSH and disable password-based logins.
- Add this to /etc/ssh/sshd_config:
```
 PermitRootLogin no
 PasswordAuthentication no
```

Conclusion

This configuration ensures secure, encrypted communication between public users, the web server, and the app server. By leveraging HTTPS and reverse proxies, alongside SSH tunneling for administrative tasks, you can maintain a robust and secure infrastructure for sensitive environments. This setup also provides seamless SSH and SCP access to the app server via the web server, ensuring both security and usability.

Automating Deployment of Your Vue.js App to Firebase Hosting with GitHub Actions

Udara Dananjaya — Wed, 15 Oct 2025 12:20:44 +0000

In the fast-paced world of web development, efficiency is key. As a developer working on a Process management system (PMS) for a industrial application, I needed a reliable way to deploy updates seamlessly. Manually deploying changes to production can be error-prone and time-consuming. That's where continuous integration and deployment (CI/CD) comes in. By integrating Firebase Hosting with GitHub Actions, I set up an automated pipeline that builds and deploys my Vue.js app on every pull request and merge. This ensures previews for reviews and live updates without lifting a finger.

In this article, I'll walk you through the exact steps I followed to achieve this setup. We'll cover installing tools, authenticating with Firebase and GitHub, initializing the project, and configuring workflows. By the end, you'll have a fully automated deployment process for your own static web app.

Prerequisites

Before diving in, ensure you have:

Node.js and npm installed on your machine.
A GitHub account with a repository for your project (mine was a Vue.js-based PMS, but this works for any static site generator).
A Firebase project set up in the Firebase Console.
Your app built with a command like npm run build that outputs to a dist folder (common for Vue CLI projects).

If your project isn't already in a Git repository, initialize one with git init and push it to GitHub.

Step 1: Install Firebase Tools

Firebase CLI is the command-line interface that makes interacting with Firebase projects straightforward. Open your terminal in the project root directory (e.g., your deployment folder) and run:

npm install firebase-tools

This command installs the Firebase tools globally or locally. You'll see output like:

npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead
added 745 packages in 39s
81 packages are looking for funding
run `npm fund` for details

The deprecation warning is harmless—it's just advising on a minor dependency. Once installed, you're ready to authenticate.

Step 2: Authenticate with Firebase

Firebase requires authentication to manage projects. First, check your current login status:

npx firebase login

If you're already logged in (as I was initially), it will confirm that. To switch accounts or start fresh, log out:

npx firebase logout

+ Logged out from [your-previous-account]

Now, log in again:

npx firebase login

You'll encounter a few prompts during login:

Enable Gemini in Firebase features? This is an optional AI-powered feature for Firebase. I selected Yes to explore it, but choose based on your needs. Learn more about Gemini in Firebase.
Allow Firebase to collect CLI and Emulator Suite usage and error reporting information? This helps improve the tools. I selected Yes, in line with Google's privacy policy. You can always change this later by logging out and in again.

The CLI will open a browser for OAuth authentication. Visit the provided URL (something like https://accounts.google.com/o/oauth2/auth?...), sign in, and authorize. Success looks like:

Waiting for authentication...
+ Success! Logged in as [your-account]

Step 3: Initialize Firebase in Your Project

With authentication complete, initialize Firebase Hosting in your project directory:

npx firebase init

You'll see the Firebase ASCII art banner, followed by:

You're about to initialize a Firebase project in this directory: [your-project-path]
√ Are you ready to proceed? Yes

Select features using spacebar and Enter. For Hosting:

√ Which Firebase features do you want to set up for this directory?
Press Space to select features, then Enter to confirm your choices.
◉ Hosting: Set up deployments for static web apps

Project Setup

Associate your directory with a Firebase project:

=== Project Setup

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,

√ Please select an option: Use an existing project
√ Select a default Firebase project for this directory: [your-project-name] ([project-id])

I chose an existing test project for safety.

Hosting Setup

Configure the public directory—the folder containing your built assets:

=== Hosting Setup

Your public directory is the folder (relative to your project directory) that will contain Hosting assets to be uploaded with firebase deploy.
If you have a build process for your assets, use your build's output directory.

√ What do you want to use as your public directory? dist

For a single-page app (SPA) like Vue.js, rewrite all URLs to index.html to handle routing:

√ Configure as a single-page app (rewrite all urls to /index.html)? Yes

This generates a firebase.json file with:

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

Step 4: Set Up Automatic Builds and Deploys with GitHub

The magic of CI/CD happens here. Firebase CLI can automate this with GitHub Actions.

√ Set up automatic builds and deploys with GitHub? Yes

If your project isn't a Git repo yet:

+ Didn't detect a .git folder. Assuming [your-path] is the project root.

Authorize GitHub:

+ Authorizing with GitHub to upload your service account to a GitHub repository's secrets store.
Visit this URL on this device to log in: [github-oauth-url]
Waiting for authentication...
+ Success! Logged into GitHub as [your-github-username]

Specify your repository:

√ For which GitHub repository would you like to set up a GitHub workflow? (format: user/repository) [your-org/your-repo]

Firebase creates a service account with Hosting admin permissions and uploads it as a GitHub secret (FIREBASE_SERVICE_ACCOUNT_[PROJECT-ID]). Manage secrets at https://github.com/[user/repo]/settings/secrets.

Configure the build:

√ Set up the workflow to run a build script before every deploy? Yes
√ What script should be run before every deploy? npm run build

For live deploys:

+ Created workflow file [path]/.github/workflows/firebase-hosting-pull-request.yml
√ Set up automatic deployment to your site's live channel when a PR is merged? Yes
√ What is the name of the GitHub branch associated with your site's live channel? master
+ Created workflow file [path]/.github/workflows/firebase-hosting-merge.yml

The CLI also writes:

firebase.json and .firebaserc for config.
Updates .gitignore to exclude Firebase files.
Notes on revoking authorizations if needed.

Finally:

+ Firebase initialization complete!

Step 5: Push and Test the Workflows

Commit and push the new .github/workflows files to your repo:

git add .
git commit -m "Add Firebase Hosting CI/CD workflows"
git push origin master

Create a pull request from a feature branch. Head to your repo's Actions tab—you'll see "Deploy to Firebase Hosting on PR" running. It:

Checks out code.
Sets up Node.js.
Runs npm install and npm run build.
Deploys to a preview URL.

Merge the PR, and "Deploy to Firebase Hosting on merge" triggers a production deploy.

Workflow Files Breakdown

The generated YAML files are straightforward. Here's a peek at firebase-hosting-merge.yml:

name: Deploy to Firebase Hosting on merge
'on':
  push:
    branches:
      - master
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_YOUR_PROJECT }}'
          channelId: live
          projectId: your-project-id

The PR workflow is similar but deploys to a preview channel.

Troubleshooting Tips

No Git detected? Initialize Git first.
Auth issues? Run firebase logout and re-login.
Build fails? Ensure npm run build works locally and outputs to dist.
Secrets missing? Verify in GitHub Settings > Secrets and variables > Actions.
Vue-specific: If using Vue CLI, confirm your vue.config.js handles any Firebase env vars.

Why This Setup Rocks

This pipeline saved me hours on my PMS project. Previews catch issues early, and live deploys happen instantly on merge. Firebase Hosting is free for small projects, scales effortlessly, and includes global CDN + SSL. Pair it with GitHub Actions for zero-cost CI/CD.

Ready to automate? Follow these steps, and watch your deployments fly. If you hit snags, drop a comment below—what's your go-to deployment tool?

Originally published on October 15, 2025. Built with Vue.js and Firebase love.

Understanding Northbound, Southbound, Eastbound, and Westbound Traffic in Networking and Distributed Systems

Udara Dananjaya — Tue, 14 Oct 2025 07:43:28 +0000

In the world of networking and distributed systems, data traffic doesn’t just flow in one direction. It moves through different layers of infrastructure and applications in ways that are fundamental to how modern network architectures function. When discussing this traffic, you’ll often hear terms like northbound, southbound, eastbound, and westbound. These terms describe the direction and purpose of data flow across a network or system.

In this article, we'll dive into these concepts, explore their significance, and see how they relate to Software-Defined Networking (SDN), cloud environments, and microservices architectures.

1. Northbound Traffic: From Infrastructure to Management

Northbound traffic refers to the data that moves upward in the network stack. It’s communication from lower layers (such as physical devices, network switches, or infrastructure) to higher layers, which include network management systems, monitoring platforms, or even user applications.

Key Characteristics:

Moves upward from infrastructure to management or application layers.
Often used in SDN where network controllers send data (like metrics or state information) to management systems.
Useful for analytics, monitoring, and policy enforcement.

Example Use Case:

In SDN, a network controller might collect statistics from network devices (like switches or routers) and send that data to a centralized monitoring system. This enables network administrators to get an overview of the health and performance of the network.

2. Southbound Traffic: From Management to Infrastructure

In contrast to northbound traffic, southbound traffic is communication that flows downward from the higher layers (management systems or applications) to the lower layers (network devices, switches, routers). This is the communication that enforces configurations, policies, and changes on physical or virtual network infrastructure.

Key Characteristics:

Moves downward from management systems to network devices.
Facilitates network configuration, policy application, and state changes at the device level.
Common in SDN where the controller needs to instruct physical network devices on how to forward traffic.

Example Use Case:

A network controller sends a set of flow rules to a switch (via OpenFlow or another protocol), instructing it how to forward traffic based on current network conditions, such as load balancing or security policies.

3. Eastbound Traffic: Horizontal Communication Between Peers

While northbound and southbound traffic describe vertical relationships (management to infrastructure and vice versa), eastbound traffic refers to horizontal communication between devices or services that are at the same level in the network hierarchy.

This can be particularly important in distributed systems, microservices architectures, or cloud environments, where different services or instances need to communicate with each other.

Key Characteristics:

Horizontal communication between systems or services at the same layer or level.
Typically seen in distributed systems like microservices or service meshes, where different services need to exchange data.
Important in scenarios like data synchronization, service discovery, or load balancing.

Example Use Case:

In a microservices architecture, one microservice might need to communicate with another microservice to retrieve data or send an update. This communication is eastbound since both microservices exist at the same layer (they are peers in the architecture).

4. Westbound Traffic: Reverse Horizontal Communication

The term westbound traffic is less commonly used but refers to the reverse direction of eastbound traffic: communication moving backward or in the reverse direction between systems or services at the same layer. It’s typically the response or acknowledgment to a previous eastbound request.

Key Characteristics:

The reverse of eastbound traffic, where a service responds to another service.
Often seen in the request-response model in distributed systems or API-driven environments.

Example Use Case:

In the same microservices setup, if one microservice sends a request to another (eastbound), the response from the second microservice might be considered westbound traffic. Similarly, westbound traffic could describe a situation where a request is routed back to an earlier part of the system.

Understanding the Flow of Data in Modern Networks and Distributed Systems

Now that we’ve covered what each term means, let’s explore their relevance in real-world systems:

Software-Defined Networking (SDN):

SDN is a network architecture that separates the control plane (decision-making) from the data plane (data forwarding). In SDN:

Northbound interfaces allow applications or management platforms to interact with the network controller.
Southbound interfaces connect the controller to network devices like switches and routers to execute decisions.

Distributed Systems & Microservices:

In distributed systems, where different services work together but are often decoupled:

Eastbound and westbound traffic describe communication between services, whether it's sending a request (eastbound) or receiving a response (westbound). This kind of lateral traffic is critical in the operation of microservices architectures, where each service communicates independently but must also collaborate.

Cloud Environments:

Cloud providers often host multiple virtual machines, containers, or instances that need to communicate with each other. Eastbound traffic might describe communication between two virtual machines within the same cloud region, while northbound traffic could refer to requests from end-users to cloud-based services, and southbound traffic would be from cloud services to physical infrastructure.

Conclusion: The Importance of Understanding Data Traffic Directions

In a world where networking, cloud computing, and distributed systems are growing increasingly complex, understanding how data flows across different layers of infrastructure is essential for optimizing performance, improving security, and ensuring reliability.

Northbound and southbound traffic define the relationship between management systems and the underlying infrastructure.
Eastbound and westbound traffic describe how data flows horizontally between services or devices at the same level.

By grasping these concepts, you’ll have a better understanding of how systems interact, communicate, and make decisions. Whether you’re building a cloud-native application, managing a SDN network, or optimizing a microservices architecture, these directional traffic flows will be crucial in designing efficient and scalable systems.

Gang of Four (GoF) Design Patterns in C#: A Comprehensive Guide

Udara Dananjaya — Tue, 14 Oct 2025 06:58:30 +0000

Design patterns are reusable solutions to common problems in software design. They were popularized by the "Gang of Four" (GoF) in their seminal book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns are divided into three categories: Creational, Structural, and Behavioral.

In this article, we'll explore all 23 GoF design patterns, with brief explanations and practical implementations in C#. Each example is kept simple for clarity, focusing on the core idea. We'll use console applications or basic classes to demonstrate the patterns. Feel free to copy-paste these into your IDE (like Visual Studio) to experiment.

Whether you're a beginner or an experienced developer, understanding these patterns will help you write more flexible, maintainable, and scalable code. Let's dive in!

1. Creational Design Patterns

These patterns focus on object creation mechanisms, providing flexibility in deciding which objects to instantiate.

Singleton Pattern

Ensures that a class has only one instance and provides a global point of access to it.

Use Case: Global instances like logging systems or database connection pools.

public class Singleton
{
    private static Singleton _instance;
    private static readonly object _lock = new object();

    private Singleton() { }  // Private constructor to prevent instantiation

    public static Singleton Instance
    {
        get
        {
            lock (_lock)
            {
                if (_instance == null)
                {
                    _instance = new Singleton();
                }
                return _instance;
            }
        }
    }

    public void ShowMessage()
    {
        Console.WriteLine("Hello from Singleton!");
    }
}

// Usage
Singleton.Instance.ShowMessage();

Factory Method Pattern

Defines an interface for creating an object but allows subclasses to alter the type of objects created.

Use Case: Delegating object creation when type is determined at runtime.

public abstract class Product { }

public class ConcreteProductA : Product { }
public class ConcreteProductB : Product { }

public abstract class Creator
{
    public abstract Product FactoryMethod();
}

public class ConcreteCreatorA : Creator
{
    public override Product FactoryMethod() => new ConcreteProductA();
}

public class ConcreteCreatorB : Creator
{
    public override Product FactoryMethod() => new ConcreteProductB();
}

// Usage
Creator creator = new ConcreteCreatorA();
Product product = creator.FactoryMethod();
Console.WriteLine(product.GetType().Name);  // Outputs: ConcreteProductA

Abstract Factory Pattern

Provides an interface for creating families of related or dependent objects without specifying concrete classes.

Use Case: Creating sets of related objects, leaving instantiation to subclasses.

public interface IButton { void Render(); }
public interface ICheckbox { void Render(); }

public class WindowsButton : IButton { public void Render() => Console.WriteLine("Windows Button"); }
public class WindowsCheckbox : ICheckbox { public void Render() => Console.WriteLine("Windows Checkbox"); }

public class MacButton : IButton { public void Render() => Console.WriteLine("Mac Button"); }
public class MacCheckbox : ICheckbox { public void Render() => Console.WriteLine("Mac Checkbox"); }

public interface IGUIFactory
{
    IButton CreateButton();
    ICheckbox CreateCheckbox();
}

public class WindowsFactory : IGUIFactory
{
    public IButton CreateButton() => new WindowsButton();
    public ICheckbox CreateCheckbox() => new WindowsCheckbox();
}

public class MacFactory : IGUIFactory
{
    public IButton CreateButton() => new MacButton();
    public ICheckbox CreateCheckbox() => new MacCheckbox();
}

// Usage
IGUIFactory factory = new WindowsFactory();
factory.CreateButton().Render();  // Outputs: Windows Button

Builder Pattern

Allows step-by-step construction of complex objects, isolating construction from the final object.

Use Case: Complex objects with many optional parameters.

public class Product
{
    public string PartA { get; set; }
    public string PartB { get; set; }
    public string PartC { get; set; }
}

public interface IBuilder
{
    void BuildPartA();
    void BuildPartB();
    void BuildPartC();
    Product GetProduct();
}

public class ConcreteBuilder : IBuilder
{
    private Product _product = new Product();

    public void BuildPartA() => _product.PartA = "PartA";
    public void BuildPartB() => _product.PartB = "PartB";
    public void BuildPartC() => _product.PartC = "PartC";

    public Product GetProduct()
    {
        Product result = _product;
        _product = new Product();  // Reset
        return result;
    }
}

public class Director
{
    private IBuilder _builder;

    public Director(IBuilder builder) => _builder = builder;

    public void Construct()
    {
        _builder.BuildPartA();
        _builder.BuildPartB();
        _builder.BuildPartC();
    }
}

// Usage
IBuilder builder = new ConcreteBuilder();
Director director = new Director(builder);
director.Construct();
Product product = builder.GetProduct();
Console.WriteLine($"{product.PartA}, {product.PartB}, {product.PartC}");

Prototype Pattern

Creates new objects by copying an existing prototype.

Use Case: Expensive or complex object creation.

using System;

public class Prototype : ICloneable
{
    public string Property { get; set; }

    public object Clone() => MemberwiseClone();  // Shallow clone
}

// Usage
Prototype original = new Prototype { Property = "Original" };
Prototype clone = (Prototype)original.Clone();
clone.Property = "Clone";
Console.WriteLine(original.Property);  // Outputs: Original

2. Structural Design Patterns

These patterns deal with object composition for flexibility and scalability.

Adapter Pattern

Allows incompatible interfaces to work together via an adapter.

Use Case: Integrating legacy systems or third-party libraries.

public interface ITarget { void Request(); }

public class Adaptee { public void SpecificRequest() => Console.WriteLine("Specific Request"); }

public class Adapter : ITarget
{
    private Adaptee _adaptee = new Adaptee();

    public void Request() => _adaptee.SpecificRequest();
}

// Usage
ITarget target = new Adapter();
target.Request();  // Outputs: Specific Request

Bridge Pattern

Decouples abstraction from implementation, allowing independent variation.

Use Case: Changing implementation without affecting abstraction.

public interface IImplementor { void OperationImpl(); }

public class ConcreteImplementorA : IImplementor { public void OperationImpl() => Console.WriteLine("Impl A"); }
public class ConcreteImplementorB : IImplementor { public void OperationImpl() => Console.WriteLine("Impl B"); }

public abstract class Abstraction
{
    protected IImplementor _implementor;

    protected Abstraction(IImplementor implementor) => _implementor = implementor;

    public abstract void Operation();
}

public class RefinedAbstraction : Abstraction
{
    public RefinedAbstraction(IImplementor implementor) : base(implementor) { }

    public override void Operation() => _implementor.OperationImpl();
}

// Usage
Abstraction abstraction = new RefinedAbstraction(new ConcreteImplementorA());
abstraction.Operation();  // Outputs: Impl A

Composite Pattern

Composes objects into tree structures for part-whole hierarchies.

Use Case: Hierarchical structures like file systems.

using System.Collections.Generic;

public abstract class Component
{
    public abstract void Operation();
}

public class Leaf : Component
{
    public override void Operation() => Console.WriteLine("Leaf Operation");
}

public class Composite : Component
{
    private List<Component> _children = new List<Component>();

    public void Add(Component component) => _children.Add(component);
    public void Remove(Component component) => _children.Remove(component);

    public override void Operation()
    {
        Console.WriteLine("Composite Operation");
        foreach (var child in _children) child.Operation();
    }
}

// Usage
Composite composite = new Composite();
composite.Add(new Leaf());
composite.Operation();  // Outputs: Composite Operation \n Leaf Operation

Decorator Pattern

Dynamically adds responsibilities to objects without modifying structure.

Use Case: Adding features flexibly, like to UI components.

public interface IComponent { void Operation(); }

public class ConcreteComponent : IComponent { public void Operation() => Console.WriteLine("Concrete Operation"); }

public abstract class Decorator : IComponent
{
    protected IComponent _component;

    protected Decorator(IComponent component) => _component = component;

    public abstract void Operation();
}

public class ConcreteDecorator : Decorator
{
    public ConcreteDecorator(IComponent component) : base(component) { }

    public override void Operation()
    {
        _component.Operation();
        Console.WriteLine("Decorator Added");
    }
}

// Usage
IComponent decorated = new ConcreteDecorator(new ConcreteComponent());
decorated.Operation();  // Outputs: Concrete Operation \n Decorator Added

Facade Pattern

Provides a simplified interface to a complex subsystem.

Use Case: Simplifying complex libraries.

public class SubsystemA { public void MethodA() => Console.WriteLine("Subsystem A"); }
public class SubsystemB { public void MethodB() => Console.WriteLine("Subsystem B"); }

public class Facade
{
    private SubsystemA _a = new SubsystemA();
    private SubsystemB _b = new SubsystemB();

    public void Operation()
    {
        _a.MethodA();
        _b.MethodB();
    }
}

// Usage
Facade facade = new Facade();
facade.Operation();  // Outputs: Subsystem A \n Subsystem B

Flyweight Pattern

Reduces memory by sharing similar objects.

Use Case: Large numbers of similar objects, like in games.

using System.Collections.Generic;

public class Flyweight
{
    private string _sharedState;  // Intrinsic state

    public Flyweight(string sharedState) => _sharedState = sharedState;

    public void Operation(string uniqueState) => Console.WriteLine($"Shared: {_sharedState}, Unique: {uniqueState}");
}

public class FlyweightFactory
{
    private Dictionary<string, Flyweight> _flyweights = new Dictionary<string, Flyweight>();

    public Flyweight GetFlyweight(string key)
    {
        if (!_flyweights.ContainsKey(key))
        {
            _flyweights[key] = new Flyweight(key);
        }
        return _flyweights[key];
    }
}

// Usage
FlyweightFactory factory = new FlyweightFactory();
factory.GetFlyweight("Shared1").Operation("Unique1");

Proxy Pattern

Provides a surrogate for another object.

Use Case: Lazy loading, access control.

public interface ISubject { void Request(); }

public class RealSubject : ISubject { public void Request() => Console.WriteLine("Real Request"); }

public class Proxy : ISubject
{
    private RealSubject _realSubject;

    public void Request()
    {
        if (_realSubject == null) _realSubject = new RealSubject();
        _realSubject.Request();
    }
}

// Usage
ISubject proxy = new Proxy();
proxy.Request();  // Outputs: Real Request (lazy loaded)

3. Behavioral Design Patterns

These patterns handle object interaction and communication.

Chain of Responsibility Pattern

Allows multiple handlers to process a request.

Use Case: Chains for handling requests or events.

public abstract class Handler
{
    protected Handler _next;

    public void SetNext(Handler next) => _next = next;

    public abstract void HandleRequest(int request);
}

public class ConcreteHandlerA : Handler
{
    public override void HandleRequest(int request)
    {
        if (request < 10) Console.WriteLine("Handled by A");
        else _next?.HandleRequest(request);
    }
}

public class ConcreteHandlerB : Handler
{
    public override void HandleRequest(int request)
    {
        if (request >= 10) Console.WriteLine("Handled by B");
        else _next?.HandleRequest(request);
    }
}

// Usage
Handler handlerA = new ConcreteHandlerA();
Handler handlerB = new ConcreteHandlerB();
handlerA.SetNext(handlerB);
handlerA.HandleRequest(5);  // Outputs: Handled by A

Command Pattern

Encapsulates requests as objects for parameterization, queuing, etc.

Use Case: Undo/redo, menu actions.

public interface ICommand { void Execute(); }

public class ConcreteCommand : ICommand
{
    private Receiver _receiver;

    public ConcreteCommand(Receiver receiver) => _receiver = receiver;

    public void Execute() => _receiver.Action();
}

public class Receiver { public void Action() => Console.WriteLine("Receiver Action"); }

public class Invoker
{
    private ICommand _command;

    public void SetCommand(ICommand command) => _command = command;
    public void ExecuteCommand() => _command.Execute();
}

// Usage
Receiver receiver = new Receiver();
ICommand command = new ConcreteCommand(receiver);
Invoker invoker = new Invoker();
invoker.SetCommand(command);
invoker.ExecuteCommand();  // Outputs: Receiver Action

Interpreter Pattern

Evaluates language grammar or expressions.

Use Case: Parsing expressions like math or regex.

using System.Collections.Generic;

public interface IExpression { int Interpret(Dictionary<string, int> context); }

public class Number : IExpression
{
    private int _number;
    public Number(int number) => _number = number;
    public int Interpret(Dictionary<string, int> context) => _number;
}

public class Add : IExpression
{
    private IExpression _left, _right;
    public Add(IExpression left, IExpression right) { _left = left; _right = right; }
    public int Interpret(Dictionary<string, int> context) => _left.Interpret(context) + _right.Interpret(context);
}

// Usage (simple example: 1 + 2)
IExpression expression = new Add(new Number(1), new Number(2));
Console.WriteLine(expression.Interpret(new Dictionary<string, int>()));  // Outputs: 3

Iterator Pattern

Accesses collection elements sequentially without exposing representation.

Use Case: Iterating lists or sets consistently.

using System.Collections;
using System.Collections.Generic;

public class Aggregate : IEnumerable<string>
{
    private List<string> _items = new List<string> { "Item1", "Item2" };

    public IEnumerator<string> GetEnumerator() => _items.GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

// Usage
Aggregate aggregate = new Aggregate();
foreach (var item in aggregate) Console.WriteLine(item);  // Outputs: Item1 \n Item2

Mediator Pattern

Centralizes communication between objects to reduce dependencies.

Use Case: Centralizing object interactions.

public interface IMediator { void Notify(object sender, string ev); }

public class ConcreteMediator : IMediator
{
    public Colleague1 Colleague1 { get; set; }
    public Colleague2 Colleague2 { get; set; }

    public void Notify(object sender, string ev)
    {
        if (ev == "A") Colleague2.DoSomething();
        else if (ev == "B") Colleague1.DoSomething();
    }
}

public abstract class Colleague
{
    protected IMediator _mediator;
    protected Colleague(IMediator mediator) => _mediator = mediator;
}

public class Colleague1 : Colleague
{
    public Colleague1(IMediator mediator) : base(mediator) { }
    public void DoA() => _mediator.Notify(this, "A");
    public void DoSomething() => Console.WriteLine("Colleague1 reacts");
}

public class Colleague2 : Colleague
{
    public Colleague2(IMediator mediator) : base(mediator) { }
    public void DoB() => _mediator.Notify(this, "B");
    public void DoSomething() => Console.WriteLine("Colleague2 reacts");
}

// Usage
ConcreteMediator mediator = new ConcreteMediator();
Colleague1 c1 = new Colleague1(mediator);
Colleague2 c2 = new Colleague2(mediator);
mediator.Colleague1 = c1;
mediator.Colleague2 = c2;
c1.DoA();  // Outputs: Colleague2 reacts

Memento Pattern

Captures and restores object state without violating encapsulation.

Use Case: Undo functionality.

public class Memento
{
    public string State { get; }

    public Memento(string state) => State = state;
}

public class Originator
{
    public string State { get; set; }

    public Memento Save() => new Memento(State);
    public void Restore(Memento memento) => State = memento.State;
}

public class Caretaker
{
    public Memento Memento { get; set; }
}

// Usage
Originator originator = new Originator { State = "State1" };
Caretaker caretaker = new Caretaker { Memento = originator.Save() };
originator.State = "State2";
originator.Restore(caretaker.Memento);
Console.WriteLine(originator.State);  // Outputs: State1

Observer Pattern

Defines one-to-many dependency for notifying dependents of changes.

Use Case: Event listeners in GUIs.

using System.Collections.Generic;

public interface IObserver { void Update(string message); }

public class Subject
{
    private List<IObserver> _observers = new List<IObserver>();

    public void Attach(IObserver observer) => _observers.Add(observer);
    public void Detach(IObserver observer) => _observers.Remove(observer);

    public void Notify(string message)
    {
        foreach (var observer in _observers) observer.Update(message);
    }
}

public class ConcreteObserver : IObserver
{
    public void Update(string message) => Console.WriteLine($"Received: {message}");
}

// Usage
Subject subject = new Subject();
ConcreteObserver observer = new ConcreteObserver();
subject.Attach(observer);
subject.Notify("Update!");  // Outputs: Received: Update!

State Pattern

Changes object behavior based on internal state.

Use Case: Finite-state machines.

public interface IState { void Handle(Context context); }

public class ConcreteStateA : IState
{
    public void Handle(Context context)
    {
        Console.WriteLine("State A");
        context.State = new ConcreteStateB();
    }
}

public class ConcreteStateB : IState
{
    public void Handle(Context context)
    {
        Console.WriteLine("State B");
        context.State = new ConcreteStateA();
    }
}

public class Context
{
    public IState State { get; set; }

    public Context(IState state) => State = state;

    public void Request() => State.Handle(this);
}

// Usage
Context context = new Context(new ConcreteStateA());
context.Request();  // Outputs: State A
context.Request();  // Outputs: State B

Strategy Pattern

Defines a family of algorithms, selectable at runtime.

Use Case: Runtime algorithm selection, like sorting.

public interface IStrategy { void Algorithm(); }

public class ConcreteStrategyA : IStrategy { public void Algorithm() => Console.WriteLine("Strategy A"); }
public class ConcreteStrategyB : IStrategy { public void Algorithm() => Console.WriteLine("Strategy B"); }

public class Context
{
    private IStrategy _strategy;

    public Context(IStrategy strategy) => _strategy = strategy;

    public void Execute() => _strategy.Algorithm();
}

// Usage
Context context = new Context(new ConcreteStrategyA());
context.Execute();  // Outputs: Strategy A

Template Method Pattern

Defines algorithm skeleton in superclass, with customizable steps in subclasses.

Use Case: Common processes with customizable steps.

public abstract class AbstractClass
{
    public void TemplateMethod()
    {
        PrimitiveOperation1();
        PrimitiveOperation2();
    }

    protected abstract void PrimitiveOperation1();
    protected abstract void PrimitiveOperation2();
}

public class ConcreteClass : AbstractClass
{
    protected override void PrimitiveOperation1() => Console.WriteLine("Op1");
    protected override void PrimitiveOperation2() => Console.WriteLine("Op2");
}

// Usage
AbstractClass concrete = new ConcreteClass();
concrete.TemplateMethod();  // Outputs: Op1 \n Op2

Visitor Pattern

Adds new operations to object structures without changing classes.

Use Case: Adding operations to composites.

using System.Collections.Generic;

public interface IVisitor { void Visit(ElementA element); void Visit(ElementB element); }

public abstract class Element { public abstract void Accept(IVisitor visitor); }

public class ElementA : Element { public override void Accept(IVisitor visitor) => visitor.Visit(this); }
public class ElementB : Element { public override void Accept(IVisitor visitor) => visitor.Visit(this); }

public class ConcreteVisitor : IVisitor
{
    public void Visit(ElementA element) => Console.WriteLine("Visited A");
    public void Visit(ElementB element) => Console.WriteLine("Visited B");
}

public class ObjectStructure
{
    private List<Element> _elements = new List<Element>();

    public void Add(Element element) => _elements.Add(element);

    public void Accept(IVisitor visitor)
    {
        foreach (var element in _elements) element.Accept(visitor);
    }
}

// Usage
ObjectStructure structure = new ObjectStructure();
structure.Add(new ElementA());
structure.Add(new ElementB());
IVisitor visitor = new ConcreteVisitor();
structure.Accept(visitor);  // Outputs: Visited A \n Visited B

Conclusion

We've covered all 23 GoF design patterns with C# implementations. These patterns aren't silver bullets—use them where they fit to avoid over-engineering. Practice by applying them to real projects, like refactoring legacy code or building new systems.

Working with Cron Jobs on Ubuntu

Udara Dananjaya — Mon, 28 Jul 2025 06:04:25 +0000

📅 Cron Jobs in Ubuntu

Cron is a time-based job scheduler in Unix-like systems used to run scripts and commands automatically at scheduled times.

🔧 Edit the Crontab

To create or edit cron jobs for the current user:

crontab -e

⏱️ Common Cron Job Examples

Run a backup script daily at 2:30 AM:

30 2 * * * /home/youruser/backup.sh

Run a script every minute, and log output and errors:

* * * * * /bin/bash /path/to/your/script.sh >> /path/to/logfile.log 2>&1

Run a script daily at 1:00 AM:

0 1 * * * /bin/bash /path/to/your/script.sh >> /path/to/logfile.log 2>&1

🧠 Cron Syntax Breakdown

* * * * * command_to_run
│ │ │ │ │
│ │ │ │ └──── Day of the week (0 - 7) (Sunday = 0 or 7)
│ │ │ └────── Month (1 - 12)
│ │ └──────── Day of month (1 - 31)
│ └────────── Hour (0 - 23)
└──────────── Minute (0 - 59)

⚙️ Cron Job Setup & Management

Make your script executable:

  chmod +x /path/to/your/script.sh

List current cron jobs:

  crontab -l

Remove all cron jobs for the user:

  crontab -r

Check cron service status:

  systemctl status cron

Debugging cron output in system logs (if enabled):

  grep CRON /var/log/syslog

✏️ Changing the Default Text Editor in Ubuntu

Cron and Git (e.g., git commit) may invoke a text editor — by default, it's usually nano or vi. You can change this to something else, like vim or VS Code.

🔹 Option 1: Quick Swap with Alternatives

sudo update-alternatives --config editor

Select your preferred editor from the list.

🔹 Option 2: Set `EDITOR` or `VISUAL` Environment Variables

Open your shell config file (e.g., ~/.bashrc or ~/.zshrc)
Add one of the following:

For Nano:

export EDITOR=nano

For Vim:

export EDITOR=vim
export VISUAL=vim

Apply the changes:

source ~/.bashrc   # or ~/.zshrc

Confirm the default editor:

echo $EDITOR

🧪 Final Notes & Tips

Always test your script manually before scheduling it with cron.
Use full paths for commands and scripts in cron jobs — cron runs in a minimal environment.
Log all output to a file for easy debugging.
Comment your crontab entries if you have multiple tasks.
Update or delete cron jobs as your project changes.

🔐 How to Use Deploy Keys with GitHub for Secure Automation

Udara Dananjaya — Mon, 14 Apr 2025 05:14:33 +0000

Whether you're building a CI/CD pipeline, automating deployments, or giving a remote server access to a private repository, Deploy Keys offer a secure, streamlined solution. Instead of sharing personal credentials or access tokens, you can assign a unique SSH key to a specific repository — and GitHub will only allow that key to interact with that one repo.

Let’s walk through how to set it up and why you might want to.

🧠 What is a Deploy Key?

A Deploy Key is an SSH key (public/private key pair) that gives access to a single GitHub repository. It’s not tied to a GitHub user — just the repository.

This makes deploy keys perfect for:

Read-only access from build servers or scripts
Secure write access for auto-deployment
Isolated access that can’t affect other projects

🛠️ Step 1: Generate an SSH Key Pair

Start by creating a new SSH key pair. It’s best to use a new key just for this purpose:

ssh-keygen -t ed25519 -C "deploy-key" -f deploy_key

-f deploy_key saves the private key as deploy_key and the public key as deploy_key.pub
When prompted for a passphrase, leave it empty (for automation)

Make sure you keep the private key safe and secure — this is the key that will be used by your deployment environment or server.

📤 Step 2: Add the Public Key to GitHub

Go to your GitHub repository
Navigate to Settings → Deploy Keys
Click “Add deploy key”
Give it a name (e.g., CI/CD Server, Deployment Key)
Paste the contents of your deploy_key.pub file
✅ Check “Allow write access” if the key needs to push code (otherwise leave it unchecked for read-only)

Click Add Key, and you're done with the GitHub side.

🔧 Step 3: Use the Private Key for Git Access

On your server, deployment script, or CI environment, make sure the private key is available and used when interacting with Git.

There are a few ways to do this:

🔹 Option A: One-Time Use with Git

GIT_SSH_COMMAND='ssh -i /path/to/deploy_key' git clone git@github.com:your-org/your-repo.git

This command tells Git to use your specific SSH key when cloning.

Note: If you're using Git Bash or a Unix-like shell, use forward slashes in paths.

🔹 Option B: Configure a Host Alias with SSH

Create or edit your SSH config file (~/.ssh/config) like this:

Host github-deploy
    HostName github.com
    User git
    IdentityFile /path/to/deploy_key
    IdentitiesOnly yes

Now you can clone using:

git clone github-deploy:your-org/your-repo.git

This keeps your automation scripts cleaner and reusable.

🔹 Option C: Global Git Config (Alternative)

You can also tell Git to always use the key by setting:

git config --global core.sshCommand "ssh -i /path/to/deploy_key"

This sets the SSH key for all Git commands run in that environment.

🔐 Read-Only vs Write Access

By default, deploy keys are read-only, which is ideal for cloning and fetching code. But if your use case involves pushing code — like automated deployments, GitOps workflows, or update bots — you can enable write access when adding the key.

🔒 Only grant write access when absolutely necessary.

💡 Best Practices

Use a separate deploy key per repository
Never reuse a deploy key across multiple repos
Don’t share deploy keys with people — they’re for systems
For multiple repositories, consider using a machine user with a Personal Access Token instead

✅ Summary

Deploy keys offer a clean, secure way to grant SSH access to a GitHub repo without giving away personal credentials or full user access. Whether you’re setting up continuous deployment, pulling code onto a server, or triggering builds from a CI system — deploy keys are the right tool for the job.

They’re easy to create, scoped to a single repo, and flexible enough for both read and write access. Just generate a key, upload the public part to GitHub, and start automating with confidence.

DEV Community: Udara Dananjaya

🔐 Running a Persistent Database SSH Tunnel as a Windows Service (SSH & Plink)

🧠 Understanding SSH Tunneling

🖥 Example SSH Tunnel Command

Parameter Explanation

⚙ Creating a Windows Service for the Tunnel

Explanation

🔧 Starting and Managing the Service

🔌 Connecting to the Database

🧰 Alternative Method Using Plink (PuTTY)

Example Plink Tunnel Command

Parameter Explanation

Creating a Windows Service Using Plink

🚀 Advantages of Running the Tunnel as a Service

📌 Final Thoughts

How to Use a Public GitHub Repository as a Maven Dependency

Why GitHub Packages for Maven?

Prerequisites

Step 1: Create a GitHub Personal Access Token (PAT)

Step 2: Authenticate Maven with GitHub Packages

Step 3: Add the GitHub Maven Repository

Option 1: Use a specific repository

Option 2: Use all repositories under an owner

Step 4: Add the Dependency

Step 5: Build the Project

Common Pitfalls

Final Thoughts

Automating Vue.js App Deployment to Firebase Hosting with GitHub Actions Without npm firebase-tools

Prerequisites

Step 1: Set Up Firebase Hosting Manually

Create firebase.json

Create .firebaserc

Update .gitignore

Generate a Service Account Key

Step 2: Test Your Build Locally

Step 3: Set Up GitHub Actions for CI/CD

Add Service Account Key to GitHub Secrets

Create Workflow for Pull Requests

Create Workflow for Live Deployment

Step 4: Push and Test the Workflows

Step 5: Verify Deployment

Troubleshooting

Why This Approach Wins

Effortless Vue.js Deployment with Firebase Hosting and GitHub Actions (No firebase-tools)

Effortless Vue.js Deployment with Firebase Hosting and GitHub Actions

TL;DR

Why This Setup?

Prerequisites

Step 1: Configure Firebase Hosting Manually

Create firebase.json

Create .firebaserc

Update .gitignore

Get a Service Account Key

Step 2: Test Your Build

Step 3: Set Up GitHub Actions CI/CD

Add Service Account to GitHub Secrets

Create Workflow

Step 4: Push and Test

Step 5: Verify Deployment

Troubleshooting

Why This Wins

Complete Guide: Automating Deployment with GitHub Webhooks, Nginx, and Shell Scripts

Table of Contents

1. Setting Up GitHub Webhook

Steps to Set Up the Webhook:

2. Configuring Your VPS

2.1 Installing Nginx (Web Server)

2.2 Creating the Webhook Handler Script

2.3 Setting Up Nginx to Trigger the Webhook Script

3. Testing the Webhook Endpoint

4. Automating the Deployment

5. Monitoring Logs

6. Conclusion

Setting Up a Secure Web Server Proxy

Server Roles and Tools

Flow Overview

1. Configuring HTTPS on the Internal Server

1.1 Generate a Self-Signed SSL Certificate

1.2 Configure Apache (httpd) for HTTPS

1.3 Configure Nginx (Optional)

Create `firebase.json`

Create `.firebaserc`

Update `.gitignore`

Create `firebase.json`

Create `.firebaserc`

Update `.gitignore`

1.2 Configure Apache (`httpd`) for HTTPS

1.2 Configure Apache (`httpd`) for HTTPS