Setting Up Nginx and SSL: Making Your Strapi Backend Production-Ready

Series Navigation:

• Part 0: Introduction - Why This Setup?

• Part 1: Containerizing Strapi v5

• Part 2: Deploying to DigitalOcean

• Part 3: Production Web Server Setup (You are here)

• Part 4: Automated Database Backups (Coming next week)

• Part 5: CI/CD Pipeline with GitHub Actions

New to the series? You can jump in here, but I recommend reading Parts 1-2 first since we're building on that foundation.

---

Alright, we've got Strapi running on DigitalOcean, accessible via http://YOUR_DROPLET_IP:1337. That works fine for testing, but let's be real - nobody wants to share an IP address with investors or show it to beta users.

"Hey, check out my app at http://167.99.234.123:1337/admin!" Yeah, not exactly inspiring confidence.

In this article, we're setting up Nginx as a reverse proxy, configuring a proper domain with free SSL certificates, and making your setup look and feel production-ready. We're also diving into logs and troubleshooting - the stuff you actually need when things break at 2 AM.

By the end, you'll access your Strapi backend at https://api.yourdomain.com with a proper SSL certificate. Same $6/month cost, way more professional.

Let's get into it.

---

What We're Building

Here's what this article covers:

• Nginx as a reverse proxy (sitting in front of Strapi)

• Custom domain setup with DNS configuration

• Free SSL certificates from Let's Encrypt

• Automatic HTTP to HTTPS redirects

• Security headers to protect against common attacks

• Complete logging and troubleshooting setup

• Optional port management (closing direct access to Strapi/PostgreSQL)

All of this still runs on your $6/month DigitalOcean droplet. The SSL certificate is free and renews automatically.

---

Prerequisites

Before we start, make sure you have:

• Parts 1-2 completed (Strapi running on DigitalOcean)

• A registered domain name (from Namecheap, GoDaddy, Google Domains, etc.)

• DNS access to add A records

• SSH access to your droplet

• About 45-60 minutes

Don't have a domain yet? You'll need one for this part. Domain names cost $10-15/year from most registrars. If you're just testing and don't want to buy a domain yet, you can skip to Part 4 and come back to this later.

New to DNS records? No worries - we'll walk through the basics. If you need more detail, there are tons of beginner-friendly guides out there. The main focus of this series isn't DNS configuration, so we'll keep it brief and practical.

---

Understanding the Architecture

Before we start configuring things, let's talk about what we're actually building and why.

Current Setup (After Part 2):

Internet → Port 1337 → Strapi Container

Users connect directly to Strapi on port 1337. This works but has problems:

• No SSL encryption (traffic is visible)

• Exposing Strapi directly isn't great security

• Can't easily host multiple services

• No request logging or filtering

New Setup (After Part 3):

Internet → Port 443 (HTTPS) → Nginx → Port 1337 → Strapi Container

Nginx sits in front of Strapi and handles:

• SSL/TLS encryption (HTTPS)

• Domain routing

• Security headers

• Request logging

• Rate limiting (if we add it later)

Why this matters: Nginx is battle-tested reverse proxy software used by huge companies. It's better at handling SSL, logging, and security than letting Strapi face the internet directly.

---

Step 1: Install Nginx

Let's start by installing Nginx on your droplet. We'll need root access for this since we're installing system-level software.

Connect to Your Droplet

ssh root@YOUR_DROPLET_IP

We're connecting as root because we need to install Nginx, configure system files, and manage SSL certificates - all of which require root privileges. We'll switch to the deploy user later when we need to update application files.

Install Nginx

# Update package lists
apt update

# Install Nginx
apt install nginx -y

# Check if it's running
systemctl status nginx

You should see something like:

● nginx.service - A high performance web server
   Active: active (running)

If it says "active (running)", you're golden. Nginx is now running on your server.

Configure Firewall for Web Traffic

Before we can access Nginx from our browser, we need to open the necessary ports:

# Allow HTTP (port 80)
ufw allow 80/tcp

# Allow HTTPS (port 443) - we'll need this soon for SSL
ufw allow 443/tcp

# Verify firewall rules
ufw status

You should now see port 80 and 443 in your firewall rules:

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
1337/tcp                   ALLOW       Anywhere
5432/tcp                   ALLOW       Anywhere

Why we're opening these ports:

• Port 80 (HTTP): Nginx needs this to serve web traffic

• Port 443 (HTTPS): We'll use this for SSL in a few steps

In Part 2, we opened ports 1337 and 5432 for direct Strapi and PostgreSQL access. We'll talk about closing those later once Nginx is handling all web traffic.

Verify Basic Nginx Installation

Now that the firewall is configured, open your browser and visit: http://YOUR_DROPLET_IP

You should see the default Nginx welcome page - "Welcome to nginx!" This confirms Nginx is running and accessible.

If you don't see this page, check your firewall settings from Part 2. Make sure port 80 is allowed.

---

Step 2: Configure DNS (Point Your Domain to the Droplet)

Before we configure Nginx, we need your domain to point to your DigitalOcean droplet. This is done through DNS A records.

What's an A Record?

An A record tells the internet "when someone types api.yourdomain.com, send them to this IP address." Think of it like adding a contact to your phone - you're associating a name with a number.

Adding the A Record

The exact steps depend on your domain registrar, but the concept is the same everywhere:

Generic Steps:

1. Login to your domain registrar (Namecheap, GoDaddy, etc.)

2. Find DNS settings (might be called "DNS Management", "Advanced DNS", or "Name Servers")

3. Add a new A record:

   • Type: A

   • Host/Name: api (or whatever subdomain you want)

   • Value/Points to: Your droplet IP address

   • TTL: 300 (5 minutes) or leave default

Example:

Type: A
Host: api
Value: 167.99.234.123
TTL: 300

This creates api.yourdomain.com pointing to your droplet.

Verify DNS Propagation

DNS changes can take a few minutes to propagate. Test it:

# From your local machine (not the server)
nslookup api.yourdomain.com

# Or use dig
dig api.yourdomain.com +short

If you see your droplet's IP address in the response, DNS is working! If not, wait 5-10 minutes and try again.

New to DNS or need more detailed instructions for your specific registrar? Google "[your registrar name] add A record" - there are tons of step-by-step guides with screenshots for every major registrar.

---

Step 3: Configure Nginx as Reverse Proxy

Now let's configure Nginx to forward requests to our Strapi container.

Create Nginx Configuration File

# Still as root
nano /etc/nginx/sites-available/api.yourdomain.com

Important: Replace api.yourdomain.com with your actual domain throughout this guide.

Paste this configuration:

server {
    listen 80;
    listen [::]:80;
    server_name api.yourdomain.com;

    # Security headers
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header Referrer-Policy "strict-origin-when-cross-origin";

    # Client max body size for file uploads
    client_max_body_size 100M;

    location / {
        proxy_pass http://localhost:1337;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        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 $scheme;
        proxy_cache_bypass $http_upgrade;

        # Timeout settings
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

Save and exit (Ctrl+X, Y, Enter).

Understanding the Configuration

Let's break down what this does:

Server Block:

• listen 80 - Listen on HTTP port 80

• server_name api.yourdomain.com - Respond to requests for this domain

Security Headers: These tell browsers how to handle security:

• X-Frame-Options: DENY - Prevents your site from being embedded in iframes (protects against clickjacking attacks)

• X-Content-Type-Options: nosniff - Prevents browsers from trying to "guess" file types (protects against MIME-type attacks)

• X-XSS-Protection - Enables browser's built-in XSS filter

• Referrer-Policy - Controls what information browsers send when navigating away from your site

Full transparency: Since we're running an API that returns JSON, some of these headers (like X-Frame-Options and X-XSS-Protection) don't provide much protection - they're more relevant for sites serving HTML. But we're keeping them because (a) your Strapi admin panel does serve HTML and benefits from these, (b) they're harmless to include, and (c) they're standard reverse proxy best practices. The one that actually matters for APIs is X-Content-Type-Options - it prevents MIME-type confusion attacks on your JSON responses.

Client Settings:

• client_max_body_size 100M - Allows file uploads up to 100MB

Proxy Settings: These tell Nginx how to forward requests to Strapi:

• proxy_pass http://localhost:1337 - Forward to Strapi container

• proxy_set_header directives - Pass along important information (client IP, protocol, etc.)

• Timeout settings - How long to wait for Strapi to respond

These proxy headers are actually critical for Strapi to work correctly. Without X-Real-IP and X-Forwarded-For, Strapi thinks every request comes from 127.0.0.1 (localhost). Without X-Forwarded-Proto, Strapi doesn't know the request came via HTTPS, which breaks redirects and webhooks. Don't skip these.

Enable the Configuration

# Create symbolic link to enable the site
ln -s /etc/nginx/sites-available/api.yourdomain.com /etc/nginx/sites-enabled/

# Test configuration for syntax errors
nginx -t

You should see:

nginx: configuration file /etc/nginx/nginx.conf test is successful

If you see errors, double-check your configuration file for typos.

Restart Nginx

systemctl restart nginx
systemctl enable nginx  # Enable auto-start on boot

Important Note About Testing:

Before we test in the browser, here's something to know: If your Strapi .env.stg file has HTTPS configured (like PUBLIC_URL=https://api.yourdomain.com), your site might not work properly until we install SSL in the next step.

What to do: If you run into connection issues when testing, don't worry - just proceed directly to Step 4 (SSL installation). Once SSL is configured, everything will work. You can verify everything at once after SSL is set up rather than testing at each intermediate step.

If your .env.stg has HTTP URLs (not HTTPS), you can test now and everything should work fine.

Test HTTP Access

Open your browser and visit: http://api.yourdomain.com

You should see your Strapi admin panel! We're now accessing Strapi through Nginx via your domain name.

If you see "502 Bad Gateway", make sure your Strapi container is actually running: docker compose -f docker-compose.stg.yml ps

---

Step 4: Install SSL Certificate with Let's Encrypt

Accessing your API over HTTP is fine for testing, but we need HTTPS for anything resembling production. Let's get a free SSL certificate from Let's Encrypt.

Install Certbot

Certbot is the official Let's Encrypt client. It automates the entire SSL certificate process.

# Still as root
apt install certbot python3-certbot-nginx -y

Obtain SSL Certificate

This is where the magic happens. Certbot will:

1. Verify you control the domain

2. Generate the SSL certificate

3. Automatically update your Nginx config

4. Set up auto-renewal

certbot --nginx -d api.yourdomain.com

You'll be prompted for:

1. Email address: Enter your email (used for renewal reminders)

2. Terms of Service: Type A to agree

3. Email newsletter: Type N (you can opt-in if you want updates)

4. Redirect HTTP to HTTPS?

Please choose whether or not to redirect HTTP traffic to HTTPS:
1: No redirect
2: Redirect - Make all requests redirect to secure HTTPS access

Choose option 2. This automatically redirects anyone visiting http://api.yourdomain.com to https://api.yourdomain.com.

Certbot will now:

• Verify domain ownership

• Generate certificates

• Update Nginx configuration

• Restart Nginx automatically

You should see:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/api.yourdomain.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/api.yourdomain.com/privkey.pem

That's it! Your site now has HTTPS. 🎉

Verify SSL Certificate

Open your browser and visit: https://api.yourdomain.com

You should see:

• The padlock icon in your browser's address bar

• "Connection is secure" when you click the padlock

• Your Strapi admin panel loading over HTTPS

Test the redirect: Visit http://api.yourdomain.com (without the 's'). You should automatically be redirected to https://api.yourdomain.com.

Test SSL Certificate Renewal

Let's Encrypt certificates expire after 90 days, but Certbot automatically renews them. Let's verify this is set up:

# Test the renewal process (doesn't actually renew)
certbot renew --dry-run

If this succeeds, you're all set. Certbot will automatically renew your certificate before it expires.

Check the auto-renewal timer:

systemctl status certbot.timer

You should see it's active and scheduled to run twice daily. Certbot checks if renewal is needed and renews if the certificate is close to expiring.

---

Step 5: Update Strapi Configuration for HTTPS

Now that we have HTTPS, we need to tell Strapi about it. This ensures Strapi generates correct URLs in API responses and handles requests properly.

Note: If your .env.stg already has the PUBLIC_URL configured with HTTPS, you can skip the editing part and just restart Strapi to ensure everything's fresh. Just verify the URL is correct below.

Update Environment Variables

# Exit root shell if you're still in it
exit

# Switch back to deploy user
cd /opt/strapi-backend

# Edit environment file
nano .env.stg

Add or update this line:

# Public URL
PUBLIC_URL=https://api.yourdomain.com

# CORS (if you have a frontend)
# Uncomment and update with your frontend domain
# ALLOWED_ORIGINS=https://yourdomain.com,https://www.yourdomain.com

Important: Replace api.yourdomain.com with your actual domain.

What PUBLIC_URL does:

• Sets the base URL for API responses

• Used for generating correct links in webhooks

• Helps Strapi understand it's being accessed via HTTPS

Save and exit.

Restart Strapi Container

docker compose -f docker-compose.stg.yml restart genkiStrapi

Wait about 30 seconds for Strapi to restart, then test: https://api.yourdomain.com/admin

Everything should work exactly the same, but now with HTTPS.

---

Step 6: Monitoring, Logs & Troubleshooting

Here's where we talk about what you actually need for effective debugging: comprehensive logging and systematic troubleshooting. This is the stuff that saves you when things break.

Why Logs Matter

Logs are your debugging lifeline. When something goes wrong (and it will), logs tell you:

• Did the request reach your server?

• What went wrong and where?

• Is someone attacking your API?

• Why is everything suddenly slow?

Without logs, you're flying blind. With logs, you can diagnose and fix issues in minutes instead of hours.

What Logs Does Nginx Generate?

Nginx creates two main log files that serve different purposes:

1. Access Logs (/var/log/nginx/access.log)

This logs every single HTTP request that hits your server. Each line is a complete record of one request.

Example log entry:

167.99.123.45 - - [04/Dec/2025:10:30:15 +0000] "GET /api/articles HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)"

Breaking it down:

• 167.99.123.45 - IP address of the client

• [14/Dec/2024:10:30:15 +0000] - Timestamp

• "GET /api/articles HTTP/1.1" - Request method, path, and protocol

• 200 - HTTP status code (200 = success, 404 = not found, 500 = error)

• 1234 - Response size in bytes

• "Mozilla/5.0..." - User agent (browser/client info)

What you can learn from access logs:

• Who's accessing your API and when

• What endpoints are getting hit the most

• Which requests are failing (4xx/5xx status codes)

• Response sizes and patterns

• Potential attack patterns (many requests from one IP)

2. Error Logs (/var/log/nginx/error.log)

This logs problems and errors that Nginx encounters. These are the logs you check when something's broken.

Understanding Error Log Levels:

Not all entries in the "error log" are actual problems you need to fix:

• [notice] - Informational messages (nginx starting, reloading configs) - completely normal

• [warn] - Warnings that might indicate issues worth investigating

• [error] - Actual errors affecting your site (connection failures, timeouts)

• [crit] - Critical errors (but see note below about SSL handshakes)

Example of what you'll actually see:

2025/12/04 06:22:36 [notice] 57335#57335: signal process started
2025/12/04 07:43:44 [crit] 58370#58370: *343 SSL_do_handshake() failed (SSL: error:0A00006C:SSL routines::bad key share) while SSL handshaking, client: 5.189.130.33, server: 0.0.0.0:443
2025/12/04 10:30:15 [error] 1234#1234: *5 connect() failed (111: Connection refused) while connecting to upstream, client: 167.99.123.45, server: api.yourdomain.com, request: "GET /admin HTTP/1.1"

Common "errors" that are actually harmless internet noise:

• SSL_do_handshake() failed - Random bots/scanners with incompatible SSL settings

• upstream prematurely closed connection - Client disconnected before response completed

• These happen constantly on any public server and aren't problems with your setup

Errors that actually matter and need fixing:

• connect() failed (111: Connection refused) - Nginx can't reach Strapi (container might be down)

• upstream timed out - Strapi is responding too slowly

• no live upstreams - Strapi container has stopped

• certificate verification failed - SSL certificate issues

What error logs tell you:

• Connection problems between Nginx and Strapi

• SSL certificate issues (actual problems, not bot noise)

• Configuration errors

• Timeout problems

• Permission issues

• Upstream server health

The key difference:

• Access logs: "What requests came in and what happened"

• Error logs: "What went wrong and why"

You'll use access logs to understand traffic patterns and error logs to debug problems.

3. Log Rotation (Automatic Maintenance)

Here's something important: logs can fill up your disk if left unchecked. Nginx handles this automatically through logrotate.

How log rotation works:

• Daily: Old log files are renamed (access.log becomes access.log.1)

• After 14 days: Old logs are compressed (access.log.14 becomes access.log.15.gz)

• After 52 days: Really old logs are deleted

• Your disk stays clean automatically

Check rotation configuration:

cat /etc/logrotate.d/nginx

You'll see something like:

/var/log/nginx/*.log {
    daily
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
}

For a $6/month staging environment with minimal traffic, the default rotation is perfect. You don't need to change anything. Your logs won't fill the disk, and you'll have 2 weeks of history available.

---

Step 7: Optional - Secure Port Access

Right now, users can access Strapi through:

• ✅ https://api.yourdomain.com (through Nginx - what we want)

• ⚠️ http://YOUR_IP:1337/admin (direct access - less secure)

• ⚠️ PostgreSQL port 5432 (for database clients like DBeaver)

Let's talk about whether you should close these direct access ports.

Closing Port 1337 (Direct Strapi Access)

Why close it:

• Forces all traffic through Nginx (better security, logging, SSL)

• Prevents bypassing security headers

• Standard practice for production setups

Why keep it open:

• Slightly easier debugging (can test Strapi directly)

My recommendation: Close it. Once Nginx is working, you don't need direct access to port 1337.

# Remove port 1337 from firewall
sudo ufw delete allow 1337/tcp

# Verify
sudo ufw status

Now http://YOUR_IP:1337 won't work, but https://api.yourdomain.com will work fine through Nginx.

PostgreSQL Port 5432 (Database Access)

This one's trickier. Let's consider both sides:

Why keep it open:

• Connect with database clients (DBeaver, pgAdmin)

• Run SQL queries during development

• Direct database backups

• Very convenient for debugging

Why close it:

• Exposes database to the internet

• Potential brute-force password attacks

• Not necessary if you only use Docker exec for database access

Security considerations:

If you keep port 5432 open:

• ✅ Use strong database passwords (not "password123")

• ✅ Restrict to specific IPs if possible (your office IP, home IP)

• ✅ Monitor access logs for suspicious connections

• ⚠️ Understand you're trading convenience for slightly increased risk

To restrict PostgreSQL to specific IPs:

# Allow only from your IP
sudo ufw allow from YOUR_HOME_IP to any port 5432

# Remove general access
sudo ufw delete allow 5432/tcp

# Verify
sudo ufw status

To close PostgreSQL entirely:

# Remove port 5432 from firewall
sudo ufw delete allow 5432/tcp

# Verify
sudo ufw status

You can still access the database via Docker:

docker compose -f docker-compose.stg.yml exec genkiStrapiDB psql -U postgres -d strapi_staging

My recommendation for staging: Keep PostgreSQL open if you're actively using database clients. It's convenient and the risk is manageable with strong passwords. Close it for production or if you're not using database clients.

Verify Your Firewall Rules

Check what ports are open:

sudo ufw status numbered

For a secure staging setup, you should see:

Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere
[ 4] 5432/tcp                   ALLOW IN    Anywhere    (optional)

Port 1337 should NOT be in this list if you closed it.

---

What About Rate Limiting?

You might have heard about rate limiting - it's a way to restrict how many requests someone can make in a given time period. For example, "100 requests per minute per IP address."

What rate limiting protects against:

• Brute force attacks (someone trying to guess passwords)

• DDoS attempts (overwhelming your server with requests)

• API abuse (someone hammering your endpoints)

• Accidental runaway scripts

For your $6/month staging environment: You probably don't need rate limiting yet. Here's why:

• You're getting minimal traffic (maybe 100-1000 requests per day)

• You're not a real attack target (yet)

• If someone does hammer your API, you'll see it in access logs

• Rate limiting adds complexity for minimal benefit at this stage

When you'll need rate limiting:

• Moving to production with real users

• Getting significant traffic (>10,000 requests/day)

• Experiencing actual attack attempts

• Building a public API

How to add it later: Nginx has built-in rate limiting that's pretty easy to configure. When you're ready, add this to your Nginx configuration:

# Define rate limit zone
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/m;

# Apply to your location block
location / {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://localhost:1337;
    # ... rest of your proxy settings
}

This allows 100 requests per minute per IP, with a burst allowance of 20 extra requests.

My recommendation: Skip rate limiting for now. Focus on getting your staging environment working smoothly. When you're ready for production or start seeing suspicious traffic patterns in your logs, add rate limiting then.

---

What We Built

Let's recap what your setup now includes:

Before Part 3:

• Strapi accessible at http://YOUR_IP:1337

• No SSL

• No custom domain

• Direct container access

After Part 3:

• ✅ Nginx reverse proxy handling all traffic

• ✅ Custom domain: api.yourdomain.com

• ✅ Free SSL certificate with auto-renewal

• ✅ Automatic HTTP to HTTPS redirects

• ✅ Security headers protecting against common attacks

• ✅ Optional port security (closing direct access)

This looks and feels production-ready. Sure, it's not handling enterprise-level traffic, but for a staging environment or small MVP? This setup is solid.

---

What's Next?

We've got a proper web server setup with SSL and comprehensive logging. Your Strapi backend now looks professional and secure.

But we're missing one critical piece: backups.

In Part 4, we're setting up automated daily backups to AWS S3:

• Automatic PostgreSQL database backups

• 120-day retention with lifecycle management

• Costs about $0.001/month (yes, less than a penny)

• Reliable restore procedures when things go wrong

• Backup verification and monitoring

The backup setup we'll build costs almost nothing but could save your entire project if something breaks. And since we're using AWS S3, you'll learn skills that transfer directly to production environments.

The infrastructure work is almost done. After Part 4 (backups) and Part 5 (CI/CD), you'll have a complete deployment pipeline that handles everything automatically.

---

Quick Reference

Here are the commands you'll use most often:

Nginx Management:

# Test configuration
sudo nginx -t

# Restart Nginx
sudo systemctl restart nginx

# Check status
sudo systemctl status nginx

# View error log
sudo tail -f /var/log/nginx/error.log

# View access log
sudo tail -f /var/log/nginx/access.log

SSL Certificate:

# Check certificate status
sudo certbot certificates

# Test renewal
sudo certbot renew --dry-run

# Force renewal
sudo certbot renew --force-renewal

# Check auto-renewal timer
sudo systemctl status certbot.timer

Troubleshooting:

# Check if Strapi is running
docker compose -f docker-compose.stg.yml ps

# View Strapi logs
docker compose -f docker-compose.stg.yml logs -f genkiStrapi

# Restart Strapi
docker compose -f docker-compose.stg.yml restart genkiStrapi

# Check system resources
docker stats

Firewall:

# Check firewall status
sudo ufw status

# Close port 1337 (direct Strapi access)
sudo ufw delete allow 1337/tcp

# Close PostgreSQL (database access)
sudo ufw delete allow 5432/tcp

---

Hit any snags setting up Nginx or SSL? Drop a comment with the error and I'll help you troubleshoot. Next week, we're tackling the backup system - see you then!