Before we get into the steps, here is a quick look at how I got started.

How I Found Vaultwarden

I first came across the Vaultwarden repo sometime in the summer of 2025. After watching a YouTube tutorial, I figured it was something I could handle, even though I was still pretty new to Docker. I tried running the script directly from the README:

docker pull vaultwarden/server:latest
docker run --detach --name vaultwarden \
  --env DOMAIN="https://vw.domain.tld" \
  --volume /vw-data/:/data/ \
  --restart unless-stopped \
  --publish 127.0.0.1:8000:80 \
  vaultwarden/server:latest

It worked in the sense that I could see the login screen when I navigated to the resource and port. But I could not actually log in or access anything, as you can see here:

I searched around for a while but did not have the time to dig deeper. I eventually moved on to other projects like Portainer and SterlingPDF.

Prerequisites

Before you start, here is what you need:

• Raspberry Pi running Raspberry Pi OS

• Docker and Docker Compose installed

• A Cloudflare account with a registered domain

• Basic familiarity with SSH

• A willingness to troubleshoot a bit

This setup is beginner friendly, but having these pieces in place will save you time.

Returning to the Project

I came back to this project at the end of 2025 around New Year's weekend. This time, I switched to Docker Compose and cleaned up the configuration. Here is the actual file I used:

services:
  vaultwarden:
    image: vaultwarden/server:alpine
    container_name: vaultwarden
    restart: always
    environment:
      DOMAIN: "https://pass.example.com"
      SIGNUPS_ALLOWED: "true" # Set to false after creating your account
      ADMIN_TOKEN: ${ADMIN_TOKEN}
    volumes:
      - ./vw-data:/data
    ports:
      - 11001:80

Why Alpine Matters on Raspberry Pi

This is one of the biggest gotchas. Raspberry Pi OS uses ARM architecture. The latest Vaultwarden image is built for x86 systems, so it will not run correctly on a Pi. The Alpine variant supports ARM out of the box, which is why vaultwarden/server:alpine is required.

Why HTTPS Is Required

Vaultwarden does not support HTTP for normal operation. It needs to know it is behind HTTPS so that attachments, WebSockets, and the web vault function correctly. If you try to access it over plain HTTP, you will run into the same issues I did during my first attempt.

Running the Container

I started the container with:

docker compose up -d

And checked logs with:

docker logs -f vaultwarden

This step is optional but helpful for catching errors early.

Why I Chose Cloudflare Tunnels

Most tutorials use Caddy or Nginx Proxy Manager. I already had a Cloudflare Tunnel running for my NocoDB project and liked the simplicity of outbound-only connections. No port forwarding, no exposing your home network, and Cloudflare handles the heavy lifting.

In my first project, I installed the Cloudflare Tunnel via the CLI. This time, I wanted to use the Cloudflare One Dashboard. My domain was already registered with Cloudflare, so I logged into Cloudflare One.

In the Zero Trust Platform, click on "Networks".

Under Networks, go to “Manage Tunnels” and set up a tunnel if you do not already have one. The process is straightforward.

From here, manage the routed hostnames as shown below:

Cloudflare will automatically create a CNAME record in your DNS settings. Within a few seconds, you will be able to navigate to your Vaultwarden instance securely.

This method works for almost any service running on a port. I prefer it over opening ports on my router, which can introduce security risks. Cloudflare Tunnels create an outbound-only connection from your device to Cloudflare and rely on their global network to handle the rest.

Backup Reminder

Your entire Vaultwarden instance lives in the /data directory. Back it up regularly. A simple file-level backup is enough to restore your vault if anything goes wrong.

Security Tips

A few quick reminders:

• Disable signups after creating your account.

• Store your ADMIN_TOKEN in an .env file instead of hardcoding it.

• Keep your Pi updated.

• Use strong passwords for your Cloudflare account and enable 2FA.

Small steps like these go a long way.

Troubleshooting Tips

Here are a few common issues you might run into:

• Using the wrong image on Raspberry Pi

• DOMAIN not set or set incorrectly

• Tunnel routing to the wrong port

• Trying to access Vaultwarden over HTTP

• Missing or incorrect volume paths

Checking logs usually points you in the right direction.

What’s Next

I will create another post soon about generating the keys needed to securely enable the Admin page. I also plan to cover backups, token rotation, and a few other Vaultwarden best practices.

If you are self-hosting other tools on your Pi, Cloudflare Tunnels can simplify your entire setup. This approach has been reliable for me, and I hope this guide helps you get your own instance running smoothly.

Recently, I discovered Nocodb while searching for alternatives to AirTable. I needed a solution for a work-related problem and initially created a database on AirTable. However, I was hesitant to pay for it when a great open-source alternative might be available. Nocodb emerged as a top choice, leading me to transition away from AirTable. I soon realized that Nocodb could also be useful for a personal project, which I will guide you through here.

Setup

I used Docker on my Raspberry Pi 5 to install it with SQLite.

docker run -d --name nocodb \
-v "$(pwd)"/nocodb:/usr/app/data/ \
-p 8080:8080 \
nocodb/nocodb:latest

After successful installation, I ran the command docker start nocodb to get access to the database. I used the <pi-ip-address:8080>, created a master username and password, and then created the initial tables and schema. The Initial setup was straightforward.

After about a day of playing with the database on my local network, I quickly realized that I might need to access this outside my network. What if I’m on the road and want to add something to my database? Or, what if I wanted to invite someone else to add stuff to my database?

Remote access

I had a few options: port forwarding, VPN, hosting on the cloud, or Cloudflare Tunnel. I didn’t want to do port forwarding for a few reasons. For one, I’m not keen on exposing ports on my home network; it seems like a bad idea (though I may be wrong here). VPN wasn’t an option either, as it was cost-prohibitive. My goal for this setup was to keep things free if possible, and I wanted to host everything on my Raspberry Pi myself. That left Cloudflare Tunnel.

Configuring Cloudflare Tunnel was surprisingly straightforward with the help of ChatGPT and online guides. I’m already a big fan of Cloudflare, and since my dev domain is hosted there, integrating the tunnel was even easier.

Setting Up Cloudflare Tunnel

I installed the cloudflared daemon on my Raspberry Pi, then authenticated it with my Cloudflare account using:

cloudflared tunnel login

After creating the tunnel and configuring it to forward traffic to NocoDB’s local port (8080), I set up a DNS CNAME record on Cloudflare to point my subdomain to the tunnel endpoint.

This allowed me to securely access NocoDB remotely via HTTPS without exposing ports on my home network. On top of that, I configured the Raspberry Pi firewall ufw to only allow SSH traffic, blocking everything else. Inside NocoDB, I created user accounts with appropriate roles to restrict access as needed.

Integrating Cloudflare R2 for File Storage

I wanted to offload file uploads (images, documents) from my Pi to scalable cloud storage. Cloudflare R2’s S3-compatible API made it a natural fit.

I configured NocoDB’s Docker container with environment variables pointing to my R2 bucket:

-e S3_ACCESS_KEY_ID=<your-access-key-id> \
-e S3_SECRET_ACCESS_KEY=<your-secret-access-key> \
-e S3_ENDPOINT=https://<account-id>.r2.cloudflarestorage.com \
-e S3_BUCKET=<your-bucket-name> \
-e S3_REGION=auto \
-e S3_FORCE_PATH_STYLE=true

Uploads now go directly to R2, keeping my Pi’s storage free and scalable.

Backups and Automation

Before moving file storage to R2, I backed up my local SQLite database and uploaded folders. I used rclone to sync my uploads folder to R2 manually, and then create a simple shell script to automate this process.

Scheduling that script with a cron job on the Pi ensured my uploads stay in sync without manual effort:

0 2 * * * /home/pi/sync-nocodb-uploads.sh >> /home/pi/cron-sync.log 2>&1

Conclusion

If you’re looking for an affordable, flexible way to run your own database accessible anywhere, give NocoDB on a Raspberry Pi with Cloudflare Tunnel and R2 a shot!