🟢 Phase 11 — Security Hardening (Step-by-Step)

[vimal-java-dev]

We’ll implement this in layers (like real infra defence):

1. Secrets (.env) security
2. Server access hardening (sudo, SSH)
3. Network isolation (DB, Redis)
4. Abuse protection (Fail2ban)
5. Application-level protection (rate limiting)

[vimal-tech-starter]

Assign me.

[vimal-tech-starter]

❗ Issues (Be Strict Here)

1. Weak Credentials ❌
   contactuser / contactpass

👉 This is not acceptable in production, even for a portfolio.

2. Duplicate Variables ❌

You’re defining both:

SPRING_DATASOURCE_*
DB_*

👉 Redundant → increases risk of inconsistency.

3. Path Location ⚠️
   ~/deployments/contact-api/.env

This is:

OK for now
BUT not ideal for separation of code vs secrets

[vimal-tech-starter]

❗ Issues (Be Strict Here)

1. Weak Credentials ❌
   contactuser / contactpass

👉 This is not acceptable in production, even for a portfolio.

2. Duplicate Variables ❌

You’re defining both:

SPRING_DATASOURCE_* DB_*

👉 Redundant → increases risk of inconsistency.

3. Path Location ⚠️
   ~/deployments/contact-api/.env

This is:

OK for now BUT not ideal for separation of code vs secrets

✅ Step-by-Step Fix (Production-Grade)

🔐 Step 1: Move .env to Secure Location

Create a dedicated secrets directory:

sudo mkdir -p /opt/contact-api
sudo mv ~/deployments/contact-api/.env /opt/contact-api/.env

🔐 Step 2: Lock Permissions
sudo chown deploy:deploy /opt/contact-api/.env
sudo chmod 600 /opt/contact-api/.env

🔐 Step 3: Generate Strong Credentials

Use:

openssl rand -base64 32

🔐 Step 4: Clean .env (REMOVE DUPLICATES)

🔐 Step 5: Update docker-compose.yml

Change:

env_file:

• .env ❌

To:

env_file:

• /opt/contact-api/.env ✅

---

Need below -> 🔐 Step 6: Ensure .env is NOT in Git

[.gitignore at VPS or Not]

🔍 YOUR CURRENT FLOW (IMPORTANT)

Right now your deployment is:

GitHub → GitHub Actions → GHCR (Docker image) → VPS (docker pull) → run container

👉 So:

VPS does NOT build code
VPS just pulls image
👉 So your VPS does NOT depend on repo code

[vimal-java-dev]

❗ Issues (Be Strict Here)

1. Weak Credentials ❌
   contactuser / contactpass

👉 This is not acceptable in production, even for a portfolio.

2. Duplicate Variables ❌

You’re defining both:
SPRING_DATASOURCE_* DB_*
👉 Redundant → increases risk of inconsistency.

3. Path Location ⚠️
   ~/deployments/contact-api/.env

This is:
OK for now BUT not ideal for separation of code vs secrets

✅ Step-by-Step Fix (Production-Grade)

🔐 Step 1: Move .env to Secure Location

Create a dedicated secrets directory:

sudo mkdir -p /opt/contact-api sudo mv ~/deployments/contact-api/.env /opt/contact-api/.env

🔐 Step 2: Lock Permissions sudo chown deploy:deploy /opt/contact-api/.env sudo chmod 600 /opt/contact-api/.env

🔐 Step 3: Generate Strong Credentials

Use:

openssl rand -base64 32

🔐 Step 4: Clean .env (REMOVE DUPLICATES)

🔐 Step 5: Update docker-compose.yml

Change:

env_file:

• .env ❌

To:

env_file:

• /opt/contact-api/.env ✅

Need below -> 🔐 Step 6: Ensure .env is NOT in Git

[.gitignore at VPS or Not]

🔍 YOUR CURRENT FLOW (IMPORTANT)

Right now your deployment is:

GitHub → GitHub Actions → GHCR (Docker image) → VPS (docker pull) → run container

👉 So:

VPS does NOT build code VPS just pulls image 👉 So your VPS does NOT depend on repo code

=============
✅ WHEN YOU DO NOT NEED git pull

For normal development & deployment:

New feature
Bug fix
Code change

👉 Just run:

./deploy.sh

✔ Done

=================

⚠️ WHEN YOU DO NEED git pull (RARE CASES)

Only if you changed the files that are actually used on the VPS

🔹 Case 1 — You decide to manage infra via Git

Example:

You edit docker-compose.yml in GitHub
You want VPS to use that version

👉 THEN:

git pull

🔹 Case 2 — Monitoring configs from repo

Example:

Prometheus config updated in repo

👉 THEN:

git pull

[vimal-java-dev]

❗ YOUR CURRENT REALITY (IMPORTANT)

Right now you are:

• Editing these directly on VPS:
  • docker-compose.yml
  • deploy.sh
  • .env

👉 That means:

VPS = source of truth for infra

---

🚨 SO IN YOUR CASE

👉 You do NOT need git pull at all

Because:

• You are NOT syncing infra from Git
• You are NOT using repo configs on VPS

---

🧠 SIMPLE RULE (REMEMBER THIS)

If VPS uses Git → use git pull
If VPS uses Docker image + manual configs → NO git pull

---

👍 YOUR CURRENT SETUP (FINAL CLARITY)

Component | Source -- | -- App | GHCR (Docker image) ✅ DB / Redis | VPS docker-compose ✅ deploy.sh | VPS local file ✅ .env | VPS local file ✅

👉 So:

NO git pull needed

[vimal-java-dev]

❗ YOUR CURRENT REALITY (IMPORTANT)

Right now you are:

• Editing these directly on VPS:

  • docker-compose.yml
  • deploy.sh
  • .env

👉 That means:

VPS = source of truth for infra

🚨 SO IN YOUR CASE

👉 You do NOT need git pull at all

Because:

• You are NOT syncing infra from Git
• You are NOT using repo configs on VPS

🧠 SIMPLE RULE (REMEMBER THIS)

If VPS uses Git → use git pull
If VPS uses Docker image + manual configs → NO git pull

👍 YOUR CURRENT SETUP (FINAL CLARITY)

Component | Source -- | -- App | GHCR (Docker image) ✅ DB / Redis | VPS docker-compose ✅ deploy.sh | VPS local file ✅ .env | VPS local file ✅
👉 So:

NO git pull needed

🧾 FINAL ONE-LINE ANSWER

👉 For your project: NO, you do NOT need git pull on VPS.

👍 YOU’RE GOOD NOW

No more confusion:

Deploy → ./deploy.sh
Infra → edit on VPS
Secrets → /opt/.env

[vimal-java-dev]

You’re currently at:

✔ Completed

• CI/CD → GitHub Actions → GHCR → VPS
• Dockerized Spring Boot app
• Postgres + Redis (isolated, internal network)
• Blue-Green deployment (zero downtime)
• Health checks + rollback
• Secure .env handling
• Removed public app exposure (localhost binding)

[vimal-tech-starter]

You’re currently at:

✔ Completed

• CI/CD → GitHub Actions → GHCR → VPS
• Dockerized Spring Boot app
• Postgres + Redis (isolated, internal network)
• Blue-Green deployment (zero downtime)
• Health checks + rollback
• Secure .env handling
• Removed public app exposure (localhost binding)

Phase 11 (Security Hardening) – partially done:

• .env secured
• DB not exposed
• Containers bound to localhost

Continue Phase 11 with:

• NGINX security hardening (rate limiting, headers)
• Fail2ban (optional)
• Any remaining production security best practices

[vimal-java-dev]

You’re currently at:

✔ Completed

• CI/CD → GitHub Actions → GHCR → VPS
• Dockerized Spring Boot app
• Postgres + Redis (isolated, internal network)
• Blue-Green deployment (zero downtime)
• Health checks + rollback
• Secure .env handling
• Removed public app exposure (localhost binding)

Phase 11 (Security Hardening) – partially done:

• .env secured
• DB not exposed
• Containers bound to localhost

Continue Phase 11 with:

• NGINX security hardening (rate limiting, headers)
• Fail2ban (optional)
• Any remaining production security best practices

🚀 What We’ll Do Next

We’ll go cleanly into:

🔐 NGINX Hardening

• Rate limiting (DDoS/basic abuse protection)
• Security headers (XSS, clickjacking, etc.)
• Tight proxy config

🔐 Optional but strong:

• Fail2ban
• Request filtering

👍 Final Note

• You’ve crossed the hardest part already.

The next phase is:
👉 polishing + hardening (not debugging chaos anymore)

[vimal-tech-starter]

Check PR #39.

[vimal-java-dev]

PR #39 is merged and closed.