The Great Migration: Next Steps

With a new server set up, the next step in the great migration was to start moving services to it from the cloud. First up, my toy encrypted secret sharing service!

With the new server set up and configured, the next step was to begin migration my existing cloud services and shutting things down. First up: Project Swordfish, an end-to-end encrypted sharing system I’d debuted on this site back in 2022.

Conveniently, I had already built the project to leverage containerization. This means there wasn’t much to migrate – just set up the new server and begin redirecting traffic.1There was a minor risk of losing any existing secrets stored in the backend during the migration. Given secrets only live for 24 hours, I just had to wait for some downtime in activity before shifting things over. Nothing was lost in the transition.

I’d long ago published the full code of my implementation – both the server components and a basic CLI ingration. The full Docker stack is simple and consists of just two components:

  • A vanilla Redis server for storing encrypted data
  • A PHP web server

The web server itself currently hosts just 5 endpoints:

  • Three static web pages – one for setting secrets, two for retrieving. (One endpoint checks for a secret ID in the request path.)
  • The actual routes for storing data in and retrieving data from Redis

I merely cloned the repository to my new server and started things up with a docker compose up -d. Things were running great locally and everything was right with the world.

Public Access

Actually, not everything was right. No one outside of my private Tailnet could see the server. If I wanted to fully replace a publicly-available service, I had to expose this small Docker environment to the world.

In previous experiments with a Raspberry Pi, I ran an hourly cron job to grab my public facing IP address and write it to a Route53 DNS zone. This was effective, but required two personal security compromises I find untenable:

  1. I had to expose my home network’s IP address to the world
  2. I had to reconfigure my home network to route incoming traffic to a specific machine

Neither of these steps felt right to me, so I looked for an alternative option. Tailscale Funnel felt like exactly what I wanted, except it required me to use a *.ts.net address rather than my custom top-level domain. So I instead settled on Cloudflare Tunnel as my solution.

Running a cloudflared instance on my machine and routing all DNS through Cloudflare’s network allows me to set the swordfish.displace.tech domain to route directly to my home server. My IP address stays private and I don’t have to reconfigure anything about my home network. It also means the public internet can only talk to the specific Docker container I expose on that fixed port rather than my entire machine.

It’s a win-win for me from a security perspective. And it means Project Swordfish remains online and available for public use without my needing to continue to pay for an additional EC2 instance.

One expensive cloud server down; four left to go.

  • 1
    There was a minor risk of losing any existing secrets stored in the backend during the migration. Given secrets only live for 24 hours, I just had to wait for some downtime in activity before shifting things over. Nothing was lost in the transition.