Why this setup#

With only two ports available, one is already reserved for SSH, which leaves just one for everything else. I do not want to spend that last port on a Cloudflare setup, since I may need it later for debugging or some other service. So I decided to use Cloudflare Tunnel instead.

And with only 256 MiB of memory, building an Astro site directly on the VPS is not very practical. So I build the site in GitHub Actions and deploy only the generated files to the server with rsync over SSH.

Add secrets to GitHub Actions#

Before creating the workflow, follow the official documentation and add the deployment credentials below as repository secrets or environment secrets in GitHub Actions:

• VPS_HOST: VPS IP address, for example 123.45.67.89
• VPS_PORT: SSH port, for example 22
• VPS_USER: deployment user, for example deploy
• VPS_TARGET_DIR: target directory on VPS, for example /var/www/fuwari-blog
• VPS_SSH_KEY: private SSH key used for deployment

Set up GitHub Actions#

Create .github/workflows/deploy.yml with the following workflow:

1
name: Build and Deploy to VPS
2

3
on:
4
  workflow_dispatch:
5
  push:
6
    branches: [main]
7

8
permissions:
9
  contents: read
10

11
jobs:
12
  build:
13
    runs-on: ubuntu-latest
14

15
    steps:
17 collapsed lines
16
      - name: Checkout
17
        uses: actions/checkout@v6
18

19
      - name: Setup pnpm
20
        uses: pnpm/action-setup@v5
21
        with:
22
          run_install: false
23

24
      - name: Setup Node.js
25
        uses: actions/setup-node@v6
26
        with:
27
          node-version: 24
28
          cache: pnpm
29

30
      - name: Install dependencies
31
        run: pnpm install --frozen-lockfile
32

33
      - name: Build site
34
        run: pnpm run build
35

36
      - name: Upload build artifact for VPS deploy
37
        uses: actions/upload-artifact@v7
38
        with:
39
          name: generated-site
40
          path: dist
41
          if-no-files-found: error
42

43
  deploy:
44
    needs: build
45
    runs-on: ubuntu-latest
46
    # Add below if you add secret as environment secrets instead of repository secrets
47
    # environment: <secret_environment>
48

49
    steps:
50
      - name: Download runtime artifact
51
        uses: actions/download-artifact@v8
52
        with:
53
          name: generated-site
54
          path: ./deploy
26 collapsed lines
55

56
      - name: Check website size (150 MB capacity guard)
57
        run: |
58
          SIZE_MB=$(du -sm ./deploy | cut -f1)
59
          echo "Deploy folder size: ${SIZE_MB} MB"
60
          if [ "$SIZE_MB" -gt 150 ]; then
61
            echo "Artifact too large for this VPS capacity limit."
62
            exit 1
63
          fi
64

65
      - name: Validate deploy secrets
66
        run: |
67
          test -n "${{ secrets.VPS_HOST }}" || (echo "Missing VPS_HOST" && exit 1)
68
          test -n "${{ secrets.VPS_PORT }}" || (echo "Missing VPS_PORT" && exit 1)
69
          test -n "${{ secrets.VPS_USER }}" || (echo "Missing VPS_USER" && exit 1)
70
          test -n "${{ secrets.VPS_TARGET_DIR }}" || (echo "Missing VPS_TARGET_DIR" && exit 1)
71
          test -n "${{ secrets.VPS_SSH_KEY }}" || (echo "Missing VPS_SSH_KEY" && exit 1)
72

73
      - name: Configure SSH
74
        run: |
75
          mkdir -p ~/.ssh
76
          chmod 700 ~/.ssh
77
          printf "%s\n" "${{ secrets.VPS_SSH_KEY }}" > ~/.ssh/id_ed25519
78
          chmod 600 ~/.ssh/id_ed25519
79
          ssh-keyscan -p "${{ secrets.VPS_PORT }}" "${{ secrets.VPS_HOST }}" >> ~/.ssh/known_hosts
80

81
      - name: Rsync to VPS
82
        run: |
83
          rsync -a \
84
            --delete-before \
85
            --inplace \
86
            --whole-file \
87
            --no-compress \
88
            --no-perms --no-owner --no-group \
89
            -e "ssh -p ${{ secrets.VPS_PORT }} -i ~/.ssh/id_ed25519" \
90
            ./deploy/ \
91
            "${{ secrets.VPS_USER }}@${{ secrets.VPS_HOST }}:${{ secrets.VPS_TARGET_DIR }}/"
92

93
      - name: Cleanup SSH key and known_hosts
94
        if: always()
95
        run: |
96
          rm -f ~/.ssh/id_ed25519
97
          rm -f ~/.ssh/known_hosts

This workflow is split into two jobs:

• build installs dependencies and generates the static site in dist
• The generated site is uploaded as a workflow artifact
• deploy downloads the artifact and syncs it to the VPS
• A size check helps prevent oversized deployments on a very small server
• SSH key and known_hosts file are cleaned up after deployment

Install Nginx#

Since the site will be served locally and exposed through Cloudflare Tunnel, the next step is to install Nginx. Here I am using the official Debian package repository provided by Nginx:

1
apt-get install curl gnupg2 ca-certificates lsb-release debian-archive-keyring
2

3
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
4
    | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
5

6
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
7
https://nginx.org/packages/debian `lsb_release -cs` nginx" \
8
    | sudo tee /etc/apt/sources.list.d/nginx.list
9

10
apt-get update && apt-get install nginx

Configure Nginx#

After installing Nginx, remove the default config, add a new server block for the blog, then test and reload the service.

a. Remove default config and create new one for the blog

1
rm /etc/nginx/conf.d/default.conf
2
nano /etc/nginx/conf.d/fuwari-blog.conf

b. Use following configuration to serve the blog on 127.0.0.1:8080

1
server {
2
    listen 127.0.0.1:8080;
3
    server_name localhost;
4

5
    root /var/www/fuwari-blog;
6
    gzip on;
7

8
    location / {
9
        try_files $uri $uri/ /index.html;
10
    }
11

12
    location ~* \.(js|mjs|css|png|jpg|jpeg|gif|webp|svg|ico|woff2?)$ {
13
        add_header Cache-Control "public, max-age=3600, immutable" always;
14
        try_files $uri =404;
15
    }
16
}

c. Test configuration and start Nginx

1
nginx -t
2
systemctl enable nginx --now

If Nginx is already running before any change is made, reload it to apply new configuration:

1
systemctl reload nginx

Install cloudflared#

Next, install the Cloudflare Tunnel client, cloudflared, from Cloudflare’s Debian package repository:

1
sudo mkdir -p --mode=0755 /usr/share/keyrings
2
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
3

4
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
5

6
sudo apt-get update && sudo apt-get install cloudflared

Quick tunnel test#

Before setting up a tunnel in production, start with a quick tunnel to make sure the local Nginx service is reachable through Cloudflare Tunnel:

1
cloudflared tunnel --url http://localhost:8080

1
2026-04-14T03:13:00Z INF Thank you for trying Cloudflare Tunnel. Doing so, without a Cloudflare account, is a quick way to experiment and try it out. However, be aware that these account-less Tunnels have no uptime guarantee, are subject to the Cloudflare Online Services Terms of Use (https://www.cloudflare.com/website-terms/), and Cloudflare reserves the right to investigate your use of Tunnels for violations of such terms. If you intend to use Tunnels in production you should use a pre-created named tunnel by following: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps
2
2026-04-14T03:13:00Z INF Requesting new quick Tunnel on trycloudflare.com...
3
2026-04-14T03:13:09Z INF +--------------------------------------------------------------------------------------------+
4
2026-04-14T03:13:09Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
5
2026-04-14T03:13:09Z INF |  https://<random-string>.trycloudflare.com                                    |
6
2026-04-14T03:13:09Z INF +--------------------------------------------------------------------------------------------+
7
2026-04-14T03:13:09Z INF Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /etc/cloudflared /usr/local/etc/cloudflared]
8
2026-04-14T03:13:09Z INF Version 2026.3.0-2-ga0e55fc9 (Checksum 81a043e9865c932b7755f347fdc404e3f246cb99b3251d6df022418b1b73b208)
9
2026-04-14T03:13:09Z INF GOOS: linux, GOVersion: go1.26.0, GoArch: amd64
10
2026-04-14T03:13:09Z INF Settings: map[ha-connections:1 protocol:quic url:http://localhost:8080]
11
2026-04-14T03:13:09Z INF cloudflared will not automatically update if installed by a package manager.
12
...

Open the https://<random-string>.trycloudflare.com URL from the log and check whether the blog is reachable.

The problem with the official approach#

CAUTION

The result below comes from following the official steps directly. On an LXC VPS, this is the approach you should avoid.

You may already have tried the official “Create a tunnel” documentation, but this approach has a problem here.

The official documentation asks you to execute the following command:

1
sudo cloudflared service install abcdefghijklmnopqrstuvwxyz

This command creates a systemd service that starts automatically at boot:

1
# /etc/systemd/system/cloudflared.service
2
[Unit]
3
Description=cloudflared
4
After=network-online.target
5
Wants=network-online.target
6

7
[Service]
8
TimeoutStartSec=15
9
Type=notify
10
ExecStart=/usr/bin/cloudflared --no-autoupdate tunnel run --token abcdefghijklmnopqrstuvwxyz
11
Restart=on-failure
12
RestartSec=5s
13

14
[Install]
15
WantedBy=multi-user.target

When you inspect the process information, the token is embedded in the command line:

1
ps -fp "$(systemctl show -p MainPID --value cloudflared)"
2
UID          PID    PPID  C STIME TTY          TIME CMD
3
root        7668       1  0 06:57 ?        00:00:00 /usr/bin/cloudflared --no-autoupdate tunnel run --token abcdefghijklmnopqrstuvwxyz

cloudflared service install <token> works, but it embeds the token directly into the service startup command. On an LXC VPS, where the host system may be able to inspect container processes, filesystem contents, and network activity, that is not a risk I want to take.

Why passing credentials on the command line is risky#

Technically, unless you control your own encryption keys, VPS provider can potentially access your data regardless of whether the VPS runs on KVM or LXC. The difference is mostly in how direct that access is.

That is why the goal here is simply to avoid exposing the token directly in the process list, where it could be revealed by something as simple as ps -ef. If we are being serious about security, nothing on the filesystem should be treated as completely secret. What we can do here is avoid the most obvious and easily exposed method.

If qemu-ga is installed inside the VPS, the host can also use the guest agent to perform operations such as reading or writing files inside the guest. That may sound alarming, but qemu-ga is commonly used for guest management and automation, such as reporting system information, handling graceful shutdown or reboot, freezing filesystems for snapshots, and in some cases resetting a user password. On Azure, qemu-ga is not used; instead, Azure uses its own VM agent, waagent, which serves a similar but more Azure-specific purpose.

In short, credentials passed through command-line arguments are easier to expose, especially during troubleshooting or host-side inspection.

Set up the legacy Cloudflare tunnel#

The legacy Cloudflare tunnel, also known as a locally-managed tunnel, uses a file-based credential, so it does not appear directly in the process command line.

NOTE

Considered that the documentation now calls this a legacy configuration. Later, I will migrate it to the remotely-managed tunnel that Cloudflare recommends today.
One thing to keep in mind is that the old file-based credential remains valid and is [not revoked automatically][tunnel-permissions]. To revoke the credential, you need to delete the tunnel.

a. Log into cloudflared

1
cloudflared tunnel login

b. Follow the prompt to complete the login in your browser
An example prompt looks like this:

1
Please open the following URL and log in with your Cloudflare account:
2

3
https://dash.cloudflare.com/argotunnel?aud=&callback=https%3A%2F%2Flogin.cloudflareaccess.org%2Fxxxxxxxxxxxxxxxxxxxxxxxxxxxx
4

5
Leave cloudflared running to download the cert automatically.
6
2026-04-14T04:14:38Z INF You have successfully logged in.
7
If you wish to copy your credentials to a server, they have been saved to:
8
/root/.cloudflared/cert.pem

c. Create the tunnel

1
cloudflared tunnel create fuwari-blog

The output will also show where the tunnel credentials are stored:

1
Tunnel credentials written to /root/.cloudflared/<TUNNEL-UUID>.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
2

3
Created tunnel fuwari-blog with id <TUNNEL_UUID>

If you list the directory, you will see both the account certificate and the tunnel credential file:

1
ls ~/.cloudflared/

1
<TUNNEL-UUID>.json  cert.pem

d. Run the tunnel in the foreground to verify the connection

1
cloudflared --no-autoupdate tunnel run <TUNNEL_UUID>

Output:

1
2026-04-14T05:17:24Z INF Starting tunnel tunnelID=<TUNNEL_UUID>
2
2026-04-14T05:17:24Z INF Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /etc/cloudflared /usr/local/etc/cloudflared]
3
2026-04-14T05:17:24Z INF Version 2026.3.0-2-ga0e55fc9 (Checksum 81a043e9865c932b7755f347fdc404e3f246cb99b3251d6df022418b1b73b208)
4
2026-04-14T05:17:24Z INF GOOS: linux, GOVersion: go1.26.0, GoArch: amd64
5
2026-04-14T05:17:24Z INF Settings: map[no-autoupdate:true]
6
2026-04-14T05:17:24Z INF cloudflared will not automatically update if installed by a package manager.
7
2026-04-14T05:17:24Z INF Generated Connector ID: de376c93-29e6-4b83-a495-b3173274aa9c
8
2026-04-14T05:17:24Z WRN No ingress rules were defined in provided config (if any) nor from the cli, cloudflared will return 503 for all incoming HTTP requests
9
2026-04-14T05:17:24Z INF Initial protocol quic
10
2026-04-14T05:17:24Z INF ICMP proxy will use 10.0.1.4 as source for IPv4
11
2026-04-14T05:17:24Z INF ICMP proxy will use 2001:157:a:135::56b2 in zone eth0 as source for IPv6
12
2026-04-14T05:17:24Z WRN The user running cloudflared process has a GID (group ID) that is not within ping_group_range. You might need to add that user to a group within that range, or instead update the range to encompass a group the user is already in by modifying /proc/sys/net/ipv4/ping_group_range. Otherwise cloudflared will not be able to ping this network error="Group ID 0 is not between ping group 1 to 0"
13
2026-04-14T05:17:24Z WRN ICMP proxy feature is disabled error="cannot create ICMPv4 proxy: Group ID 0 is not between ping group 1 to 0 nor ICMPv6 proxy: socket: permission denied"
14
2026-04-14T05:17:24Z INF ICMP proxy will use 10.0.1.4 as source for IPv4
15
2026-04-14T05:17:24Z INF ICMP proxy will use 2001:157:a:135::56b2 in zone eth0 as source for IPv6
16
2026-04-14T05:17:24Z INF Starting metrics server on 127.0.0.1:20241/metrics
17
2026-04-14T05:17:24Z INF Tunnel connection curve preferences: [X25519MLKEM768 CurveP256] connIndex=0 event=0 ip=198.41.199.193
18
2026-04-14T05:17:24Z INF Registered tunnel connection connIndex=0 connection=e8669842-7a21-430d-8f26-0c828c73de3b event=0 ip=198.41.199.193 location=hkg01 protocol=quic
19
2026-04-14T05:17:24Z INF Tunnel connection curve preferences: [X25519MLKEM768 CurveP256] connIndex=1 event=0 ip=198.41.192.51
20
2026-04-14T05:17:24Z INF Registered tunnel connection connIndex=1 connection=49703548-fa99-4e3c-ba2e-3717550e383b event=0 ip=198.41.192.51 location=hkg11 protocol=quic
21
2026-04-14T05:17:25Z INF Tunnel connection curve preferences: [X25519MLKEM768 CurveP256] connIndex=2 event=0 ip=198.41.192.124
22
2026-04-14T05:17:25Z INF Registered tunnel connection connIndex=2 connection=e7c3020e-bab5-499b-a664-1460e73cfd12 event=0 ip=198.41.192.124 location=hkg01 protocol=quic
23
2026-04-14T05:17:26Z INF Tunnel connection curve preferences: [X25519MLKEM768 CurveP256] connIndex=3 event=0 ip=198.41.199.62
24
2026-04-14T05:17:26Z INF Registered tunnel connection connIndex=3 connection=d5c4628e-0005-42d4-9a4d-3d298c4b035d event=0 ip=198.41.199.62 location=hkg05 protocol=quic

Migrate from the legacy Cloudflare tunnel#

a. Move the tunnel credential into /etc/cloudflared and remove account certificate file

1
mkdir /etc/cloudflared/
2
mv ~/.cloudflared/*.json /etc/cloudflared/
3
rm ~/.cloudflared/cert.pem

NOTE

Also remember to delete API tokens created via cloudflared: https://dash.cloudflare.com/profile/api-tokens

b. Migrate legacy tunnel in Cloudflare Dashboard

After creating the tunnel locally, open the Cloudflare Zero Trust Dashboard and go to Networks -> Connectors -> Cloudflare Tunnels. You should see your tunnel listed there. Select the tunnel you created.

Since it is a locally managed tunnel, Cloudflare will show a migration prompt and tell you that it cannot be managed from the dashboard yet. Click Start migration to continue.

TIP

If the Start migration button is grayed out, it usually means either the previous cloudflared --no-autoupdate tunnel run <TUNNEL_UUID> command has not been run yet, or the server cannot reach Cloudflare. Run the command first, and if the button is still unavailable, check whether your network environment meets Cloudflare Tunnel’s outbound requirements.

Publish the blog#

Once the migration is complete, add a published application route for the blog:

• Subdomain: blog (or any subdomain you prefer)
• Domain: your domain
• Type: HTTP
• URL: localhost:8080

Then click Save. After that, Cloudflare will automatically configure the DNS record, and requests to your domain will be routed to the local Nginx service through tunnel once cloudflared is running.

a. Create the cloudflared systemd service

1
nano /etc/systemd/system/cloudflared.service

Replace <TUNNEL_UUID> with your actual tunnel ID:

1
[Unit]
2
Description=cloudflared
3
After=network-online.target
4
Wants=network-online.target
5

6
[Service]
7
TimeoutStartSec=15
8
Type=notify
9
ExecStart=/usr/bin/cloudflared --no-autoupdate tunnel run <TUNNEL_UUID>
10
Restart=on-failure
11
RestartSec=5s
12

13
[Install]
14
WantedBy=multi-user.target

b. Reload systemd, then enable and start service

1
systemctl daemon-reload
2
systemctl enable cloudflared --now

Your blog should now be up and running.