Coder Legion - Recent posts tagged nginx

Securing an Angular Application: Part 3 — Implementing CSP with Nginx

Sun, 18 Oct 2026 10:55:08 +0000

Continuing my series on hardening Angular applications, Part 3 moves into the actual Nginx server configuration and Content Security Policy (CSP) implementation.

In this part, I walk through the docker-nginx-server.conf configuration used to serve a real Angular application and explain how the different pieces work together.

Some of the topics covered:

⚙️ Angular server configuration with Nginx
🔀 Angular SPA routing
📦 Static asset handling and caching
🚫 Blocking hidden and sensitive files
🔐 Security headers
🛡️ Content Security Policy directives
🔑 Dynamic CSP nonce handling
🧩 Injecting the nonce into Angular HTML
⚠️ Error page handling
🔒 Trusted Types and other CSP protections

Rather than using a generic CSP policy, the goal is to understand which resources the Angular application actually needs and how those requirements translate into individual CSP directives.

This part also shows how the CSP nonce is handled using Nginx:

set $csp_nonce $request_id;

sub_filter_once off;
sub_filter '__CSP_NONCE__' '$csp_nonce';

This allows the nonce used by the CSP policy to be injected into the Angular application's HTML for each request.
With the Nginx configuration and CSP in place, the next part moves one layer deeper into the deployment process: Dockerizing the Angular application and packaging the Nginx configuration into a production-ready container.

📖 Read Part 3:
https://medium.com/@jangidamit800/angular-content-security-policy-csp-implementing-the-nginx-server-configuration-c70593b9136a?sharedUserId=jangidamit800

#Angular #AngularSecurity #CSP #ContentSecurityPolicy #Nginx #WebSecurity #DevSecOps #Docker #FrontendSecurity

Angular Security Headers: A Practical Guide to Securing Your Angular Application

Sat, 10 Oct 2026 12:37:43 +0000

I've started a new series focused on hardening Angular applications using browser and HTTP security controls.

In Part 1, I cover the fundamentals of security headers and how they add another layer of protection between an Angular application and the browser.

Some of the topics covered:

🔒 HSTS — enforcing HTTPS
🛡️ X-Content-Type-Options
🧭 Referrer-Policy
🎯 Permissions-Policy
🚫 X-Frame-Options
🔄 Cross-Origin Opener Policy (COOP)
🌐 Cross-Origin Resource Policy (CORP)
🔐 Content Security Policy (CSP)
The goal of this series isn't to simply copy a list of security headers, but to understand what each header does, what problem it addresses, and how these controls fit into a real Angular deployment.

This is Part 1, where we establish the foundation. The upcoming parts will move into the actual CSP, Nginx, and Docker configuration used to serve the application.

📖 Read Part 1:

https://medium.com/@jangidamit800/hardening-an-angular-application-understanding-security-headers-0c65644b981b

Would love to hear how others approach security hardening for Angular applications.

#Angular #AngularSecurity #WebSecurity #CSP #Nginx #DevSecOps #FrontendSecurity #WebDevelopment

Same Ingress, Different Defaults: What Changed When We Moved to HAProxy

Thu, 08 Oct 2026 08:23:47 +0000

Over the last few weeks, we moved the customer-facing managed services on our NKE service clusters and Deploio from ingress-nginx to HAProxy: Grafana, Loki, ArgoCD, the container registry, Alertmanager, Tempo, OpenSearch, the Object Storage endpoints and all Deploio applications. Some clusters alone had more than 200 Ingresses.

We have written about the motivation twice before. In December, we explained what the retirement of ingress-nginx meant and which migration paths were open. Our TechTalk #29 recap covered our evaluation of Traefik, Gateway API and HAProxy, and why HAProxy became our default for classic Ingress on NKE.

This post is about what happened after that decision.

The annotation mapping table in our documentation gets you a working Ingress on HAProxy in a few minutes. What it does not show is how the defaults shift underneath your workloads. Two ingress controllers can parse the same Ingress resource and still differ in how they talk to your backends, which status codes they send, how long they wait and how many connections they accept before refusing new ones.

We found most of these differences in production, after the switch. One of them broke a customer’s website asset delivery. We are sharing them so you can check your own setup before you migrate.

HTTP to HTTPS Redirects

While comparing responses from both controllers, we noticed that plain HTTP requests were redirected with 302 Found on HAProxy, whereas nginx returned 308 Permanent Redirect.

ingress-nginx sets http-redirect-code to 308 by default. haproxy-ingress defaults its corresponding ssl-redirect-code to a temporary 302. Browsers follow both, but API clients, search crawlers and intermediate caches treat them differently. A 302 allows clients to rewrite a POST into a GET on redirect, whereas a 308 preserves the request method and body.

A silent downgrade to temporary redirects can break API consumers, so we set ssl-redirect-code: "308" globally on our managed controllers to keep the previous behaviour.

Connection Limits

During peak traffic, requests to Deploio applications slowed down and some new connections were refused.

The cause was the connection limit. nginx and HAProxy calculate their ceilings differently:

nginx multiplies worker_processes by worker_connections. With
ingress-nginx setting worker_processes to the node’s CPU count and
worker_connections to 16384, even a modest node can handle tens of
thousands of concurrent connections.
HAProxy enforces a single global maxconn, which haproxy-ingress
exposes as max-connections and sets to 2,000 per pod by default.

Once a pod reaches that ceiling, HAProxy stops accepting new connections. They then queue in the kernel’s accept backlog, which caused the slowdown. Once the backlog is full, they are dropped.

We raised max-connections to 20,000 across all managed controllers.

Timeouts

Shortly after we migrated Deploio, some customers saw requests fail with 504 Gateway Timeout.

haproxy-ingress defaults timeout-client and timeout-server to 50 seconds, while ingress-nginx waits 60 seconds. Ten seconds make no difference for typical web requests, but data exports or reports that reliably finished in 55 seconds suddenly failed with a 504.

To avoid cutting off requests that used to succeed, our managed controllers set both timeout-client and timeout-server to 60 seconds. You can still override the timeout per Ingress with haproxy-ingress.github.io/timeout-server in place of nginx.ingress.kubernetes.io/proxy-read-timeout.

Upstream HTTP Version

In July, we moved an S3-compatible Object Storage endpoint to HAProxy. A customer served website assets through their own nginx reverse proxy in front of that endpoint. Right after the cutover, every asset request failed with 400 Bad Request.

The cause: nginx’s proxy_pass talks to upstreams over HTTP/1.0 by default. ingress-nginx always spoke HTTP/1.1 to backends, regardless of the client’s protocol, and so it silently upgraded the customer’s HTTP/1.0 requests. HAProxy forwards the request with the protocol version the client sent. The Object Storage backend rejected HTTP/1.0 requests, which produced the 400 errors.

The fix was for the customer to add proxy_http_version 1.1 to their reverse proxy configuration:

location / {
    proxy_pass http://storage-endpoint;
    proxy_http_version 1.1;
}

If you run a reverse proxy in front of an NKE or Deploio Ingress, check which HTTP version it sends.

Basic Auth

After we had migrated most managed services, one of the controllers spiked to more than two full CPU cores while serving only 155 concurrent connections. Almost all traffic to that pod hit two endpoints protected by HTTP basic authentication, one of them our metrics ingestion pipeline.

HAProxy verifies basic authentication via crypt(3) synchronously on every request, without caching. A bcrypt hash with a cost factor of 10, the default in most standard libraries and in Helm’s htpasswd template function, takes about 50 ms of CPU time to verify. At 50 ms per check, twenty requests per second are enough to saturate a whole CPU core.

This also applies to nginx, as its auth_basic module verifies every request synchronously and caches nothing either. Because each nginx worker is a single-threaded event loop, a 50 ms verification stalls every connection on that worker. But workers are separate processes, so a controller with eight workers can verify eight passwords in parallel.

HAProxy uses the thread-safe crypt_r(3) only on glibc and FreeBSD. On every other platform, including the Alpine-based image that haproxy-ingress ships, it wraps the plain crypt(3) call in a single process-wide spinlock. Only one thread can verify a password at a time, which caps the whole pod at roughly twenty verifications per second, no matter how many cores it has. And because it is a spinlock, waiting threads do not sleep. They keep their cores busy until it is their turn. That is how a pod serving 155 connections ended up using more than two cores.

The HAProxy manual warns that hashed passwords “can quickly become a major factor in HAProxy’s overall CPU consumption” and notes that musl’s hash implementations are slower than glibc’s. An upstream request to cache successful basic authentication results has been open since 2019 in haproxy/haproxy#370.

For credentials we generate internally, we reduced the bcrypt cost to 4, where verification takes under one millisecond. This is safe because those passwords are long, machine-generated strings of 20 random characters, which makes brute-force attacks computationally infeasible regardless of the cost factor. Helm’s built-in htpasswd function always hashes with bcrypt’s default cost of 10 and offers no way to change it (Sprig source), so chart-generated credentials need to be hashed outside Helm.

The annotation syntax is simpler on HAProxy. Setting haproxy-ingress.github.io/auth-secret alone enables authentication, auth-type is deprecated. The secret format stays the same: an htpasswd file stored under the auth key.

X-Forwarded-For

On paper, this looks like a change in behaviour. In practice it is not one, but it does add a header.

ingress-nginx replaced any incoming X-Forwarded-For with the connecting IP unless the cluster-wide compute-full-forwarded-for option was enabled, and on our shared controllers it was off.

HAProxy’s option forwardfor on its own behaves differently: it appends the connecting IP, so if the client already sent an X-Forwarded-For, the backend receives both. Applications behind a CDN or reverse proxy would then see the whole proxy chain instead of the single value ingress-nginx gave them.

haproxy-ingress closes that gap. Its forwardfor key defaults to add, which deletes any incoming X-Forwarded-For before HAProxy inserts the connecting IP. Your application therefore sees the same as before: a single address, the one that connected directly to the ingress, for example your CDN.

What is new is one extra header. If the request already carried an X-Forwarded-For, haproxy-ingress copies its original value to X-Original-Forwarded-For before discarding it:

X-Forwarded-For: <cdn-or-proxy-ip>
X-Original-Forwarded-For: <whatever-the-client-sent>

On its own, X-Original-Forwarded-For is untrusted input. It is copied verbatim from whoever connected to the ingress, and anyone can put anything into it.

It becomes useful once your application checks who connected. X-Forwarded-For holds the address that opened the TCP connection to HAProxy, which the client cannot forge. If that address belongs to a CDN you trust, for example one of the published edge IPs of your provider, then X-Original-Forwarded-For is the header that CDN sent. Its rightmost entry is the address the CDN saw connecting to it.

HSTS Headers

haproxy-ingress defaults its Strict-Transport-Security header to max-age=15768000 (six months). ingress-nginx sent max-age=31536000 (one year).

RFC 6797 leaves the duration to the operator, and the two projects measure against different yardsticks. Six months is the minimum Qualys SSL Labs has required for an A+ grade since January 2014. HAProxy’s own documentation examples use a value just above it, max-age=16000000, described as “a bit more than 6 months”. When HAProxy published those examples, the HSTS preload list accepted a max-age shorter than one year. It has since raised the minimum to one year.

For standard web traffic, this has no functional impact. If your domain is on the HSTS preload list, however, six months fails validation. We therefore override the haproxy-ingress default and send max-age=31536000 (one year), the same value ingress-nginx did.

If you need a different duration, set spec.forProvider.hsts.maxAge on the IngressHAProxy resource (a duration, for example 8760h). For a single Ingress, set haproxy-ingress.github.io/hsts-max-age (in seconds).

Request Buffering

Under ingress-nginx, high-volume write endpoints produced warnings like this in the controller logs:

[warn] a client request body is buffered to a temporary file /tmp/nginx/client-body/0000000123
  request: "POST /loki/api/v1/push HTTP/1.1"

A while back, one node in our service cluster ran at 98% CPU, with its nginx pod using 1.4 cores mainly to write and clean up temporary disk buffers. On nginx, the fix was to set nginx.ingress.kubernetes.io/proxy-request-buffering: "off" on write-heavy Ingresses such as Loki, Promscale and container registries.

HAProxy streams request bodies to backends by default. There is no equivalent buffering annotation, because HAProxy does not write incoming payloads to disk.

Where This Leaves You

If you still use our managed ingress-nginx on NKE: as announced, support ended on 1 October 2026. HAProxy is available for every NKE cluster, and our migration documentation is the place to start.

If you are unsure how one of these differences affects your workloads, write to us at Emails are not allowed and we will look at it with you.

How to Run SafeLine WAF Behind an Nginx Reverse Proxy

Sun, 20 Sep 2026 01:44:17 +0000

How to Run SafeLine WAF Behind an Nginx Reverse Proxy

Sometimes Nginx is already your public edge — terminating TLS, serving static files, doing virtual hosting. You can keep Nginx exactly where it is and place SafeLine behind it, so Nginx forwards traffic to SafeLine for inspection before it reaches your app.

The topology

Client → Nginx (edge / TLS) → SafeLine (inspects) → upstream app

Nginx stays the entry point. Instead of proxying straight to your app, it proxies to SafeLine; SafeLine then proxies to the real upstream. You get Nginx's edge features plus SafeLine's WAF filtering.

Step 1 — Install SafeLine

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

Step 2 — Tell SafeLine where the app is

In the SafeLine console (https://<safeline-ip>:9443), add a protected site whose upstream is your actual app, e.g. http://127.0.0.1:3000 or http://10.0.0.10:8080. SafeLine will listen on its own port (default :80) and forward clean traffic there.

Step 3 — Point Nginx at SafeLine

Change Nginx's proxy_pass from the app to SafeLine. A minimal upstream looks like:

upstream safeline {
    server 127.0.0.1:80;   # SafeLine's listener
}

server {
    listen 443 ssl;
    server_name app.example.com;

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

Reload Nginx. Traffic now flows Client → Nginx → SafeLine → app.

Step 4 — Preserve the real client IP

Because Nginx proxies to SafeLine, SafeLine sees Nginx's address by default. Pass X-Forwarded-For (above) and configure SafeLine's trusted-proxy / client-IP setting so its logs show the real visitor IP rather than Nginx's.

FAQ

Why put SafeLine behind Nginx instead of in front?

If Nginx already handles TLS, redirects, or static assets you don't want to move, keeping it at the edge and forwarding to SafeLine is the least-disruptive way to add a WAF.

Can SafeLine also do TLS?

Yes — you can terminate TLS at SafeLine instead. Behind-Nginx just describes the case where Nginx keeps that job.

Does this affect performance much?

SafeLine adds one lightweight proxy hop; for most sites the latency is negligible.

Free tier?

The Community Edition covers 10 apps at 800 QPS for free.

That's it — Nginx stays your edge, and SafeLine quietly filters everything behind it.

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

SafeLine WAF vs Nginx WAF: Why a Dedicated Engine Beats a Module

Fri, 11 Sep 2026 02:39:56 +0000

SafeLine WAF vs Nginx WAF: Why a Dedicated Engine Beats a Module

"Nginx WAF" usually means either the commercial NGINX WAF module or ModSecurity
bolted onto nginx. SafeLine is a standalone, self-hosted WAF you place in front of nginx. The
difference is where the intelligence lives.

The nginx approach

nginx itself is a great reverse proxy and can host a WAF module. The commercial NGINX WAF and the
ModSecurity/CRS combo both work, but they inherit the same tuning burden: you manage rules,
thresholds, and false positives.

SafeLine in front of nginx

SafeLine sits as a reverse proxy before your nginx upstream. Requests are inspected by its
semantic-analysis engine before they ever reach your app server. Because detection is based on
request intent rather than a signature list, you spend less time writing exception rules.

Why a dedicated engine helps

Clean separation: WAF logic lives in its own container; your nginx config stays about
routing.
Central dashboard: SafeLine gives you a web UI at https://<ip>:9443 for policies, logs,
and alerts.
Lower false positives: semantic analysis is gentler on legitimate, unusual traffic.

FAQ

Do I have to remove nginx?

No. Keep nginx for routing; put SafeLine in front as the inspection layer.

Can I run it on the same host?

Yes, as a container sharing the host network or a dedicated port.

Is it free?

The Community Edition is free for 10 apps at 800 QPS.

Wrap Up

If you want a self-hosted WAF you fully control, SafeLine is worth a look. It sits in
front of your existing stack as a container, uses a semantic-analysis engine to catch SQL
injection, XSS, and bot abuse with very low false positives, and the Community Edition is
free.

Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Live demo: https://demo.waf.chaitin.com:9443/statistics

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

How to Configure Nginx as an HTTPS Proxy Server?

Tue, 02 Jun 2026 16:03:57 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In previous article we could able to setup basic nginx server and server simple html page.

Now let's setup https for our nginx server.

Requirements

Before we start setting up https we should do the following:

Buy a domain name from any registrar.
Set up dns records to point to our server ip.
Setup Certificate for our domain name.
Install nginx on our server.
Set up nginx server to serve our website.

Buying Domain Name

We can buy domain name from any registrar like Namecheap, GoDaddy, etc.

It depends on which name it is and the charges will be around

Setting Up DNS Records

Once buy setup the dns records to point to our server ip.

Example:
For your server the ip address is [IP_ADDRESS].
And your domain name is [EMAIL_ADDRESS]

So, you need to set up a dns record to point to your server ip.

Setting up Certificate

Now let's setup certificate for our domain name.

example.com

so, we setup

sudo certbot --nginx -d `example.com` --email [EMAIL_ADDRESS] --agree-tos --no-eff-email

Here is simple workflow on how certificate is fetched and how

Key generation

The Certbot generates a private key and a CSR (Certificate Signing Request) entirely on your machine.

The private key is the core security guarantee.

HTTP-01 Challenge

Let's Encrypt needs to verify you actually control example.com. It sends Certbot a random token.

Certbot places it at:

/var/www/html/.well-known/acme-challenge/<random-token>

Nginx (already running on port 80) serves this file publicly.

Let's Encrypt fetches the token

LE makes a plain HTTP request to http://example.com/.well-known/acme-challenge/<token>.

If it gets the right response back, it's satisfied that you own the domain.

This is why DNS must be pointing to your server before you run Certbot — if the domain pointed elsewhere, LE would fetch the token from the wrong machine and the challenge would fail.

Certificate issued & saved

LE signs and returns your certificate.

Certbot saves four files to /etc/letsencrypt/live/example.com/:

File	What it is
`fullchain.pem`	Your cert + intermediate CA chain (this is what Nginx uses)
`privkey.pem`	Your private key (Nginx uses this too)
`cert.pem`	Just your cert alone
`chain.pem`	Just the CA chain alone

Nginx config is rewritten

Certbot patches your server block to add the listen 443 ssl lines and the cert paths, and adds a new server { listen 80; } block that redirects all HTTP traffic to HTTPS.

Then it reloads Nginx for you.

Setting up with nginx

Assuming your application running in local host 8090. and you are setting up https for your domain name example.com.

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # All requests — public, no auth
    location / {
        proxy_pass http://localhost:8090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Add to symlink to sites enabled

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

Restarting nginx

sudo nginx -t && sudo systemctl reload nginx

Conclusion

We could get https for our domain name example.com.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Developer Journal..“My First Docker + Nginx Setup on Ubuntu”

Sat, 16 May 2026 14:24:42 +0000

Hello Everyone!

A while ago, I decided to learn Docker and, honestly, it turned out to be much simpler than I expected. In this article, I’ll walk you through how I configured Docker on Windows using WSL (Windows Subsystem for Linux) and ran my very first container.

If you're a developer using Windows and want to get into Docker, this post is for you.

Spoiler: At the end, you’ll see the Nginx welcome page in your browser — and that feeling is amazing

What is Docker? (In Simple Terms)

Docker is a platform that allows you to package your application inside a “container” — an isolated and portable environment that behaves the same way on any machine.

Think of it as a sealed box containing everything your app needs to run.

Prerequisites

Before getting started, you’ll need:

✅ Windows 10 or 11
✅ WSL (Windows Subsystem for Linux) enabled
✅ A Linux distribution installed (we’ll use Ubuntu)
✅ PowerShell running as Administrator
Step 1: Verify and Install WSL

WSL allows you to run Linux commands directly on Windows. Let’s first verify whether it’s installed.

Option A: List all available distributions
wsl --list --online

This command will show all Linux distributions available for installation.

Option B: Install Ubuntu on WSL (if you don’t already have it)
wsl --install -d Ubuntu
Option C: Check installed distributions
wsl --list --verbose

This command is very useful because it shows the state and version of each installed distribution.

Step 2: Open Ubuntu in WSL

From PowerShell, type:

wsl -d Ubuntu

You should see something like:

user@PC:~$

Congratulations! You are now inside Ubuntu. From this point on, all commands will be Linux commands.

Step 3: Verify and Install Docker

First, let’s check if Docker is already installed:

docker --version

If Docker is not installed, you’ll see a message suggesting available packages. Install it with:

sudo apt-get install docker.io -y

The -y flag automatically answers “yes” to confirmation prompts, saving time.

Verify the installation
docker --version

You should see something like:

Docker version 24.0.x
Step 4: Enable and Start the Docker Service

Docker is now installed, but we still need to start the service.

Enable Docker to start automatically
sudo systemctl enable docker
Start the service immediately
sudo systemctl start docker
Step 5: Fix Permission Errors

If you encounter an error like this while running Docker commands:

PERMISSION DENIED WHILE TRYING TO CONNECT TO THE DOCKER API AT UNIX:///VAR/RUN/DOCKER.SOCK

Don’t worry! This is completely normal. Docker requires special permissions.

Add your user to the Docker group:

sudo usermod -aG docker your_user

Replace your_user with your Linux username.

Now you have two options:
Option 1 (Recommended): Close and reopen Ubuntu
exit

Then reopen it from PowerShell:

wsl -d Ubuntu
Option 2: Activate the group immediately
newgrp docker
Verify everything works
docker ps

If you see an empty table with headers like CONTAINER ID, IMAGE, etc., Docker is working correctly

Step 6: Run Your First Container (Nginx)

Here comes the fun part. Let’s run Nginx, one of the most popular web servers:

docker run -d -p 8080:80 nginx
What does this command do?
docker run → Runs a container
-d → Runs it in detached mode (background)
-p 8080:80 → Maps port 8080 on your machine to port 80 inside the container
nginx → The image you want to run (Docker will download it automatically)

You should see something similar to:

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
Digest: sha256:abc123...
Status: Downloaded newer image for nginx:latest
a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

That last string is your container ID.

Your container is now running

Step 7: Verify the Container is Running
docker ps

You should see your container listed with the status Up.

Step 8: The Best Part — Open it in Your Browser

Open any browser on Windows (Chrome, Firefox, Edge, etc.) and go to:

http://localhost:8080

If everything worked correctly, you’ll see the beautiful Nginx welcome page saying:

“Welcome to nginx!”

That feeling when you realize everything is actually working is incredible

Additional Useful Commands

Here are a few Docker commands you’ll probably want to know:

View all containers (including stopped ones)
docker ps -a
Stop a container
docker stop CONTAINER_ID
Remove a container
docker rm CONTAINER_ID
View container logs
docker logs CONTAINER_ID
Lessons Learned

✅ WSL is essential: Without WSL, Docker on Windows can feel complicated. With WSL, the experience becomes much smoother.

✅ Permissions matter: “Permission Denied” errors are completely normal. It’s not a broken installation — you just need the correct user group permissions.

✅ Docker is beginner-friendly: The Docker ecosystem has done an excellent job making containerization accessible.

✅ Documentation is your best friend: If something breaks, check the logs using docker logs.

What’s Next?

Now that Docker is working, you can:

Build your own Dockerfile for a personal application
Explore Docker Hub and discover thousands of pre-configured images
Learn Docker Compose for multi-container orchestration
Publish your own images on Docker Hub
Final Thoughts

My first experience with Docker on Windows was honestly great.

The process is clear, well documented, and most importantly — you get immediate results. And that’s one of the best ways to learn.

If you’re thinking about learning Docker:

Don’t wait any longer.

The journey into containerization begins with a simple:

docker run

Have questions? Ran into problems? Share your experience in the comments — I’d love to hear about your first Docker setup too

References & Resources
Docker Official Documentation
WSL Documentation
Docker Hub

How to Configure and Control Nginx?

Tue, 21 Apr 2026 02:19:50 +0000

In previous article I explinaed how nginx works and what is the architecture of nginx.

Now let's configure it and controls nginx.

Understanding Nginx Controls

Reload

nginx -s reload

This signal is used to reload the configuration files of nginx.
It will not stop the nginx processes.
It will just reload the configuration files and start the new worker processes.
If old worker process serving few clients it will be served by old worker process.

Either master will stop old worker process or it will wait for the old worker process to finish serving the current requests.

This way if anything has issues nginx will not apply new configuration files.

Quit

nginx -s quit

This signal is used to quit the nginx processes.

It will stop the nginx processes and wait for the worker processes to finish serving the current requests.

Stop

nginx -s stop

This signal is used to stop the nginx processes.

It will stop the nginx processes and wait for the worker processes to finish serving the current requests.

To stop nginx with PID. We can use kill command.

kill -QUIT <master_pid>

We can also find all PID

ps -ax | grep nginx

Configure Nginx

nginx consists of modules which are controlled by directives specified in the configuration file.

These Directives are divided into simple directives and block directives.

Similar to C language, simple directive consists of the name and parameters separated by spaces and ends with a semicolon (;).

A block directive has the same structure as a simple directive, but instead of the semicolon it ends with a set of additional instructions surrounded by braces ({ and }).

If a block directive can have other directives inside braces, it is called a context (examples: events, http, server, and location).

Directives placed in the configuration file outside of any contexts are considered to be in the main context. The events and http directives reside in the main context, server in http, and location in server.

The rest of a line after the # sign is considered a comment.

Here is the simple example of nginx configuration file:

Main context: worker_processes 1;

events context: worker_connections 1024;

http context: we define server context here.

server context: In here we define this to listen port 80 which is http port.

location context: In here we define the root directory of the website.

So, any request coming to port 80 will be served by the worker process with the root directory of /var/www/html.

# This is a comment in the Main Context
worker_processes 1; 

events { 
    # This is a simple directive inside the 'events' context
    worker_connections 1024; 
}

http { 
    # We are now inside the 'http' context

    server { 
        # The 'server' context is nested inside 'http'
        listen 80; 

        location / { 
            # The 'location' context is nested inside 'server'
            root /var/www/html; 
        }
    }
}

Conclusion

We understood how to control nginx and how to configure nginx.

So, this makes solid foundation for us to understand how work with nginx.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

How Nginx Architecture is Designed and How They Work

Thu, 09 Apr 2026 02:36:18 +0000

In the previous article, We have seen how to setup nginx on ubuntu and enable the site. It was more into basic where anyone one who wants to configure domain or any other thing can follow it.

Now in this article we will explore a how nginx works.

How Nginx Architecture and How they Works?

Before we go into how nginx works, we need to understand the architecture of nginx.

Nginx has two main components:

Master Process
Worker Process

Master process is to read, evaluate configuration files and maintain worker process.

Worker Process will do all the processing of client requests.

Nginx works on principle of event-based and OS-dependent mechanisms to efficiently distribute requests among worker processes.

The number of worker process can be configured in the nginx.conf file and this can also be automatically set based on the number of CPU cores available on the system.

For more information on how to configure the number of worker process, please refer to the official documentation Worker Processes.

By default, the configuration file is named nginx.conf and placed in the directory /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx.

How to Start, Stop and Reload Nginx?

To Control any operation of nginx, we need to use the executable file.

This will be having this syntax:

nginx -s signal

Where signal may be one of the following:

stop — fast shutdown
quit — graceful shutdown
reload — reloading the configuration file
reopen — reopening the log files

For example, to stop nginx processes with waiting for the worker processes to finish serving current requests, the following command can be executed:

nginx -s quit

Conclusion

As of now we understand how Nginx architecture works and how to control Nginx.

In the next article, we will go in-depth on how to use these signals to control Nginx.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Beyond `chmod 755`: A Senior Engineer’s Guide to Debugging Nginx 403 Forbidden

Tue, 24 Mar 2026 08:02:06 +0000

The 403 Forbidden error in Nginx is deceptively simple. At face value, it signals "access denied." In practice, it is the result of a decision chain that spans filesystem permissions, process identity, kernel-level security controls, and upstream security layers.

The common reflex—chmod -R 777—removes friction by collapsing the permission model. It also destroys any meaningful security boundary. The correct approach is to treat a 403 as a diagnostic signal, not a configuration annoyance.

This guide breaks down the problem the way it actually manifests in production systems.

The Foundation: Filesystem Traversal and Process Identity

Nginx does not operate as root (beyond initial binding). It runs as a constrained user such as www-data or nginx. That user must be able to traverse the entire directory chain, not just read the target file.

Given a path:

/var/www/app/public/index.html

The required condition is:

r on the file
x on every parent directory

A failure at any level results in a 403.

To inspect this precisely:

namei -om /var/www/app/public/index.html

Typical problematic output:

drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-x--- root root www
drwx------ root root app
drwxr-xr-x root root public
-rw-r--r-- root root index.html

Here, /var/www/app is 700, which blocks traversal for the Nginx worker.

Corrective action is not "open everything," but align ownership and minimal permissions:

chown -R www-data:www-data /var/www/app
chmod 755 /var/www/app

The Configuration Layer: Index Resolution and Access Semantics

Nginx does not assume behavior. If a request targets a directory, resolution depends on explicit configuration.

Example request:

GET /assets/ HTTP/1.1

If no index file exists and directory listing is disabled (default), Nginx returns 403.

Relevant configuration:

location /assets/ {
    root /var/www/app/public;
    index index.html;
    autoindex off;
}

Failure modes:

index file missing → 403
autoindex off → no fallback
incorrect root or alias → silent mismatch

To verify effective resolution, use:

nginx -T | grep -A5 "location /assets/"

The Kernel Layer: SELinux and AppArmor

If permissions appear correct but 403 persists, the denial is often happening below Nginx, enforced by Mandatory Access Control (MAC).

On SELinux-enabled systems, file context is decisive.

Incorrect context example:

ls -Z /var/www/app/public

-rw-r--r-- user user unconfined_u:object_r:user_home_t:s0 index.html

Expected context:

httpd_sys_content_t

Fix:

chcon -R -t httpd_sys_content_t /var/www/app/public

Or persistently:

semanage fcontext -a -t httpd_sys_content_t "/var/www/app/public(/.*)?"
restorecon -Rv /var/www/app/public

To confirm denial source:

ausearch -m avc -ts recent

If AppArmor is in use (Ubuntu), check:

dmesg | grep DENIED

At this layer, Nginx is functioning correctly. The kernel is rejecting the access.

The Security Layer: WAF-Induced 403s

In modern deployments, a 403 often originates before the request reaches Nginx logic.

Indicators:

Only specific payloads trigger 403
Requests with SQL keywords, encodings, or long parameters fail
Static assets load normally

Example:

GET /api/user?id=1 OR 1=1

Traditional WAFs (e.g., ModSecurity with OWASP CRS) rely on regex-heavy rule sets:

SecRule ARGS "(?i:(union select|sleep\())" "id:1001,deny,status:403"

Problems:

High false positive rate
Poor explainability
Debugging requires rule tracing across multiple layers

This leads to a common failure mode: engineers disable rules to restore functionality.

Moving Toward Deterministic Visibility

The core issue with 403 debugging is not complexity—it is lack of attribution.

You need to answer one question precisely:

Which layer denied the request?

A modern WAF such as SafeLine changes the model from passive blocking to explicit classification.

Instead of opaque rule triggers, it provides structured reasoning:

attack type (e.g., SQL injection, RCE pattern)
confidence score
matched behavioral pattern
request context

Example event:

{
  "client_ip": "203.0.113.10",
  "path": "/api/user",
  "attack_type": "SQL_INJECTION",
  "action": "BLOCKED",
  "confidence": 0.97
}

This eliminates ambiguity between:

misconfigured nginx.conf
filesystem permission failure
kernel-level denial
security-layer intervention

Practical Debugging Order (Production-Grade)

When encountering a 403, the fastest resolution path is:

1. Filesystem traversal (namei)
2. Nginx config resolution (root, index, alias)
3. MAC layer (SELinux / AppArmor)
4. Upstream security (WAF / rate limiting)

Skipping layers leads to misdiagnosis.

Final Observation

A 403 is not an error in isolation. It is a policy decision made somewhere in the request pipeline.

Junior handling removes the policy.

Senior handling identifies which policy fired and why.

The difference is whether your system remains secure after the fix.

F5's AI-Powered WAF Stopped a ChatGPT-Generated Attack — Without a Single Signature

Sun, 15 Mar 2026 21:27:17 +0000

The attack took about 30 seconds to set up. Open ChatGPT. Ask it to generate a SQL injection payload. Copy the output. Paste it into a login form.

The payload that came back wasn't a known attack signature. It was a SQL injection wrapped around JSON extraction — a combination specific enough that no static rule had seen it before. When Kunal Anand, Chief Product Officer at F5, dropped it into a test finance application during the closing keynote at F5 AppWorld 2026, it worked. JSON data containing sensitive information echoed back immediately. The application was compromised in under a minute using a payload generated on demand by a consumer AI tool.

Then Anand enabled F5's new AI-enhanced WAF layer, went back to the login form, and dropped the same payload in again.

Blocked. No new signatures. No new definitions. No prior knowledge of that specific attack pattern is required.

That demo was the clearest illustration of what F5 announced at AppWorld this week: a fundamentally different approach to web application security, built on a neural network trained from scratch on F5's own traffic data.

Why Static Signatures Are Structurally Obsolete

Web application firewalls have always worked on pattern matching. Signatures, regular expressions, and known attack strings — the WAF maintains a library of what bad traffic looks like and blocks anything that matches. It's a proven model with decades of operational history.

The problem is that the model assumes a relatively stable attack landscape. New attack patterns emerge, security researchers identify them, vendors push signature updates, and defenders catch up. The cycle has latency, but it works—as long as attackers operate from a finite library of known techniques.

AI changes that assumption. An attacker with access to a capable language model can generate novel payloads on demand, specifically designed to evade known signatures. The attack surface is no longer a finite library — it's the combinatorial space of everything a capable AI can produce. Static signatures, by definition, can't keep up with that.

Anand was direct about the implications at AppWorld: "These AI agents and technologies are able to generate brand new payloads on the fly. They can learn, they can build something new, and they can counter those static rules and those static definitions, rendering them structurally obsolete."

If the attacker can learn in real time, the defense has to as well.

What F5 Built

F5 didn't patch their existing WAF. They built a new layer on top of it.

The foundation — signatures, pattern matching, attack indicators, risk intelligence — remains in place. F5 treated it as the base, not the ceiling. On top of that foundation, they trained a transformer model from scratch using their own traffic data. Not a model pulled from an open source repository. Not a general-purpose LLM fine-tuned for security. A purpose-built neural network trained on F5's proprietary dataset.

The technical constraint they solved for is important: the model runs on CPUs. No GPUs required. That means it can operate at the edge, in resource-constrained environments, without blowing up latency budgets. Bringing AI inference into the live traffic path is viable only if it doesn't introduce meaningful latency. F5's model is efficient enough to do that.

The result is a WAF that can evaluate traffic it has never seen before and make an accurate, real-time decision about whether it's malicious — without needing a signature for that specific attack.

The Numbers

F5 shared performance data from the production deployment of the AI-enhanced WAF in December. The results are concrete enough to matter:

Ten zero-day attacks were caught in December alone — without prior signatures or definitions. The model identified them as malicious based on behavioral patterns rather than known signatures.

False positive rate for new signatures dropped from 28% to 1%. That number deserves emphasis. A 28% false-positive rate for new signatures means more than a quarter of legitimate traffic is flagged as malicious when new attack patterns emerge. Getting that to 1% is the difference between a security control that creates operational chaos and one that actually works in production.

Out-of-the-box accuracy for new signatures went from 64% to 98%. Day-one accuracy without tuning or customization — which is what most organizations actually deploy into — improved from barely acceptable to near-production-ready.

These are not F5's internal benchmarks. Anand noted during the keynote that the numbers were independently verified by a third party.

Agentic Ransomware: The Threat Context

To explain why this matters, Anand shared a story from a recent conversation with a CISO.

The CISO described an agentic ransomware attack. The ransomware wasn't delivered by a human operator — it was propagated by an AI agent that handled every stage of the attack: target selection, social engineering, negotiation, and cryptocurrency collection. The victim communicated with what they believed was a human throughout. The pauses, the urgency, the negotiation cadence — all machine-generated. When the decryption key was provided and the ransom paid, the agent simply disappeared.

The security implication is precise: the adversary is no longer a human operating a tool. It's a system. That system doesn't get tired, doesn't make social-engineering mistakes, doesn't operate under human time constraints, and can run multiple simultaneous attack campaigns. A defense built on detecting human behavioral patterns has a structural blind spot.

The Roadmap: Toward Self-Improving Security

Anand described where F5 is taking this capability. The current version requires human approval before new AI-generated signatures go into production. The future state they're building toward is an agentic defense system that can operate continuously — analyzing traffic, generating candidate signatures, running them through controlled tests, and presenting validated signatures to humans for production deployment.

The human stays in the loop for the final decision. Everything before that step runs automatically. The result is a security system that continuously improves itself, compounding accuracy and efficiency over time, without requiring a human to perform the analytical work that currently creates latency between discovery and protection.

"There will be a time when AI will be good enough," Anand said. "We're not there yet. But we want to design for that world now."

The Token Economy and BIG-IP on BlueField

The closing keynote covered more than the WAF. Anand spent significant time on what he called the token economy — the economics that govern AI inference at scale.

He framed the metric shift clearly. For application and API teams, the unit of measure has always been requests per second. For AI workloads, the unit that matters is tokens per second. The five variables that govern performance in the token economy are throughput (tokens per second), perceived responsiveness (time to first token), cost (cost per token), total latency (end-to-end response time), and energy efficiency (tokens per watt).

That last variable, he argued, is the most important constraint at scale. Energy is the ultimate thermodynamic limit on AI infrastructure. Organizations that aren't optimizing for tokens per watt are burning margins as well as power.

F5's answer at the infrastructure layer is BIG-IP running on NVIDIA's BlueField DPU. The thesis: handle delivery and security before requests ever reach the GPU cluster, in a single pass, using the DPU's dedicated processing capacity.

The independent performance numbers from third-party testing:

40% increase in total throughput. For organizations running AI inference at scale, that's more tokens from the same hardware.

60% reduction in time to first token. This is the metric that governs perceived intelligence — how quickly the model starts responding. A 60% improvement is the difference between a model that feels responsive and one that feels slow.

30% improvement in end-to-end latency.

F5 announced that iRules, expanded token counting, and AI Guardrails are all coming to the DPU platform over the next year. The goal is to bring the same delivery and security controls available at the application layer directly into the AI factory infrastructure — so that as AI inference scales, the governance capabilities scale with it.

What This Means for Engineering Teams

For teams running web applications, the practical implication of an AI-enhanced WAF is that the signature maintenance burden is reduced. Not eliminated — the static signature layer still runs — but the manual tuning work required to keep false positives manageable is significantly reduced when the AI layer is doing behavioral analysis in parallel.

For teams building AI inference infrastructure, the BIG-IP on BlueField numbers present a compelling case for rethinking where security and delivery processing occur. If you can get 40% more throughput from existing hardware by moving those workloads to a DPU, the math on when to add more GPU capacity changes.

The broader argument Anand made at the close of AppWorld is worth taking seriously. The path from a user prompt to a token — ingress, workflows, inference — has control points at every stage. The organizations that understand those control points and apply appropriate security and delivery controls at each one will be better positioned as AI workloads grow. Those that don't will find the problem harder to address later, when traffic volumes are higher and the attack surface is wider.

The bottleneck, as Anand put it, is no longer source code. It's imagination. And the infrastructure that runs what imagination produces needs to be ready for it.

NGINX Is Already in Front of Your AI Workloads. F5 Says That's the Point.

Fri, 13 Mar 2026 02:16:08 +0000

When enterprises start deploying AI workloads, they typically go looking for a dedicated AI gateway. F5 thinks that's the wrong instinct — and they have a straightforward argument for why.

About 50% of NGINX deployments already sit in front of Kubernetes clusters. When AI workloads land in those same clusters, NGINX is already there. It's already trusted. It's already in the traffic path. The question F5 is answering with its NGINX AI gateway strategy isn't "how do we build something new?" It's "why would you add something when what you need is already running?"

Shawn Wormke, SVP of Product Management at F5, put it plainly during AppWorld 2026 in Las Vegas: "It doesn't require people to change. And I think that's the biggest differentiator."

That's the bet. And for developer and platform teams who have spent years standardizing on NGINX, it's worth understanding what that actually means in practice.

What MCP Traffic Is Revealing

One of the more significant things coming out of F5's NGINX work isn't a feature — it's what visibility into MCP traffic is showing enterprises about their own environments.

MCP, the Model Context Protocol, is the emerging standard for how AI agents communicate with tools, APIs, and data sources. When NGINX parses MCP metadata, it gives operations teams a view into AI activity that most enterprises didn't know they were missing.

What they're finding is that more AI is already running than anyone realized. More sensitive data is being accessed. More shadow AI is operating in the background. The visibility problem turns out to be bigger than the security problem — and you can't address the second until you've solved the first.

For platform teams, this is a meaningful shift. The same proxy that handles your web traffic can now surface what your AI agents are actually doing, who they're talking to, and what data they're touching. No new tooling required. No rearchitecting the stack.

NGINX MCP visibility is now generally available in NGINX Open Source. Enterprise support is available through NGINX Plus.

The AI Gateway Argument

The case for a separate AI gateway usually goes something like this: AI traffic is different, AI models need specialized routing, and purpose-built tools handle it better than general-purpose infrastructure.

F5's counter-argument is operational. A dedicated AI gateway means another tool to deploy, another vendor to manage, another configuration surface to maintain, and another potential point of failure between your users and your models. If NGINX is already handling traffic management, TLS termination, and load balancing for the applications sitting next to your AI workloads, adding a separate gateway layer creates complexity without adding capability.

The argument gets sharper when you look at where enterprises actually are in their AI deployments. Wormke was direct about this at AppWorld: the narrative about enterprise AI adoption doesn't always match reality. "If you read everything on the internet about AI, you think all of these customers are doing all this stuff. But the reality is, some are. A lot of enterprises are just trying to figure it out."

For the majority of organizations still in early deployment stages, the last thing they need is infrastructure sprawl. NGINX as an AI gateway works because it's already there.

What NGINX Handles in the AI Traffic Path

Within F5's ADSP platform, NGINX addresses several specific problems in the AI traffic path.

Routing and load balancing for AI model endpoints works the same way it works for any application — with the addition of LLM-specific routing logic that can direct requests based on model type, token budget, or other AI-specific parameters.

Rate limiting and quota enforcement matter more with AI workloads than with traditional applications because token costs are real and variable. NGINX can enforce limits at the gateway layer before requests ever reach the model.

Observability via MCP parsing gives teams visibility into agent behavior — what actions agents are taking, what tools they're calling, and what data they're accessing. This is genuinely new capability. Traditional application observability doesn't capture the semantic content of AI interactions. MCP visibility does.

Security controls apply the same WAF and bot defense capabilities that already protect your web applications to AI traffic — including protection against prompt injection and model abuse.

The Rollout Sequence

F5 is sequencing the NGINX AI gateway capabilities based on where they see the most immediate customer pain. Automated certificate management is first — operationally unglamorous, but a real friction point for teams managing certificates across large NGINX deployments. AI-specific capabilities build on top of that foundation.

The broader NGINX roadmap runs through 2026 and into 2027 as part of F5's ADSP platform expansion. BIG-IP got F5 Insight first. NGINX and Distributed Cloud follow as the platform matures.

For developer and platform teams already running NGINX, the practical implication is straightforward: the infrastructure you have is being extended to handle AI workloads without requiring you to replace it or work around it. That's a different kind of product story than most of what gets announced at conferences. It's not about adding something new. It's about making what you already trust more capable.

And in a period when most engineering teams are already managing more complexity than they'd like, that distinction matters.

How I Built a Secure Reverse Proxy with Nginx

Wed, 11 Mar 2026 06:55:31 +0000

A reverse proxy is one of the most powerful building blocks in modern web infrastructure. It sits between users and your backend services, acting as a gatekeeper that can improve performance, enforce security policies, and control traffic.

In this article, I'll walk through how I built a secure reverse proxy using Nginx, including:

Reverse proxy architecture
Rate limiting to stop abuse
Security headers for safer responses
Request logging for visibility

By the end, you'll have a practical setup you can deploy in front of your applications.

Reverse Proxy Architecture

At a high level, a reverse proxy sits between clients and your backend servers.

Instead of users directly accessing your application server, all requests first go through the proxy.

Client
   │
   ▼
Reverse Proxy (Nginx)
   │
   ▼
Application Server

Benefits of this architecture:

Hide internal infrastructure
Centralize security policies
Terminate TLS in one place
Add traffic filtering and monitoring

Example scenario:

Internet
   │
   ▼
Nginx Reverse Proxy
   ├── API Server (Node.js)
   ├── Web App (React / Next.js)
   └── Admin Panel

This makes Nginx the entry point for all incoming traffic.

Basic Nginx Reverse Proxy Configuration

A simple reverse proxy configuration might look like this:

server {
    listen 80;

    server_name example.com;

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

What this does:

Accepts HTTP requests
Forwards them to the backend application
Preserves client IP information

This is the foundation, but by itself it doesn't provide much security.

Adding Rate Limiting

Public services often face bot traffic, scanners, and brute-force attacks.

Rate limiting helps protect your application by restricting how many requests a client can make.

First, define a rate limit zone:

http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
}

Then apply it in your server block:

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://backend_api;
}

This configuration:

Limit: 10 requests per second
Burst: allow short spikes
Protects API endpoints from abuse

Rate limiting is especially effective against automated scanners and brute-force attacks.

Adding Security Headers

Security headers help protect browsers and users from common web vulnerabilities.

You can add them directly in Nginx.

Example configuration:

add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header X-XSS-Protection "1; mode=block";
add_header Referrer-Policy "no-referrer-when-downgrade";
add_header Content-Security-Policy "default-src 'self'";

These headers help defend against:

clickjacking
content-type sniffing
cross-site scripting
data leakage

They add an additional layer of client-side protection.

Enabling Access Logging

Logging is essential for visibility and incident response.

With Nginx logs you can:

detect suspicious traffic
identify attack patterns
debug application issues
analyze performance

Example configuration:

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

You can also customize log formats:

log_format security_log '$remote_addr - $request - $status - $http_user_agent';

access_log /var/log/nginx/security.log security_log;

Useful data in logs:

client IP
request path
HTTP status codes
user agents
request timing

Logs often reveal automated scanning and attack attempts hitting your endpoints.

Extra Hardening Tips

In production environments, you may want to go further.

Additional best practices:

Enable HTTPS with TLS
Disable unnecessary HTTP methods
Hide server version information
Restrict admin endpoints
Use upstream health checks

Example:

server_tokens off;

This prevents Nginx from exposing its version number in responses.

Final Thoughts

A reverse proxy is much more than just a traffic router — it can act as a powerful security layer in front of your applications.

With a few Nginx configurations you can implement:

traffic control
security headers
request logging
basic attack mitigation

These protections significantly reduce your exposure to automated attacks.

If you want a ready-to-use security layer, projects like SafeLine WAF implement many of these protections out of the box.

Inside a Web Application Firewall: How WAFs Actually Inspect HTTP Traffic

Fri, 06 Mar 2026 11:36:34 +0000

A practical look at how Web Application Firewalls analyze HTTP requests, detect attacks, and fit into modern DevOps infrastructure.

A Web Application Firewall (WAF) protects web applications by inspecting HTTP requests at the application layer.

Unlike traditional firewalls, it analyzes:

URLs
Query parameters
Headers
Cookies
Request bodies
File uploads

WAFs detect attacks like:

SQL Injection
Cross-Site Scripting (XSS)
Command Injection
File Upload Exploits
Application-layer DDoS

But they work best when combined with secure coding practices and proper DevOps observability.

Why WAF Still Matters in Modern Infrastructure

If your API or web service is public, it is already being scanned.

Typical traffic hitting public endpoints often looks like this:

GET /phpmyadmin
GET /.env
GET /wp-login.php
GET /admin
GET /api/users?id=1 OR 1=1

These requests are usually automated vulnerability scans.

A WAF acts as a filter between the internet and your application.

Typical deployment architecture:

Internet
|
v
+-----------+
| CDN |
+-----------+
|
v
+-----------+
| WAF |
+-----------+
|
v
+-----------+
| Load Bal. |
+-----------+
|
v
+-----------+
| Web App |
+-----------+

The WAF intercepts every HTTP request before it reaches the backend.

Step-by-Step: How a WAF Processes a Request

A typical WAF request lifecycle looks like this:

Client Request
|
v
Request Parsing
|
v
Rule Matching
|
v
Risk Scoring
|
v
Allow / Block / Log

Step 1: HTTP Request Parsing

Before detection begins, the WAF extracts request fields.

Example request:

POST /api/login HTTP/1.1
Host: example.com
User-Agent: sqlmap
Content-Type: application/json

{
 "username":"admin",
 "password":"' OR 1=1 --"
}

The WAF parses this request into structured fields:

requestMethod = POST
requestURI = /api/login
userAgent = sqlmap
requestBody = JSON payload
headers = HTTP headers

These fields are then inspected by the detection engine.

Step 2: Rule Matching

Most WAF engines rely on signature-based detection.

Example rule detecting SQL injection:

rule_id: 10001
description: Detect SQL injection
match:
  field: requestBody
  pattern: "(union select|or 1=1|sleep\()"
action: block

Example rule detecting vulnerability scanners:

rule_id: 20002
description: Block vulnerability scanners
match:
  field: userAgent
  pattern: "(sqlmap|nikto|nmap)"
action: block

When a request matches a rule, the configured action is executed.

Example: ModSecurity Rule

Many production deployments use NGINX + ModSecurity as a Web Application Firewall.
Below is an example rule that detects common SQL injection patterns in incoming requests.

SecRule REQUEST_URI|ARGS|REQUEST_BODY "@rx (union\s+select|sleep\(|benchmark\()" \
"id:10010,\
phase:2,\
block,\
msg:'SQL Injection attempt detected'"

Parameter	Meaning
`REQUEST_URI`	Inspect the URL path
`ARGS`	Inspect query parameters
`REQUEST_BODY`	Inspect POST request body
`@rx`	Perform regex pattern matching
`phase:2`	Execute rule after request body parsing
`block`	Deny the request

Step 3: Request Scoring

Modern WAFs rarely block based on a single rule.

Instead, they use a risk scoring model.

Example scoring system:

SQL injection pattern +5
XSS payload +4
Scanner user-agent +2
Suspicious encoding +2

Example threshold:

score >= 5 → block request
score < 5 → allow request

This approach reduces false positives.

Real Attack Example

Example malicious request:

GET /api/products?id=1 UNION SELECT username,password FROM users

Detected pattern:

union select

Response:

HTTP 403 Forbidden

The request never reaches the backend server.

DevOps Example: Rate Limiting

Application-layer attacks often involve high request rates.

Example NGINX rate limiting configuration:

limit_req_zone $binary_remote_addr zone=login_limit:10m rate=10r/s;

server {

  location /login {

    limit_req zone=login_limit burst=20 nodelay;

  }

}

This protects login endpoints from:

brute force attacks

credential stuffing

CC attacks

WAF Logging for Security Monitoring

Logging is critical for security operations.

Example log entry:

{
 "timestamp":"2026-03-05T11:22:09Z",
 "client_ip":"192.168.1.15",
 "uri":"/login",
 "rule_id":10010,
 "attack_type":"SQL Injection",
 "action":"blocked"
}

These logs can be forwarded to:

SIEM systems

security monitoring platforms

incident response pipelines

The Biggest Challenge: False Positives

No WAF is perfect.

Example legitimate request:

GET /search?q=select+product+from+store

A poorly designed rule might detect select as SQL injection.

Solutions include:

whitelisting trusted endpoints

adjusting rule thresholds

disabling noisy signatures

Proper tuning is essential for production environments.

Practical Advice for Engineers

If you operate production systems, consider the following best practices.

1. Always deploy a WAF

Especially for services that are directly exposed to the internet:

Public APIs
Authentication endpoints (e.g., /login, /auth)
File upload services
Payment or account management systems

A WAF can filter large amounts of automated attack traffic before it reaches your application layer.

2. Start in monitor mode

Before enabling blocking rules, it is recommended to run the WAF in monitor (or detection-only) mode.

This allows engineers to:

observe real traffic patterns
identify potential false positives
understand how rules interact with the application

Only after analyzing logs and tuning rules should blocking be fully enabled.

3. Continuously tune rule sets

No rule set works perfectly out of the box.

Production environments often require continuous adjustments such as:

disabling overly aggressive rules
adjusting anomaly score thresholds
creating endpoint-specific rule exceptions

Regular rule tuning significantly reduces false positives while maintaining protection.

4. Implement layered security

A WAF should not be treated as the only security control.

Instead, it should be part of a defense-in-depth strategy that includes:

input validation at the application layer
strong authentication mechanisms
rate limiting and request throttling
vulnerability scanning and patch management
centralized logging and monitoring

Combining multiple defensive layers greatly improves overall security posture.

Final Thoughts

A Web Application Firewall is essentially a programmable HTTP inspection engine that sits between the internet and your application.

By analyzing requests in real time, it can detect and block a wide range of common web attacks before they reach backend services.

However, the effectiveness of a WAF depends heavily on:

proper configuration
continuous rule tuning
integration with monitoring and security operations

When deployed correctly, a WAF can dramatically reduce the attack surface of modern web applications while providing valuable visibility into malicious traffic patterns.

Nginx Setup in 6 Steps: From Installation to Production

Sat, 31 Jan 2026 12:01:13 +0000

Solved every nginx problem I encountered while building production servers. Here's the complete guide!

Problems → Solutions

"Where do I even start?"

VPS Selection Guide - nginx minimum requirements, sizing guide, hosting recommendations

"nginx won't start after installation"

Proper Installation - nginx.conf with correct syntax, test with nginx -t

"SSL errors / HTTPS not working"

Domain Configuration - Complete nginx SSL/TLS setup, HTTP/2 configuration, certificate paths

"413 Request Entity Too Large"

Upload Fix - Configure client_max_body_size properly

"Slow performance / high CPU usage"

Performance Optimization - Enable gzip, caching, optimize buffers

"Poor search engine visibility"

SEO Setup - robots.txt and sitemap.xml configuration

Additional Help

Comprehensive FAQ section
nginx best practices for avoiding issues
Copy-paste configs that actually work
nginx performance tuning tips

Troubleshoot now →

No more nginx frustration! ✨

Deploy a Next.js App on AWS EC2 with Docker, NGINX, and Automate with GitHub Actions.

Mon, 29 Sep 2025 12:54:42 +0000

Next.js is a powerful React framework that provides server-side rendering, static site generation, and API routes. Deploying a Next.js app on an AWS EC2 instance allows for better control and customization of the hosting environment. This guide will walk you through the process of setting up a Next.js application on AWS EC2 using Docker and NGINX while automating deployment with GitHub Actions.

Before following this Next.js tutorial, we recommend that you first consult Build and Deploy a ReactJS App to AWS EC2 with Docker, NGINX, and Automate with GitHub Actions. This guide is a continuation of the series on React deployment, focusing solely on Next.js-specific updates. The basic steps remain the same, and you can refer to the previous article for more details.

Table of Contents

Setting Up the Project
Dockerizing the NextJS application
Setting up NGINX
Automating deployment with GitHub Actions on AWS EC2

Note that you can find the link of final source code in the
https://github.com/kilamaelie/Deploy-a-Next.js-App-on-AWS-EC2-with-Docker-NGINX-and-Automate-with-GitHub-Actions
repository.

Step 1. Setting Up the Project
Open your terminal and navigate to the directory where you want to create the project, for the purpose of this tutorial we’ll create a directory with a name next-tutorial-app or you can name it anything depending on your project name. This folder is considered as the root directory for our application which contains all folders and files structures.

Then, we will change our directory into the next-tutorial-app folder and all other parts of configuration files or folders will be in this folder.

> mkdir next-tutorial-app
> cd next-tutorial-app

Inside the next-tutorial-app folder, to create a new Next project runs the following command using create-next-app@latest

npx create-next-app@latest # website is our app-name or folder name

Let’s change the directory into website as our app-name for NextJs application and start development server.

cd website # app-name
npm run dev # start the development server

Step 2: Dockerizing the Next.js App

Create a Dockerfile in the root directory of your website folder:

FROM node:23.10.0-alpine

WORKDIR /app

COPY ./package*.json ./

# Install dependencies
RUN yarn

# Copy all files
COPY . .

# Expose the listening port
EXPOSE 3000

Then, create a .dockerignore file to exclude unnecessary files:

node_modules
.next
.DS_Store
dist

In your project’s root directory as next-tutorial-app, create a file named docker-compose.yml. This file will contain the configuration for your multi-container application.

services:
  website:
    build:
      context: ./website
      dockerfile: Dockerfile
    command: yarn dev
    ports:
      - "3000:3000"

So to test it, just go in your terminal, navigate to the directory containing the docker-compose.yml file and run:

docker-compose up

Kill the task in the terminal where docker-compose up is running in order to stop the. To remove the containers and their associated resources, run:

docker-compose rm -v

Step 3: Setting Up NGINX as a Reverse Proxy in Docker

In the root of your project directory, create a Nginx directory named nginx then create a configuration file named nginx.conf . So inside nginx.conf file adds the following configuration:

server {
     listen 80;
     server_name localhost; 
     #server_name can add your domain or Ip address for your server in the production
 
    location / {
        proxy_pass http://website:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
     }
 }

in the same directory as your Nginx, create a Dockerfile which defines how to build a custom Nginx Docker Image:

# Use an official Nginx image as the base image
FROM nginx:latest

# Remove any existing config files
RUN rm /etc/nginx/conf.d/*
# Copy the custom Nginx configuration
COPY nginx.conf /etc/nginx/conf.d/
# Expose port 80 for Nginx
EXPOSE 80

Before testing in development, let’s update our docker-compose file by adding the Nginx service

services:
  website:
    build:
      context: ./website
      dockerfile: Dockerfile
    ports:
    - 3000:3000
    
  nginx:
    build:
     context: ./nginx
     dockerfile: Dockerfile
    ports:
      - "80:80"
    depends_on:
      - website

Also update the Dockerfile for the next app in the website directory

# Stage 1: Install Dependencies
ARG NODE=node:20-alpine 
FROM ${NODE} AS deps

RUN apk add --no-cache libc6-compat

WORKDIR /app

COPY package*.json ./
RUN npm install

# Stage 2: Build
FROM ${NODE} AS builder

WORKDIR /app

COPY --from=deps /app/node_modules ./node_modules
COPY . .

RUN npm run build

# Stage 3: Production Runner
FROM ${NODE} AS runner

WORKDIR /app

ENV NODE_ENV production
ENV PORT 3000
ENV NEXT_TELEMETRY_DISABLED 1

# Install PM2 globally
RUN npm install -g pm2

# Create a non-root user
RUN addgroup --system --gid 1001 nodegroup
RUN adduser --system --uid 1001 appuser

# Copy necessary files
COPY --from=builder /app/public ./public
COPY --from=builder /app/package.json ./package.json
COPY --from=builder --chown=appuser:nodegroup /app/.next/standalone ./
COPY --from=builder --chown=appuser:nodegroup /app/.next/static ./.next/static

USER appuser

EXPOSE 3000

# Start the application using PM2
CMD ["pm2-runtime", "node", "--", "server.js"]

Before testing, ensure that output: 'standalone' is set in the next.config.js file to optimize the build for Docker deployment.

To test if everything works, open a terminal, navigate to your root directory, and run the following command:

docker-compose up  #

Then let’s testing at http://localhost:80 or http://127.0.0.1:80

Kill the task in the terminal

docker-compose rm -v

Then, let’s create docker-compose.ci and docker-compose.prod files for the production and workflow purpose in the root directory of the project

Docker-compose.ci

services:
  website:
    container_name: website
    build:
      context: ./website
      dockerfile: Dockerfile
      cache_from:
        - '${NEXT_APP_WEBSITE_IMAGE}'
    image: '${NEXT_APP_WEBSITE_IMAGE}'
    env_file:
      - ./.env
    ports:
      - '3000:3000'

  nginx:
    container_name: nginx
    build:
      context: ./nginx
      dockerfile: Dockerfile
      cache_from:
        - '${NEXT_APP_NGINX_IMAGE}'
    image: '${NEXT_APP_NGINX_IMAGE}'
    ports:
      - '80:80'
    restart: always
    depends_on:
      - website

Docker-compose.prod

services:
  website:
    container_name: website
    image: '${NEXT_APP_WEBSITE_IMAGE}'
    env_file: .env
    ports:
      - '3000:3000'

  nginx:
    container_name: nginx
    image: '${NEXT_APP_NGINX_IMAGE}'
    ports:
      - '80:80'
    depends_on:
      - website
    restart: always

So for this tutorial will use Github packages for hosting the images.

Step 4: Automating Deployment with GitHub Actions

Create a GitHub Actions workflow file at .github/workflows/deploy.yml in the root of the project.

name: Continuous Integration and Delivery

on: 
  push:
    branches: [main]
env:
  NEXT_APP_WEBSITE_IMAGE: ghcr.io/$(echo $GITHUB_REPOSITORY | tr '[:upper:]' '[:lower:]')/website
  NEXT_APP_NGINX_IMAGE: ghcr.io/$(echo $GITHUB_REPOSITORY | tr '[:upper:]' '[:lower:]')/nginx
  REGISTRY: ghcr.io
jobs:
  build:
    name: Build Docker Images
    runs-on: ubuntu-latest
    steps:
      - name: Checkout main
        uses: actions/checkout@v3

      - name: Set environment variables
        run: |
          echo "NEXT_APP_WEBSITE_IMAGE=$(echo ${{env.NEXT_APP_WEBSITE_IMAGE}} )" >> $GITHUB_ENV
          echo "NEXT_APP_NGINX_IMAGE=$(echo ${{env.NEXT_APP_NGINX_IMAGE}} )" >> $GITHUB_ENV
      - name: Log in to GitHub Packages
        env:
          PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        run: echo ${PERSONAL_ACCESS_TOKEN} | docker login ghcr.io -u ${{ secrets.NAMESPACE }} --password-stdin

      - name: Build images
        run: |
          docker compose -f docker-compose.ci.yml build
      - name: Push images
        run: |
          docker push ${{ env.NEXT_APP_WEBSITE_IMAGE }}
          docker push ${{ env.NEXT_APP_NGINX_IMAGE }}
  deploy:
    name: Deploy to AWS EC2
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Checkout main
        uses: actions/checkout@v3
      - name: Add environment variables to .env
        run: |
          echo NEXT_APP_WEBSITE_IMAGE=${{ env.NEXT_APP_WEBSITE_IMAGE }} >> .env
          echo NEXT_APP_NGINX_IMAGE=${{ env.NEXT_APP_NGINX_IMAGE }} >> .env
          echo NAMESPACE=${{ secrets.NAMESPACE }} >> .env
          echo PERSONAL_ACCESS_TOKEN=${{ secrets.PERSONAL_ACCESS_TOKEN }} >> .env
      - name: Add the private SSH key to the ssh-agent
        env:
          SSH_AUTH_SOCK: /tmp/ssh_agent.sock
        run: |
          mkdir -p ~/.ssh
          ssh-agent -a $SSH_AUTH_SOCK > /dev/null
          ssh-keyscan github.com >> ~/.ssh/known_hosts
          ssh-add - <<< "${{ secrets.PRIVATE_KEY }}"
      - name: Deploy images on AWS EC2
      
        env:
          SSH_AUTH_SOCK: /tmp/ssh_agent.sock

        run: |
          scp -o StrictHostKeyChecking=no -r ./.env ./docker-compose.prod.yml ${{secrets.AWS_HOST_USER}}@${{ secrets.AWS_EC2_IP_ADDRESS }}:
          ssh -o StrictHostKeyChecking=no ${{secrets.AWS_HOST_USER}}@${{ secrets.AWS_EC2_IP_ADDRESS }} << EOF
              docker-compose down --rmi all -v
              docker login ghcr.io -u ${{secrets.NAMESPACE}} -p ${{secrets.PERSONAL_ACCESS_TOKEN}}
              docker pull $WEBSITE_IMAGE
              docker pull $NGINX_IMAGE 
              docker-compose --env-file=.env -f docker-compose.prod.yml up -d
              docker logout
          EOF

Please make sure your on main branch because the workflow’s can only trigger on the main branch other you can it to your preferences.

Workflow successfully finished :

By following these steps, you have successfully deployed a Next.js application on AWS EC2 using Docker and NGINX, with automated deployments using GitHub Actions. You can further enhance this setup by integrating SSL certificates with Let’s Encrypt and using AWS services like RDS or S3 for storage.

If you would like to improve your skills, click on the following link on Master React App Deployment: AWS EC2, Route 53, SSL & GitHub Actions,A comprehensive manual which walks you through the deployment process, leveraging the power of Docker, AWS EC2, Route 53, SSL encryption and GitHub actions to build a robust CI/CD pipeline.

Keep exploring, stay curious and keep building on this foundation to create even more sophisticated and powerful projects. Happy coding!

Thanks for reading through and I hope you liked what you read here. Feel free to connect with me on portfolio,LinkedIn, twitter and GitHub.

Deploy a ReactJS App to AWS EC2 with Docker, NGINX, and Automate with GitHub Actions part One

Wed, 25 Jun 2025 17:01:32 +0000

In today’s digital landscape, master the art of building, deploying and automating ReactJS Apps using Docker, NGINX and GitHub actions on AWS EC2. Dive into this comprehensive guide and transform your coding journey into an adventure of innovation, efficiency and cutting-edge technologies.

Table of Contents

Prerequisites
Setting Up the Project
Dockerizing the ReactJS application
Setting up NGINX
Automating deployment with GitHub Actions on AWS EC2

1. Prerequisites
Before diving into this project, which involves several technologies and concepts, you need a solid grounding in the following areas to ensure successful learning and implementation such as:

Basic Web development: A good understanding of HTML, CSS and
JavaScript is essential, as ReactJS is a JavaScript library for
building user interfaces.
Git and version control: A good knowledge of Git and version control
concepts will help you manage your code base and collaborate
effectively.
Docker: Understanding containerization for docker is crucial to
packaging your application and its dependencies in isolated
containers
NGINX: A basic knowledge of NGINX as a web server and reverse proxy
will be necessary to set up the server environment.

Remember, while these requirements are essentials, you don’t need to be an expert in every area. You can learn and develop your expertise as you go along. What’s more, official documentation, online tutorials and communities can provide invaluable support as you learn.

Note that you can find the link of final source code in the build and deploy-reactApp to-aws ec2 via github-actions repository.

2. Setting Up the Project

This involves several steps which including the installation, project structure and other basic configuration, here’s a step-by-step guide helping you get started :

Install Node.js and npm:
Before you begin, make sure Node.js and npm ( Node Package Managers) are installed on your system. You can download them from the official website: https://nodejs.org.

Create a New Project:
Open your terminal and navigate to the directory where you want to create the project, for the purpose of this tutorial we’ll create a directory with a name react-tutorial-app or you can name it anything depending on your project name. This folder is considered as the root directory for our application which contains all folders and files structures.

In software development, “project structure” provides a clear and
logical layout that helps developers understand and navigate the
codebase more easily. A well-designed project structure promotes
maintainability, collaboration, and efficient development.

Then, we will change our directory into the react-tutorial-app folder and all other parts of configuration files or folders will be in this folder.

mkdir react-tutorial-app
cd react-tutorial-app

Inside the react-tutorial-app folder, to create a new React project runs the following command using create-react-app and for more details on how create-react-app works and other staff, please visit the official website: [https://create-react-app.dev/][3]

npx create-react-app your-app-name # website is our app-name or folder name

create-react-app is a command-line tool that allows you to quickly and easily set up a new Reactjs Application, this boilerplate setup generates a basic project structure, including essential files and configuration needed to start building a React application.

Let’s change the directory into website as our app-name for React application.

cd website # app-name

To start the development server and preview your React app, use the following command:

npm start

This command will initiate the development server, which will compile your React code, bundle assets, and start a local web server to serve
your application. It will also open your app in your default web
browser automatically.

Once the development server is up and running, you can access your React app by visiting http://localhost:3000 in your web browser. So well done ???? for creating a React application and setting up the project.

3. Dockerizing the ReactJS application

Docker provides a standardized way to package and distribute applications, making it easier to deploy and manage across different environments. In this section, we’ll containerize our ReactJS application using Docker.

If you haven’t already, install Docker on your machine by following the instructions for your operating system:
https://docs.docker.com/get-docker/

In your React app’s root directory, create a file named Dockerfile. This file defines the instructions to build your Docker image.

# Use an official Node.js runtime as the base image

FROM node:19.6.0-alpine
# Set the working directory within the container
WORKDIR /website

# Copy package.json and package-lock.json to the container
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the rest of the application code to the container
COPY . .

# Build the React app
EXPOSE 3000

Since in this project will have more than one container , then we ‘ll need to use docker-compose

Docker-compose : allows you to define and run multiple Docker containers as a single service, making it easier to manage complex applications.

If you haven’t already, you’ll need to install Docker Compose. Follow the installation instructions for your operating system:
[https://docs.docker.com/compose/install/][4]

In your project’s root directory as react-tutorial-app, create a file named docker-compose.yml. This file will contain the configuration for your multi-container application.

services:
  website:
    build:
      context: ./website
      dockerfile: Dockerfile
    command: npm start
    ports:
      - "3000:3000"

This defines only one service website but a bit later more will be added. So in order to test it, just go in your terminal, navigate to the directory containing the docker-compose.yml file and run:

docker-compose up

Docker Compose will build the required images and start the defined containers. You’ll see logs from both services in the terminal and also depending on your configuration, you can access your ReactJS app at http://localhost:3000 . Kill the task in the terminal where docker-compose up is running in order to stop the. To remove the containers and their associated resources, run:

docker-compose rm -v

4. Setting up NGINX

NGINX is a reverse proxy to serve the built static files of your React application. This setup is commonly used to improve performance and manage routing in production environments.

In the root of your project directory, create a Nginx directory named nginx then create a configuration file named nginx.conf . So inside nginx.conf file adds the following configuration:

server {
     listen 80;
     server_name localhost; 
     #server_name can add your domain or Ip address for your server in the production
 
     location / {
         root /usr/share/nginx/html/website;
         try_files $uri $uri/ /index.html;
     }
 }

in the same directory as your Nginx, create a Dockerfile which defines how to build a custom Nginx Docker Image:

# Use an official Nginx image as the base image
FROM nginx:latest

# Remove any existing config files
RUN rm /etc/nginx/conf.d/*

# Copy the custom Nginx configuration
COPY nginx.conf /etc/nginx/conf.d/

# Expose port 80 for Nginx
EXPOSE 80

Before testing in development, let’s update our docker-compose file by adding the Nginx service

services:
website:
  build:
    context: ./website
    dockerfile: Dockerfile
  volumes:
   - website:/website/build/  # build files will be added at this directory !!!

nginx:
  build:
   context: ./nginx
   dockerfile: Dockerfile
  ports:
    - "80:80"
  volumes:
     - website:/usr/share/nginx/html/website # Copy React App's build files to the Nginx directory

volumes:
   website:

And also update the Dockerfile for the react app in the website directory

# Use an official Node.js runtime as the base image

FROM node:19.6.0-alpine
# Set the working directory within the container
WORKDIR /website

# Copy package.json and package-lock.json to the container
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy the rest of the application code to the container
COPY . .

# Build the React app
RUN npm run build

# Build the React app
EXPOSE 3000

For the purpose of testing if everything works, we’ll open a terminal and navigate to your root directory. Run the following command:

docker-compose up  #

Then let’s testing at http://localhost:80 or http://127.0.0.1:80

Kill the task in the terminal where the container is running. To remove the container and its associated resources, run:

docker-compose rm -v

Then, let’s create docker-compose.ci and docker-compose.prod files for the production and workflow purpose in the root directory of the project

Docker-compose.ci

services:
  website:
    build:
      context: ./website
      dockerfile: Dockerfile
    cache_from:
        - '${WEBSITE_IMAGE}'
    image: '${WEBSITE_IMAGE}'
    ports:
      - "3000:3000"
    volumes:
      - website:./website/build/  # build files will be added at this directory !!!

  nginx:
    build:
     context: ./nginx
     dockerfile: Dockerfile
    cache_from:
        - '${NGINX_IMAGE}'
    image: '${NGINX_IMAGE}'
    ports:
      - "80:80"
    volumes:
      - website:/usr/share/nginx/html/website # Copy React App's build files to the Nginx directory

Docker-compose.prod

services:
  website:
    container_name: 'website'
    image: '${WEBSITE_IMAGE}'
    ports:
      - "3000:3000"
    volumes:
      - website:./website/build/  # build files will be added at this directory !!!
  
  nginx:
    container_name: 'nginx'
    image: '${NGINX_IMAGE}'
    ports:
      - "80:80"
    volumes:
      - website:/usr/share/nginx/html/website # Copy React App's build files to the Nginx directory

volumes:
  website:

So for this tutorial will use Github packages for hosting the images.

[GitHub Package Registry][5] is a package hosting service provided by GitHub. It allows you to publish, share, and manage software packages directly within your GitHub repositories.

It lets you host your software, either publicly or privately, for use in your projects on GitHub.

Click on the link for the part two

Deploy a ReactJS App to AWS EC2 with Docker, NGINX, and Automate with GitHub Actions part two

Wed, 25 Jun 2025 17:01:06 +0000

AWS Setup

Let’s start by setting up an EC2 instance to deploy our application. To do this, and you’ll need to open an AWS account (if you don’t already have one).

If you don’t know how to set up AWS EC2 , please visit this link which
will guide you through how to : launch EC2

Once we’ve finished configuring AWS EC2 and the instance is up and running, we can install Docker on it.

So connect via SSH into the instance using your Key Pair as :

$ ssh -i your-key-pair.pem ec2-user@<PUBLIC-IP-ADDRESS>

#example 
# ssh -i ~./ssh/react-tutorial.perm ec2-user@54.201.189.94

After accessing the instance, start by updating the server package and installing the latest version of Docker and Docker-compose:

[ec2-user]$ sudo yum update -y
[ec2-user]$ sudo yum install -y docker
[ec2-user]$ sudo service docker start
[ec2-user]$ sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
[ec2-user]$ sudo chmod +x /usr/local/bin/docker-compose

[ec2-user]$ docker --version
Docker version 20.10.23, build 7155243

[ec2-user]$ docker-compose --version
Docker Compose version v2.18.1

Add the ec2-user to the docker group so that you can use it without running the Docker command with sudo :

[ec2-user]$ sudo usermod -a -G docker ec2-user

Next, let’s generate the SSH KEY

[ec2-user]$ ssh-keygen -t rsa

Please! save the Key without setting any password

Next, copy the public key into the authorized_keys file and set the appropriate authorizations.:

[ec2-user]$ cat ~/.ssh/id_rsa.pub 
# Copy this public key into ~/.ssh/authorized_keys
[ec2-user]$ vi ~/.ssh/authorized_keys
# After adding the public key into authorized_key then exits  from vi text editor 
# Then add these commands are used to change the permissions of these files 
[ec2-user]$ chmod 600 ~/.ssh/authorized_keys
[ec2-user]$ chmod 600 ~/.ssh/id_rsa

Now, copy the contents of the private key

[ec2-user]$ cat ~/.ssh/id_rsa

# Copy the private key somewhere for later use

5. Automating Deployment with GitHub Actions to AWS EC2

It is an integrated continuous integration and continuous deployment (CI / CD) platform provided by GitHub .

Since our workflow will use GitHub’s core features (GitHub packages), GitHub requires you to create an access token, which will be used as a GitHub user ID for all your interactions.

Go to the Personal access tokens area in the Developer settings of your GitHub profile and click Generate new token.

To configure GitHub Actions, start by adding a new directory called .github to the root of your project, then within this directory, add another directory called workflows.
Now to configure the workflow, which is a set of one or more jobs, create a new file in the workflows directory called main.yml .
You can also run the following command in your root directory.

mkdir .github && cd .github
mkdir workflows && cd workflows
touch main.yml

main.yml

name: Continuous Integration and Delivery

on:
  push:
    branches: [main]

env:
  #
  WEBSITE_IMAGE: ghcr.io/$(echo $GITHUB_REPOSITORY | tr '[:upper:]' '[:lower:]')/website
  NGINX_IMAGE: ghcr.io/$(echo $GITHUB_REPOSITORY | tr '[:upper:]' '[:lower:]')/nginx
  REGISTRY: ghcr.io

jobs:
  build:
    name: Build the Docker Image
    runs-on: ubuntu-latest

    steps:
      - name: checkout main
        uses: actions/checkout@v3

      - name: Set environment variables to .env
        run: |
          echo "WEBSITE_IMAGE=$(echo ${{env.WEBSITE_IMAGE}} )" >> $GITHUB_ENV
          echo "NGINX_IMAGE=$(echo ${{env.NGINX_IMAGE}} )" >> $GITHUB_ENV
      - name: Log in to GitHub Packages
        env:
          PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        run: echo ${PERSONAL_ACCESS_TOKEN} | docker login ghcr.io -u ${{ secrets.NAMESPACE }} --password-stdin

      - name: Pull images
        run: |
          docker pull ${{ env.WEBSITE_IMAGE }} || true
          docker pull ${{ env.NGINX_IMAGE }} || true
      - name: Build images
        run: |
          docker compose -f docker-compose.ci.yml build
      - name: Push images
        run: |
          docker push ${{ env.WEBSITE_IMAGE }}
          docker push ${{ env.NGINX_IMAGE }}
  checking-secrets:
    name: Checking secrets
    runs-on: ubuntu-latest
    needs: build
    outputs:
      secret_key_exists: ${{steps.check_secrets.outputs.defined}}
    steps:
      - name: Check for Secrets availabilities
        id: check_secrets
        shell: bash
        run: |
          if [[ -n "${{ secrets.PRIVATE_KEY }}" && -n "${{secrets.AWS_EC2_IP_ADDRESS}}" && -n "${{secrets.AWS_HOST_USER}}" ]]; then
            echo "defined=true" >> $GITHUB_OUTPUT;
          else
            echo "defined=false" >> $GITHUB_OUTPUT;
          fi
  deploy:
    name: Deploy to AWS EC2
    runs-on: ubuntu-latest
    needs: checking-secrets
    if: needs.checking-secrets.outputs.secret_key_exists == 'true'
    steps:
      - name: Checkout main
        uses: actions/checkout@v3

      - name: Add environment variables to .env
        run: |
          echo WEBSITE_IMAGE=${{ env.WEBSITE_IMAGE }} >> .env
          echo NGINX_IMAGE=${{ env.NGINX_IMAGE }} >> .env
          echo NAMESPACE=${{ secrets.NAMESPACE }} >> .env
          echo PERSONAL_ACCESS_TOKEN=${{ secrets.PERSONAL_ACCESS_TOKEN }} >> .env
      - name: Add the private SSH key to the ssh-agent
        env:
          SSH_AUTH_SOCK: /tmp/ssh_agent.sock
        run: |
          mkdir -p ~/.ssh
          ssh-agent -a $SSH_AUTH_SOCK > /dev/null
          ssh-keyscan github.com >> ~/.ssh/known_hosts
          ssh-add - <<< "${{ secrets.PRIVATE_KEY }}"
      - name: Deploy images on AWS EC2
        env:
          SSH_AUTH_SOCK: /tmp/ssh_agent.sock

        run: |
          scp -o StrictHostKeyChecking=no -r ./.env ./docker-compose.prod.yml ${{secrets.AWS_HOST_USER}}@${{ secrets.AWS_EC2_IP_ADDRESS }}:
          ssh -o StrictHostKeyChecking=no ${{secrets.AWS_HOST_USER}}@${{ secrets.AWS_EC2_IP_ADDRESS }} << EOF
              docker-compose down --rmi all -v 
              docker login ghcr.io -u ${{secrets.NAMESPACE}} -p ${{secrets.PERSONAL_ACCESS_TOKEN}}
              docker pull $WEBSITE_IMAGE
              docker pull $NGINX_IMAGE 
              docker-compose --env-file=.env -f docker-compose.prod.yml up -d
              docker logout
          EOF

Find the complete gist.

So, in the main.yml we define :

set the environment variables
Three jobs to run:
a. build job consist of:

Set various environment variables
Login in the Github package by using the PERSONAL_ACCESS_TOKEN created
Pull images for caching, build the images and push to Github Registry

b. checking-secret consist of :

checking if the deploy variables are existing

Notes about the secrets

secrets.PERSONAL_ACCESS_TOKEN
secrets.NAMESPACE
secrets.PRIVATE_KEY
secret.AWS_EC2_IP_ADDRESS
secrets.AWS_HOST_USER

All of the secrets need to be set in your repository’s secrets (Settings > Secrets) and use your Github username or your organization name as your NAMESPACE and your personal access token as PERSONAL_ACCESS_TOKEN .

c. deploy job consist of:

Add the environment variable to .env file which will be created on the AWS EC2 instance.
Add the private key to ssh-agent for password less.
Deploy the build the images on AWS EC2 instance.

Once you are done, commit and push your code to the Github to trigger the workflow to run, so now you should see the images in the Github Packages.

Please make sure your on main branch because the workflow’s can only trigger on the main branch other you can it to your preferences.

Workflow successfully finished :

Once all our jobs have been executed, navigate to the IP of your instance, and you should see the React application running :

And there you have it, this guide has equipped you with the skills you need to successfully build, deploy and automate ReactJS applications using Docker, NGINX and GitHub Actions on AWS EC2.

Keep exploring, stay curious and keep building on this foundation to create even more sophisticated and powerful projects. Happy coding!

Thanks for reading through and I hope you liked what you read here. Feel free to connect with me on LinkedIn, twitter and GitHub

Securing Your VPS: Basic Firewall, SSH, and SSL Setup Guide

Sat, 07 Jun 2025 17:01:23 +0000

A Simple Guide to Make Your VPS Safer — Even If You're Just Starting Out

Your VPS (Virtual Private Server) is like your home on the internet — and just like a home, it needs locks, fences, and security cameras to stay safe. This guide will walk you through three critical steps to secure your VPS:

Set up a basic firewall
Secure -SSH access
Install SSL for HTTPS

Step 1: Set Up a Basic Firewall with UFW (Uncomplicated Firewall)

A firewall controls what kind of traffic can reach your VPS. Let’s use UFW, a beginner-friendly firewall for Ubuntu/Debian systems.

✅ Install UFW

sudo apt update
sudo apt install ufw

✅ Allow SSH (so you don’t lock yourself out)

sudo ufw allow OpenSSH

If you're using a non-standard SSH port (e.g., 2222), allow that too:

sudo ufw allow 2222/tcp

✅ Allow HTTP and HTTPS

sudo ufw allow 80
sudo ufw allow 443

✅ Enable the Firewall

sudo ufw enable

To check status:

sudo ufw status

Pro Tip: Only open ports that your app or server needs!

Step 2: Secure SSH Access

SSH is how you remotely access your server. But by default, it’s a bit too open.

✅ Change the Default SSH Port (optional but adds extra protection)

Edit the SSH config file:

sudo nano /etc/ssh/sshd_config

Find and change:

Port 22

To something like:

Port 2222

Then restart SSH:

sudo systemctl restart ssh

Still in /etc/ssh/sshd_config, find:

PermitRootLogin yes

Change to:

PermitRootLogin no

Restart SSH again:

sudo systemctl restart ssh

✅ Use SSH Keys Instead of Passwords

From your local machine, run:

ssh-keygen -t rsa -b 4096

Then copy the key to your VPS:

ssh-copy-id username@your-server-ip

Disable password authentication (optional but recommended):

sudo nano /etc/ssh/sshd_config

Set:

PasswordAuthentication no

Restart SSH:

sudo systemctl restart ssh

Step 3: Install Free SSL Using Let’s Encrypt (with Certbot)

SSL (HTTPS) encrypts your website traffic. Let’s Encrypt makes it easy and free.

✅ Install Certbot

For Nginx:

sudo apt install certbot python3-certbot-nginx

For Apache:

sudo apt install certbot python3-certbot-apache

✅ Issue an SSL Certificate

sudo certbot --nginx

Or for Apache:

sudo certbot --apache

Follow the prompt and choose to redirect HTTP to HTTPS.

✅ Auto-Renew SSL

Let’s Encrypt certificates expire every 90 days. Set up auto-renewal:

sudo systemctl list-timers

Certbot typically installs a timer, but you can test renewal with:

sudo certbot renew --dry-run

Final Thoughts

Security doesn't have to be scary.

With just a few commands, you've:

✅ Protected your SSH login
✅ Closed unnecessary network doors
✅ Encrypted web traffic with HTTPS

These are must-do steps for anyone hosting websites, APIs, or apps on a VPS — even beginners.

Bonus Tools for Extra Security (Optional)

Fail2Ban: Automatically blocks brute-force attempts
ModSecurity: Web application firewall
Auditd: For logging and monitoring server changes

Resources

Nginx Configuration Tips for Secure Communication: Enabling mTLS and checking client fingerprint

Fri, 21 Feb 2025 20:38:01 +0000

This paper is intended for beginners looking to enhance web security by configuring mutual Transport Layer Security (mTLS) in Nginx and verifying the client’s certificate fingerprint or securing specific URLs with mTLS. The paper provides a comprehensive guide on how to implement these security measures in Nginx, offering step-by-step instructions and practical advice. The resulting Nginx configuration is available at https://github.com/stjam/mtls_demo/blob/master/nginx.conf. By following this guide, readers can improve the security of their web applications and prevent unauthorized access to sensitive data.

A demo project has been prepared and is available at https://github.com/stjam/mtls_demo/tree/master. The project is a simple web application with two endpoints: /api/private, which echoes the headers of requests, and /api/public, which returns the current time. All traffic is routed through Nginx, which proxies requests to the backend.

I have used the following software versions to prepare this tutorial:

Maven 3.8.7
Docker Desktop 4.16.1
Java 19
LibreSSL 3.3.6
To build backend you can use the next set of commands

./mvnw package -Pnative -Dquarkus.native.container-build=true

docker build -f src/main/docker/Dockerfile.native -t quarkus/mtls_demo

To run everything, you need to use docker-compose, which I have included here: https://github.com/stjam/mtls_demo/blob/master/docker-compose.yaml

Now, let’s make access to our backend more secure. Initially, we have the following nginx.conf file, which simply proxies requests to our backend service.

events {
    worker_connections 100;
    multi_accept on;
}

http {
    server {
      listen 80;
      location / {
          proxy_pass http://quarkus:8080;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          }
      }
  }

And our private API is not secure, as we can directly call it.

I recommend changing the content of https://github.com/stjam/mtls_demo/blob/master/nginx.conf with every snippet of configuration that I’ve put here, as it will make understanding the key steps of this tutorial better.

First of all, we need to create a server certificate and enable SSL in Nginx. You can skip certificate generation and use the certificate set I’ve put in the Github repo.

To generate a server certificate, use the following command. You can read more about the parameters of this command in https://medium.com/@stjamlb/openssl-made-easy-a-practical-guide-to-generating-and-signing-x-509-certificates-da85e8f2db3e.

openssl req -newkey rsa:2048 -nodes -keyout server.key -x509 -days 365 -out server.crt

For convince you can combine key and server certificate in one file

cat server.key server.crt > server.pem

Modified nginx.conf:

events {
    worker_connections 100;
    multi_accept on;
}

http {
    server {
      listen 443 ssl;
      ssl_certificate /etc/nginx/server.pem;
      ssl_certificate_key /etc/nginx/server.pem;

      location / {
          proxy_pass http://quarkus:8080;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          }
      }
  }

Now we listen on port 443, and our clients should use HTTPS to call our service. We’ve also added paths to our server certificate and key. If we call without HTTPS, we get the following error:

After modifying our request to call via HTTPS, we get a successful response.

When configuring an HTTPS connection, it’s important to verify the connection between the client and server. This can be done using the following command:

openssl s_client -connect 127.0.0.1:443

This command will connect to the server on port 443 and print out detailed information about the SSL/TLS handshake process, including the server’s certificate details, the supported cipher suites, and the SSL/TLS session parameters:

Now that the traffic between our client and server is encrypted, clients can verify the server certificate. However, in some cases, a TLS connection alone may not be sufficient. If you need to verify the client’s certificate on the server side, you should configure mutual TLS (mTLS)

events {
    worker_connections 100;
    multi_accept on;
}

http {
    server {
      listen 443 ssl;
      ssl_certificate /etc/nginx/server.pem;
      ssl_certificate_key /etc/nginx/server.pem;
      ssl_client_certificate /etc/nginx/server.crt;
      ssl_verify_client on;

      location / {
          proxy_pass http://quarkus:8080;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          }
      }
  }

We have added the option ‘ssl_verify_client on;’ and the path to the client certificate ‘ssl_client_certificate’ in our Nginx configuration. This means that Nginx will now require a client certificate for a connection. However, we encountered an error when trying to establish a connection using OpenSSL. Let’s fix this.

we need client certificate. I should notice that both the client and server need to have certificates that are signed by the same Certificate Authority (CA). This ensures that both parties can trust each other’s identity during the SSL/TLS handshake. Without this trust relationship, the client and server will not be able to establish a secure connection.

1. openssl req -new -newkey rsa:2048 -nodes -keyout client.key -out client.csr 
 
2. openssl x509 -req -days 365 -in client.csr -CA server.crt -CAkey server.key -CAcreateserial -out client.crt

The first command generates a certificate signing request (CSR) for the client certificate, and the second command signs the CSR with the CA key to generate the client certificate. After executing these commands, you will have a client.crt file containing the client certificate.

Now we can check the OpenSSL connection.

openssl s_client -connect 127.0.0.1:443 -key client.key -cert client.crt -CAfile server.crt

After execution you should see something like this:

And now, in order to call our private API, we must provide the -cert and -key options with the path to the client.key and client certificate.

curl --cert client.crt --key client.key https://127.0.0.1:443/api/private --insecure

Everything is working as expected, but we need to remember that we have a public endpoint that doesn’t require client certificate verification. Let’s configure Nginx to only check the certificate for the /api/private endpoint. We just need to add a new location and make ssl_verify_client optional. We also add an if condition to check if the ssl_connection was successful or not. If it was not successful, we return a 403 error. Otherwise, we proxy the request to our backend.

events {
    worker_connections 100;
    multi_accept on;
}

http {
    server {
      listen 443 ssl;
      ssl_certificate /etc/nginx/server.pem;
      ssl_certificate_key /etc/nginx/server.pem;
      ssl_verify_client optional;
      ssl_client_certificate /etc/nginx/server.crt;

      location / {
          proxy_pass http://quarkus:8080;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          }

      location /api/private {
                if ($ssl_client_verify != SUCCESS) {
                    return 403;
                }
                proxy_pass http://quarkus:8080;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
        }
      }
  }

Now we only need to provide a certificate with our request if we are accessing the /api/private endpoint, as the /api/public endpoint is available directly without any additional security measures. In this case, we have two options: we can either check the client certificate fingerprint or the client CN. To find the fingerprint using openssl, we can use the following command:

openssl x509 -noout -fingerprint -sha1 -inform pem -in client.crt

After adding the fingerprint check to our configuration, our updated nginx configuration looks like this:

events {
    worker_connections 100;
    multi_accept on;
}

http {
    server {
      listen 443 ssl;
      ssl_certificate /etc/nginx/server.pem;
      ssl_certificate_key /etc/nginx/server.pem;
      ssl_verify_client optional;
      ssl_client_certificate /etc/nginx/server.crt;

      location / {
          proxy_pass http://quarkus:8080;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          }

      location /api/private {
                if ($ssl_client_verify != SUCCESS) {
                                    return 403;
                            }

                if ($ssl_client_fingerprint != 7dc7ec3379c699dc2dcf8a44e67acae5ae09e06f) {
                        return 403;
                    }



                proxy_pass http://quarkus:8080;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
        }
      }
      log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$ssl_client_fingerprint" "$ssl_client_s_dn"';
      access_log /var/log/nginx/access.log main;

  }

I should note that when checking the fingerprint, you must provide the SHA1 fingerprint without any colons. Additionally, I’ve included an example of how to enrich the information in the Nginx access.log with useful details such as the client certificate fingerprint or client certificate CN.

Conclusion

We have demonstrated the steps required to configure mutual TLS (mTLS) in Nginx, and explained how to verify the connection using OpenSSL.

After that, we worked with a location block in our Nginx configuration to check client certificates only for a specific endpoint (/api/private), and not for the public endpoint (/api/public).

Finally, we have discussed how to enrich the information in the Nginx access log with useful details such as client certificate fingerprints or CN. By following these steps, we can ensure that our communication is secure and only authorized parties can access our API endpoints. This dialog provides a comprehensive guide to configuring mTLS in Nginx for secure communication between the client and server.