Forem: David M.

How to Host a Blog on a Subdirectory with Cloudflare Workers

David M. — Tue, 25 Nov 2025 20:11:34 +0000

Original Blog Post: https://www.davidma.co/blog/2025-11-14-host-your-blog-on-a-subdirectory

How to Host Your Blog on a Subdirectory with Cloudflare

In this guide, you'll learn how to host your blog on a subdirectory (e.g. example.com/blog) instead of a subdomain (e.g., blog.example.com). Every step here has been tested and verified to work.

Introduction

Hosting your blog on a subdirectory can improve SEO and enhance user experience.

Although there are a lot of articles that espouse the benefits of using subdirectories over subdomains, few resources that provide a step-by-step guide on how to actually set this up.

Why Host on a Subdirectory?

The benefits to hosting on a subdirectory is primarily to improve SEO.

There are a lot of other articles out there on this topic, but they all say something similar to the following:

Hosting your blog on a subdirectory is better for SEO because it consolidates your website's authority and ranking power.

Google has stated that they do not treat subdomains as a separate entity.

Despite what Google has stated, empiric data suggests that subdirectories outperform subdomains in search rankings.

If you want to maximize your SEO efforts, hosting on a subdirectory is the way to go.

If you want to learn more, you can read this article by ButterCMS: Blog Subdomain or Subdirectory? Hint: One is 40% Better.

My personal experience has been similar. When I moved a blog from a subdomain to a subdirectory, I saw a noticeable increase in organic traffic and search engine rankings. The increase happened after a few weeks. During that time, I did not release any new content and nor did I promote the blog.

Why Not Host on a Subdirectory?

The setup is more complex. Many blogging platforms and CMSs are designed to work on subdomains, and configuring them to work on a subdirectory can be tricky.

I've personally found the setup process to be quite time consuming. It's a tricky process and you have to follow the instructions carefully. After having previously changed a blog from a subdomain to a subdirectory, I've found difficult to justify the time to do it for taikohub.com.

If you still think it's worth your time, then read on.

Steps to Host Your Blog on a Subdirectory

Lets suppose you have two sites right now. One is example.com and the other is blog.example.com. You want to host the blog on example.com/blog instead of blog.example.com.

Lets also suppose your blog (blog.example.com) is a Next.js app hosted on Vercel and your main site (example.com) is a static site hosted on Render.

Although Vercel and Render are used as examples here, the steps are nearly identical for other hosting providers. You do not need configure anything for your hosting provider. Everything can be done from the Cloudflare Dashboard, and from the comforts of your text editor.

Important: Note that Cloudflare often changes their dashboard UI and routes. If you find that the steps here do not match what you see on your Cloudflare Dashboard, just use the search function in the dashboard to find the relevant section.

Step 1: Set Up DNS Records for the Main Site

First, set up the DNS records for your main site (example.com). Again, if you do not use Render, then follow the equivalent steps for your hosting provider. Generally this should be in their documentation.

Go to your Cloudflare Dashboard. Click into your domain, then SSL/TLS, then Overview. Then click "Configure".

Next, select "Custom SSL/TLS" then select "Full".

Go to DNS records in the sidebar by clicking on "DNS", then "DNS Records". Then click "Add Record".

Add the following DNS Records. Replace my-site.onrender.com with the service URL for your main site. If you have other applications such as an API, you can add those as well. Note that it's important you set the "Proxy status" to "Proxied". It's also important you do NOT add a wildcard record (eg. *.example.com).

Type	Name	Target	Proxy status	TTL
CNAME	@	my-site.onrender.com	Proxied	Auto
CNAME	www	my-site.onrender.com	Proxied	Auto
CNAME	api	my-api.onrender.com	Proxied	Auto

Step 2: Set Up DNS Records for the Blog

Make sure your blog is already accessible on a subdomain (eg. blog.example.com).

Add another DNS Record for the blog. Replace cname.vercel-dns.com with the CNAME target provided by the hosting provider for your blog.

Type	Name	Target	Proxy status	TTL
CNAME	example.com	my-site.onrender.com	Proxied	Auto
CNAME	www	my-site.onrender.com	Proxied	Auto
CNAME	api	my-api.onrender.com	Proxied	Auto
CNAME	blog	cname.vercel-dns.com	Proxied	Auto

Step 3: Configure Your Next.js Blog

Ensure Correct Routing for Static Assets

Make sure that your Next.js blog's router points to / and not /blog. You should NOT have any routes that contain /blog. Edit the next.config.js or next.config.mjs file and add basePath: "/blog" to the config.

/** @type {import('next').NextConfig} */
const nextConfig = {
  basePath: "/blog",  // Add this line
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "imagedelivery.net",
      },
    ],
  },
  redirects: async () => {
    return [];
  },
};

export default nextConfig;

Step 4: Add a Cloudflare Worker

Go to Cloudflare Dashboard. Click "Workers & Pages". Click "Create" then click "Create Worker".

For the purpose of this blog post, we'll go with the easiest option by selecting "Start with Hello World!". For production applications, consider using Git. It looks like the following. Lets name it blog-worker. Then click "Deploy".

// worker.js
/**
* Welcome to Cloudflare Workers! This is your first worker.
*
* - Run "npm run dev" in your terminal to start a development server
* - Open a browser tab at http://localhost:8787/ to see your worker in action
* - Run "npm run deploy" to publish your worker
*
* Learn more at https://developers.cloudflare.com/workers/
*/
export default {
  async fetch(request, env, ctx) {
    return new Response('Hello World!');
  },
};

Now replace the code with the following:

export default {
  async fetch(request, env, ctx) {
    async function MethodNotAllowed(request) {
      return new Response(`Method ${request.method} not allowed.`, {
        status: 405,
        headers: {
          Allow: "GET",
        },
      });
    }
    // Only GET requests work with this proxy.
    if (request.method !== "GET") return MethodNotAllowed(request);

    // Get the URL that was just requested.
    const url = new URL(request.url);

    // Swap out the subdirectory with the subdomain to request the actual URL.
    const originUrl = url.toString().replace(
      'https://example.com/blog',
      'https://blog.example.com/blog'
    ).replace(
      'https://www.example.com/blog',
      'https://blog.example.com/blog'
    );

    // Fetch the origin.
    const originPage = await fetch(originUrl);

    // Return the subdomain, as the subdirectory.
    const newResponse = new Response(originPage.body, originPage);
    return newResponse;
  },
};

Change the URLs as needed. To save, click on the version ID hash (eg. b30983e0) then click "Apply".

To deploy the changes, go to the worker dashboard. Click "Deployments". Look under "Version History". Click "…" then "Deploy" on the latest version.

Version ID	Created	Version & Git Message	Source
vb29485e0	3min…	Update to …	Dashboard	"…"
vf859f2e0	2h…	Updated Script	Dashboard	"…"

Step 5: Connect Next.js Site with Cloudflare Worker

Go to "Worker Routes" in the Cloudflare Dashboard sidebar. Click on "Add Route".

Add the following route for the blog content:

Route: example.com/blog*
Worker: blog-worker. This is the worker you just created.

Add another route for the static assets:

Route: example.com/blog/_next/static*
Worker: blog-worker

You should now be able to access your blog at example.com/blog. If this works, congratulations! You've successfully hosted your blog on a subdirectory using Cloudflare Workers.

Configure Search Engine Robots.txt in Your Next.js App

Now that you've successfully hosted the blog on the subdirectory, you need to make sure search engines don't index the subdomain. This is because the blog is already indexed on the subdirectory. If search engines index both, then you may run into SEO issues due to duplicate content.

Update your next.config.js or next.config.mjs file.

/** @type {import('next').NextConfig} */
const nextConfig = {
  basePath: "/blog",
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "imagedelivery.net",
      },
    ],
  },
  redirects: async () => {                      // Add this block
    return [];
  },
  async headers() {                             // Add this block
    return [
      {
        source: '/:path*',
        headers: [
          {
            key: 'X-Robots-Tag',
            value: 'noindex, nofollow',
          },
        ],
      },
    ];
  },
};

export default nextConfig;

Now update your cloudflare worker.

export default {
  async fetch(request, env, ctx) {
    async function MethodNotAllowed(request) {
      return new Response(`Method ${request.method} not allowed.`, {
        status: 405,
        headers: {
          Allow: "GET",
        },
      });
    }
    // Only GET requests work with this proxy.
    if (request.method !== "GET") return MethodNotAllowed(request);

    // Get the URL that was just requested.
    const url = new URL(request.url);

    // Swap out the subdirectory with the subdomain to request the actual URL.
    const originUrl = url.toString().replace(
      'https://example.com/blog',
      'https://blog.example.com/blog'
    ).replace(
      'https://www.example.com/blog',
      'https://blog.example.com/blog'
    );

    // Fetch the origin.
    const originPage = await fetch(originUrl);

    // Return the subdomain, as the subdirectory.
    let newResponse = new Response(originPage.body, originPage);

    // Remove "noindex" from the origin domain.
    newResponse.headers.delete("x-robots-tag");

    return newResponse;
  },
};

Step 6: Verify Your Subdomain is Not Indexed

Open your app's deploy URL. This may look something like https://vercel.com/my-projects-30d8ek3n/my-blog/d934nfid9823sbsNgoMnOOnsiKxn.

Open the browser's Network tab in Developer Tools.

Check for existence of an "X-Robots-Tag" header. If it's not there, then your Next.js app is correctly configured to not be indexed.

Step 7: Verify Your Subdirectory is Indexed

Go to Google URL Inspection Tool.

Enter your subdirectory URL (eg. example.com/blog).

Confirm that it shows as indexed.

How to Setup a Secure Ubuntu Home Server: A Complete Guide

David M. — Wed, 30 Jul 2025 20:56:33 +0000

Original Blog Post: https://www.davidma.co/blog/2025-07-24-home-server

Setting up a home server can seem daunting, but with this blog post, you too can transform an old PC into a secure home server! This blog post will walk you through every step, from basic SSH setup to advanced security hardening.

Prerequisites

Before we begin, ensure you have:

A PC with Ubuntu installed (Either Ubuntu Server or Desktop is fine)
Basic command line familiarity
Administrative access to your home router
Another computer to test SSH connections

Quick Reference: Essential Commands

Here are some handy vim commands you might use throughout this guide. If you're not familiar with vim, you can use any text editor of your choice.

Open remote files: vim scp://user@server//home/user/file.py
Open multiple files in tabs: vim -p file1.txt file2.txt (may need :tab all)

Step 1: Setting Up SSH Access

SSH (Secure Shell) is the foundation of remote server management. Let's get it configured first.

Install and Enable OpenSSH Server

sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl status ssh

Find Your Server's IP Address

hostname -I

This will return something like 10.0.0.207 - note this down as we'll use it throughout the guide.

Test SSH Connection

From your client computer, try connecting:

ssh user@10.0.0.207

You'll need to enter your password at this point.

Set Up Key-Based Authentication

For better security and convenience, set up SSH key authentication:

ssh-copy-id user@10.0.0.207

After this, you should be able to SSH without entering a password.

Step 2: Configuring a Static IP Address

Dynamic IP addresses can change, which gets troublesome whenever you need to connect to your server. Let's set up a static IP to avoid this.

Understanding Netplan

Ubuntu uses Netplan for network configuration. Navigate to the netplan directory:

cd /etc/netplan/
ls

You should see a file like 01-network-manager-all.yaml.

Create a Backup

Always backup before making changes:

sudo cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all-BACKUP.yaml

Create Static IP Configuration

Create a new configuration file:

sudo vim /etc/netplan/static.yaml

Use this template (we'll customize it next):

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses:
        - 10.10.10.2/24
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
          addresses: [1.1.1.1, 1.0.0.1]

Get Network Interface Information

Find your network interface name:

ifconfig -a

Look for something like enp42s0 (ignore the lo interface). You'll also note your current IP address.

Customize the Configuration

Update your static.yaml file:

Replace eth0 with your actual interface name (e.g., enp42s0)
Set your desired static IP (e.g., 10.0.0.207/24)
Set your router's gateway (usually 10.0.0.1 for most home routers)
Use Cloudflare's DNS servers: [1.1.1.1, 1.0.0.1]

Apply the Configuration

Set proper permissions and apply:

sudo chmod 600 /etc/netplan/static.yaml
sudo netplan apply
sudo reboot

Test the connection from your client:

ssh user@10.0.0.207

Step 3: Hardening with UFW Firewall

UFW (Uncomplicated Firewall) provides an easy way to manage iptables rules.

Install and Enable UFW

sudo apt install ufw
sudo systemctl status ufw
sudo ufw enable

Set Default Policies

Start with a deny-all approach:

sudo ufw default deny incoming
sudo ufw default deny outgoing

Allow Essential Services

Open only the ports you need:

# Web traffic
sudo ufw allow 80,443/tcp
sudo ufw allow out 80,443/tcp

# SSH (we'll change this port later)
sudo ufw allow 22/tcp
sudo ufw allow out 22/tcp

# NTP for time synchronization
sudo ufw allow 123/udp
sudo ufw allow out 123/udp

# DNS resolution
sudo ufw allow in from any to any port 53
sudo ufw allow out from any to any port 53

Check Firewall Status

sudo ufw status numbered

You should see a comprehensive list of rules for both IPv4 and IPv6.

Step 4: Network Time Protocol (NTP) Setup

Accurate time is crucial for security certificates and log correlation.

Backup Current Configuration

sudo cp --archive /etc/systemd/timesyncd.conf /etc/systemd/timesyncd.conf-COPY-$(date +"%Y%m%d%H%M%S")

Configure NTP

Edit the configuration file:

sudo vim /etc/systemd/timesyncd.conf

Add these lines:

[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=ntp.ubuntu.com

Restart and Verify

sudo systemctl restart systemd-timesyncd
sudo systemctl status systemd-timesyncd

Set Your Timezone

Check current timezone:

timedatectl | grep Time

If needed, set it correctly:

sudo timedatectl set-timezone America/Vancouver

Step 5: Advanced SSH Security

Now let's seriously harden SSH security.

Change SSH Port

First, allow the new port through UFW:

sudo ufw allow 2222/tcp
sudo ufw allow out 2222/tcp

Backup SSH Configuration

sudo cp --preserve /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +"%Y%m%d%H%M%S")

Apply Hardened SSH Configuration

Edit the SSH config:

sudo vim /etc/ssh/sshd_config

Delete everything (:%d in vim) and paste this hardened configuration:

# Supported HostKey algorithms by order of preference
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

# Cryptographic settings
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

# Security settings
Port                            2222
LogLevel                        VERBOSE
Protocol                        2
PermitUserEnvironment           no
PermitRootLogin                 no
PubkeyAuthentication            yes
PasswordAuthentication          no
PermitEmptyPasswords            no
MaxAuthTries                    3
MaxSessions                     2
X11Forwarding                   no
IgnoreRhosts                    yes
UseDNS                          no
ClientAliveCountMax             0
ClientAliveInterval             300
AllowUsers                      YOUR_USERNAME  # CHANGE THIS!

# Disable port forwarding
AllowAgentForwarding            no
AllowTcpForwarding              no
AllowStreamLocalForwarding      no
GatewayPorts                    no
PermitTunnel                    no

# SFTP logging
Subsystem sftp  /usr/lib/openssh/sftp-server

# Additional security
Compression                     no
PrintMotd                       no
TCPKeepAlive                    no
ChallengeResponseAuthentication no
UsePAM                          yes
AcceptEnv LANG LC_*

Important: Replace YOUR_USERNAME with your actual username!

Restart SSH and Verify

sudo systemctl restart sshd
sudo ss -tlpn | grep ssh

You should see SSH listening on port 2222.

Test New SSH Configuration

From your client computer:

ssh -p 2222 user@10.0.0.207

Once you confirm the new port works, delete the old SSH port:

sudo ufw delete allow 22/tcp
sudo ufw delete allow out 22/tcp

Optional: Auto-logout After Inactivity

Add automatic logout after 5 minutes of inactivity:

echo 'TMOUT=300' >> ~/.bashrc

Strengthen SSH Keys

Remove weak moduli:

# Backup existing moduli file
sudo cp --archive /etc/ssh/moduli /etc/ssh/moduli-COPY-$(date +"%Y%m%d%H%M%S")

# Remove keys weaker than 3072 bits
sudo awk '$5 >= 3071' /etc/ssh/moduli | sudo tee /etc/ssh/moduli.tmp
sudo mv /etc/ssh/moduli.tmp /etc/ssh/moduli

Add Legal Banner

Create a warning banner:

sudo vim /etc/issue.net

Add this message:

This system is for the use of authorised users only.

Individuals using this computer system without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel.

In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorised users may also be monitored.

Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials.

Step 6: Git Configuration for Development

If you plan to use your server for development, configure Git properly.

Allow Git Port (Optional)

sudo ufw allow 9418/tcp

Configure Git for SSH

Instead of the standard GitHub SSH URL, use the HTTPS port for better firewall compatibility:

# Standard approach
git remote add origin git@github.com:username/repository.git

# Firewall-friendly approach
git remote add origin ssh://git@ssh.github.com:443/username/repository.git

Additional Security Considerations

Network-Level Restrictions

For maximum security, consider restricting SSH access to your local network only. You can modify UFW rules to only allow connections from your local subnet:

sudo ufw allow from 10.0.0.0/24 to any port 2222

Regular Maintenance

Keep your system updated: sudo apt update && sudo apt upgrade
Monitor SSH logs: sudo journalctl -u ssh
Review firewall logs: sudo ufw status verbose
Check for failed login attempts: sudo grep "Failed password" /var/log/auth.log

Conclusion

You now have a secure Ubuntu home server with:

✅ SSH access with key-based authentication
✅ Static IP configuration
✅ Hardened firewall rules
✅ Network time synchronization
✅ Secure SSH configuration on a non-standard port
✅ Git development capabilities

This setup provides a solid foundation for hosting services, running development environments, or managing home automation systems. Remember to regularly update your system and monitor logs for any suspicious activity.