Beelink → WholeTech Network

01 What's running where (current state)

There are two physical pieces and one cloud piece:

02 How a typical change flows (the loop)

When you ask Claude to do something like "build a new site" or "lock down the family pages," here's the actual mechanical sequence:

1. You type a request to Claude Code on the Beelink.
2. Claude writes or edits a Python file locally in C:\Users\walhus\websites\wholetech.com\ (e.g. build-askemai.py).
3. Claude runs scp over SSH to copy that file from the Beelink to the droplet:

   scp build-askemai.py root@143.198.182.180:/tmp/

4. Claude runs ssh + python remotely to execute the script:

   ssh root@143.198.182.180 "python3 /tmp/build-askemai.py"

   The script writes new HTML files into /var/www/<site>/ on the droplet.
5. nginx is already running and immediately serves the new files to visitors with no restart needed (for static HTML changes).
6. For backend service changes (askemai, today-stats, wholetech-rss, wholetech-chat), Claude runs systemctl restart <service> after editing the Python source.
7. Claude verifies with curl from inside the same SSH session — checks HTTP status codes, sample content, log lines.
8. Claude reports back to you in chat with what changed.

The Beelink never serves traffic itself. It only originates commands. The droplet does all the public-facing work.

03 Why this design is good

• The droplet survives the Beelink being off. You can shut down the home box, take it on a plane, lose power for a week — the public sites stay up because the Linux server in the cloud doesn't need you.
• The Beelink doesn't need a public IP, port forwarding, or a static address. It only ever initiates outbound SSH connections to the droplet. Your home network can be behind any firewall, any ISP, any router — it doesn't matter.
• All cron jobs and systemd services run on the droplet, not the Beelink. Daily backups (4:30 AM), AdSense dashboard regeneration (4:10 AM), today-stats updates, cert renewals — all on the droplet. Nothing runs on the Beelink on a schedule.
• You can move the Beelink anywhere with internet and it just works the same. Different city, different time zone, hotel WiFi — same SSH key, same scripts, same droplet, same result.
• Claude Code's local working directory is the source of truth for build scripts, while the droplet is the source of truth for live content. Two distinct concerns, two distinct boxes.

04 What's installed on the Hot Springs Beelink

Replicating this on Beelink #2 in Cedar Creek, TX means installing this same stack:

Required software

Required configuration

05 Step-by-step replication on the Cedar Creek Beelink

Do this once when you arrive in Cedar Creek, TX with the new box.

Day 1 — get the Beelink talking to the droplet

1. Boot the new Beelink. Update Windows. Install Chrome or Edge.
2. Install Git for Windows from git-scm.com. Accept the defaults. This gives you bash, ssh, scp, and ssh-keygen.
3. Install Node.js LTS from nodejs.org. Default install.
4. Install Python 3.12 from python.org. Check "Add to PATH" during install.
5. Install Claude Code following the instructions at claude.ai/code. Sign in with the same Anthropic account you use on Hot Springs.
6. Generate an SSH key for the Cedar Creek box. Open Git Bash:

   ssh-keygen -t ed25519 -C "beelink-texas"

   Press Enter through the prompts. This creates ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub.
7. Copy the public key to the droplet so Cedar Creek Beelink can SSH in. The simplest way: from the Hot Springs Beelink (which already has access), tell Claude:
   "Add this public key to /root/.ssh/authorized_keys on the droplet: ssh-ed25519 AAAA... beelink-texas"
   Paste the contents of ~/.ssh/id_ed25519.pub from the Cedar Creek box. Hot Springs Claude will append it. Now the Cedar Creek box can SSH in too.
8. Test the SSH connection from Cedar Creek Bash:

   ssh root@143.198.182.180 "echo hello from texas"

   You should see hello from texas. If you get permission denied, the public key wasn't added correctly. Re-do the previous step.

Day 1 evening — mirror the working directory and memory

9. Before leaving Hot Springs, ask Hot Springs Claude to tar up the working dir and memory dir and park them on the droplet:

   tar czf /tmp/wholetech-working-dir.tar.gz -C /c/Users/walhus/websites wholetech.com
   tar czf /tmp/claude-memory.tar.gz -C /c/Users/walhus/.claude/projects/C--Users-walhu-websites memory

10. On Cedar Creek, scp them down and extract:

    scp root@143.198.182.180:/tmp/wholetech-working-dir.tar.gz .
    scp root@143.198.182.180:/tmp/claude-memory.tar.gz .
    tar xzf wholetech-working-dir.tar.gz -C /c/Users/<you>/websites/
    mkdir -p /c/Users/<you>/.claude/projects/C--Users-<you>-websites
    tar xzf claude-memory.tar.gz -C /c/Users/<you>/.claude/projects/C--Users-<you>-websites/

11. Open Claude Code on Cedar Creek and cd into the working dir:

    cd /c/Users/<you>/websites/wholetech.com
    claude

    Test it: ask Claude to read MEMORY.md and tell you about the project. If it answers correctly, you're done. The Cedar Creek box is now functionally identical to Hot Springs.

06 How the two Beelinks communicate (unattended)

The two boxes never talk to each other directly. They communicate through the droplet, which is the always-on intermediary in the cloud.

Pattern A — The droplet as the bulletin board

Anything Hot Springs needs to share with Cedar Creek (or vice versa) gets dropped onto the droplet:

# Hot Springs pushes a note for Cedar Creek
ssh root@143.198.182.180 "echo 'Reminder for Cedar Creek Claude' >> /var/wholetech-shared/notes.md"

# Cedar Creek pulls it later
ssh root@143.198.182.180 "cat /var/wholetech-shared/notes.md"

I recommend creating one dedicated directory on the droplet for cross-machine state:

ssh root@143.198.182.180 "mkdir -p /var/wholetech-shared && chmod 755 /var/wholetech-shared"

Pattern B — A bare git repo on the droplet (recommended)

To keep build scripts in sync without manual scp every time, set up a bare git repository on the droplet:

ssh root@143.198.182.180 "mkdir -p /var/git/wholetech.git && cd /var/git/wholetech.git && git init --bare"

Then on each Beelink:

cd /c/Users/<you>/websites/wholetech.com
git init
git remote add origin root@143.198.182.180:/var/git/wholetech.git
git add -A && git commit -m "snapshot from <wisconsin or texas>"
git push -u origin master

Now either box can git pull to get the latest scripts. Either box can git push to share its work. The droplet hosts the central truth. Whichever Beelink you happen to be sitting at, your build scripts are always current.

Pattern C — The droplet's cron handles all unattended work

Anything that needs to happen unattended (without a human or Claude pressing a button) runs on the droplet, not the Beelinks. The Beelinks can be off, asleep, traveling, or unplugged — the droplet keeps doing its thing.

07 Day-to-day life with two Beelinks

Imagine you're spending part of the year in Hot Springs and part of the year in Cedar Creek, TX. Here's how the workflow looks:

The night before you leave Hot Springs

1. Tell Hot Springs Claude: "I'm flying to Cedar Creek tomorrow. Push my latest working dir and memory to the droplet."
2. Claude tarballs the working directory + memory directory + drops them in /var/wholetech-shared/.
3. Optionally: Claude commits and pushes the build scripts to the bare git repo.

The first morning in Cedar Creek, TX

1. Boot the Cedar Creek Beelink. Open Git Bash. git pull the build scripts (or scp the tarballs).
2. Open Claude Code. The memory directory is already populated, so Claude has full context — it knows about Alice, the family sites, AdSense, askemai.com, the Gmail draft workflow, everything.
3. Pick up exactly where Hot Springs Claude left off.

Mid-day in Cedar Creek, TX, you make a change

1. Edit a build script with Claude.
2. Claude scp's it to the droplet and runs it. Site updates immediately.
3. Optionally: Claude commits and pushes to the bare git repo.

The next time you boot the Hot Springs box

1. git pull to get whatever Cedar Creek changed.
2. For important changes, ask Claude to write a short memory file under memory/ so the next session on either box knows what happened.

08 Critical security note

The SSH private key on each Beelink is the master key to the droplet. Anyone who gets the file ~/.ssh/id_ed25519 can become root on 143.198.182.180. Treat it like a physical house key:

• Don't sync ~/.ssh via cloud storage (Dropbox, OneDrive, etc.).
• Use a passphrase on the key when you generate it, so even if the file is stolen the attacker still needs the passphrase.
• Different key per Beelink. Don't copy the Hot Springs key to Cedar Creek. Generate a fresh key on Cedar Creek and add its public key to /root/.ssh/authorized_keys separately. That way if a box is lost or stolen you can revoke that one key without affecting the other.
• If a Beelink is lost or stolen, SSH in from the surviving box and remove the lost box's public key line from /root/.ssh/authorized_keys immediately.

09 Quick reference card