If you work in research or anything that involves heavy compute, you’ve probably landed in this situation: your daily driver is a MacBook (great keyboard, great display, great battery), but your workloads need a beefy desktop with a GPU, more RAM, or specific OS-level tooling.

My setup is a MacBook Pro for everyday development and a Windows desktop running WSL2 with Ubuntu. Until recently I did most things on the Mac — including running experiments in Docker. That changed when I started working on a security research benchmark: one of the dynamic analysis tools had a compatibility issue with Docker on macOS and simply wouldn’t run. I had to move the experiment execution stage to WSL2. Once I did, I also realized the desktop’s extra CPU and RAM cut experiment runtimes significantly, so it made sense to keep it that way.

I already use Tailscale across all my devices and keep all my SSH keys in 1Password — so the question was less “what tools do I need” and more “how do I wire what I already have into a pipeline where I never have to touch the Windows desktop.” Everything should happen through the terminal on the Mac.

The catch? WSL2 gets a new internal IP every time Windows reboots. And without a bit of plumbing, you end up manually hunting for IPs and re-running commands every few weeks.

Here’s how I wired it all together.

Architecture overview

Before diving into the details, here’s how all the pieces fit together:

Each piece solves one specific annoyance: Tailscale gives stable IPs; 1Password removes key management; The port-forwarding script handles the WSL2 dynamic IP; tmux keeps experiments alive when SSH drops.

Next, let’s walk through each.

Exposing WSL2 after every reboot

WSL2 runs inside a lightweight VM, which means it gets a fresh internal IP address (in the 172.x.x.x range) every time Windows reboots. This breaks any hardcoded SSH config pointing at WSL2.

The fix is a small PowerShell script that runs on Windows startup. It discovers the current WSL2 IP, tears down any stale port forwarding rules, and sets up a fresh forward from Windows port 2222 to WSL2 port 22.

The PowerShell script

# wsl2-port-forward.ps1
# Get the current WSL2 IP
$wslIp = (wsl hostname -I).Trim().Split(" ")[0]

# Remove stale rules
netsh interface portproxy reset

# Forward port 2222 on all Windows interfaces to WSL2:22
netsh interface portproxy add v4tov4 `
  listenport=2222 listenaddress=0.0.0.0 `
  connectport=22 connectaddress=$wslIp

# Allow through Windows Firewall (run once)
# New-NetFirewallRule -DisplayName "WSL2 SSH" `
#   -Direction Inbound -LocalPort 2222 -Protocol TCP -Action Allow

Write-Host "Forwarding 0.0.0.0:2222 -> ${wslIp}:22"

Automate it with Task Scheduler

Create a scheduled task that triggers “At log on” (or “At startup”) running this script with elevated privileges. After that, every reboot is handled automatically — no manual IP hunting.

Why port 2222? Using a non-standard port avoids conflicts if Windows itself is running an SSH server on port 22. It also makes it immediately clear in your SSH config which connections are going to WSL2 versus a native host.

Tailscale: stable IPs without thinking

I’ve been running Tailscale on all my devices for a while now, it’s one of those tools that disappears into the background once set up. It creates a WireGuard-based mesh VPN where each device gets a stable 100.x.x.x address that works from anywhere. No port forwarding on your router, no dynamic DNS.

For this pipeline, Tailscale only needs to be on two things:

1. macOS — via the Mac App Store or brew install tailscale
2. Windows — via the Tailscale Windows installer

Since we already have port forwarding from Windows port 2222 to WSL2 port 22, there’s no need to install Tailscale inside WSL2. The Mac connects to the Windows host’s Tailscale IP, and the port forward takes care of the rest.

SSH config on the Mac

With Tailscale and 1Password SSH agent both running, the Mac-side ~/.ssh/config looks like this:

# ~/.ssh/config
# Use 1Password SSH agent for all hosts
Host *
  IdentityAgent ~/.1password/agent.sock
  Include ~/.ssh/1Password/config
  IdentitiesOnly yes

# WSL2 via Windows host's Tailscale IP
Host wsl
  HostName 100.x.x.x            # Windows host's Tailscale IP
  User your-username
  Port 2222
  IdentityFile ~/.ssh/keys/your-key.pub

Now ssh wsl from anywhere lands you in your Ubuntu session — the IP never changes, so this config survives reboots indefinitely.

1Password SSH agent: keys without key files

I switched to 1Password’s SSH agent a while back and haven’t looked at a raw key file since. All my SSH keys live in my 1Password vault — encrypted, synced, and never written to disk. The 1Password app on macOS exposes an agent socket that any SSH client can use, with biometric (Touch ID) approval for each connection.

How it fits into this pipeline

1. Keys live in 1Password. Generate or import your SSH keys directly in the 1Password app. No ~/.ssh/id_* files on disk.
2. macOS uses the 1Password agent. The IdentityAgent and IdentityFile lines in the SSH config (shown above) tell SSH to ask 1Password for the key. When you ssh wsl, Touch ID fires, and you’re in.
3. Agent forwarding passes the key to WSL2. With agent forwarding, your 1Password-managed key is available inside the WSL2 session too. You can git pull from private repos or rsync back to the Mac — all authenticated through the forwarded agent.

In 1Password settings, make sure the SSH agent is enabled under Developer → SSH Agent. The agent will serve any key in your vault that has the “Use for SSH” toggle turned on.

Security benefit. Your private keys never exist as files on disk — on any machine. They’re encrypted in 1Password’s vault, decrypted only in memory when you approve a request. If your WSL2 instance or Mac is compromised, there’s no ~/.ssh/ directory to exfiltrate.

The Windows side: bridging 1Password into WSL2

1Password runs on Windows too, but WSL2 is a separate Linux VM — the agent’s named pipe doesn’t exist inside WSL2. The bridge is npiperelay combined with socat: a small relay that exposes the Windows 1Password agent as a Unix socket inside WSL2. When you git push from a local WSL2 terminal, the request travels through the relay to 1Password, the GUI pops up, you approve with Windows Hello, and the key is served.

This works great — until you SSH into WSL2 from the Mac. There’s no desktop session, no GUI, no way for 1Password to show its popup. The bridge just hangs.

The fix is a conditional block in ~/.zshrc that detects how you entered WSL2:

if [[ -n "$SSH_CONNECTION" ]]; then
    # Remote session — use a dedicated headless key
    ln -sf ~/.ssh/config.headless ~/.ssh/config
    eval $(keychain --eval --quiet ~/.ssh/id_ed25519_headless 2>/dev/null)
else
    # Local desktop — bridge to 1Password agent
    ln -sf ~/.ssh/config.local ~/.ssh/config
    export SSH_AUTH_SOCK="$HOME/.ssh/agent.sock"
    [[ $- == *i* ]] && setsid socat \
        UNIX-LISTEN:"$SSH_AUTH_SOCK",mode=600,unlink-early,fork \
        EXEC:"/mnt/c/Windows/System32/npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork \
        >/dev/null 2>&1 &
fi

It also symlinks the right SSH config: the local version lets 1Password handle key selection; the headless version pins a dedicated key with IdentitiesOnly yes for GitHub and the Mac. The headless key (id_ed25519_headless) is the one key that lives on disk — it’s added to authorized_keys on the Mac and to GitHub, and only gets used when the GUI isn’t available.

The result: at the desktop you get the full biometric popup; from the Mac you get seamless headless auth.

Persistent sessions with tmux

Long-running experiments will outlive your SSH connection. Wi-Fi drops, laptops sleep, and VPN tunnels time out. Without a persistent session, your process dies when the connection does.

tmux is the standard solution. Start a named tmux session on WSL2, run your experiment inside it, and detach freely. Reconnect whenever you want.

# On WSL2: start a named session
tmux new -s experiment

# Run your workload inside the session
python run_experiment.py --config my_config.toml

# Detach: Ctrl+B then D
# Reconnect later:
tmux attach -t experiment

I name sessions after the experiment or task, so tmux ls gives me a quick dashboard of what’s running.

What this looks like in practice

In my recent research project, my typical flow is: develop and iterate on the Mac, then SSH into WSL2 to kick off the real run. Here’s a concrete example — starting from the Mac terminal:

# 1. SSH into WSL2
ssh wsl

# 2. Pull the latest code
cd ~/projects/my-project
git pull

# 3. Start a named tmux session and run the experiment
tmux new -s baseline-run
python src/run_experiment.py --config configs/baseline.toml

Detach with Ctrl-b d, close the laptop, go get coffee or sleep. Later:

# Reconnect from anywhere
ssh wsl
tmux attach -t baseline-run

The Mac is the control plane — I write code, tweak configs, run quick smoke tests locally. The moment I need real compute (GPU, large dataset, Docker), I ssh wsl and run it there. The Windows desktop itself never needs to be touched.

Syncing results back to macOS

Once an experiment finishes on WSL2, I want the results on my Mac for analysis. A simple rsync handles this:

# From WSL2, sync a specific run back to the Mac
rsync -avz --progress \
  ~/projects/my-project/runs/baseline/2026-04-05_14-30/ \
  mac:~/projects/my-project/runs/baseline/2026-04-05_14-30/

The mac host alias works because the Mac is also on the Tailnet with a stable IP, and WSL2’s agent-forwarded SSH key authenticates the connection. No passwords, no key files.

For repeated use, I wrap this in a small shell script that takes an experiment name and a run timestamp, resolves the paths, and handles edge cases like partial transfers or syncing evaluation results alongside the raw run output. Something like:

# A wrapper script that syncs run + eval directories
bash scripts/sync_run_to_mac.sh baseline 2026-04-05_14-30

# Preview what would be synced without actually transferring
bash scripts/sync_run_to_mac.sh --dry-run baseline 2026-04-05_14-30

Keep large runs out of git. Experiment outputs can be gigabytes of logs, checkpoints, and evaluation artifacts. Add your runs directory to .gitignore and treat rsync as the transport layer. Commit only code, configs, and lightweight analysis.

Bonus: quality-of-life extras

Auto-start SSH server in WSL2

WSL2 doesn’t start sshd automatically. Add this to your WSL2’s /etc/wsl.conf (WSL2 in Windows 11 supports [boot] commands):

# /etc/wsl.conf
[boot]
command = service ssh start

Now sshd starts every time WSL2 boots, no manual intervention needed.

Git commit signing with 1Password

Since your SSH keys are already in 1Password, you can use the same setup for signing git commits. 1Password can automatically configure your local ~/.gitconfig with the right signing key. Every commit is signed, verified on GitHub, and the key never touches disk.

Monitoring from the Mac

For long-running jobs, I sometimes want to glance at GPU usage or system load without SSHing in. A lightweight solution is to run a small status script on WSL2 that periodically writes a JSON summary, then pull it with a cron job on the Mac.

Wrapping up

None of the individual pieces here are novel — Tailscale, 1Password, tmux, rsync are all tools I was already using. The value is in wiring them together into a pipeline where the daily workflow is just:

1. Write code and configs on the Mac
2. ssh wsl — land in Ubuntu on the desktop
3. git pull, start a tmux session, run the experiment
4. Detach, close the laptop, come back later
5. Sync results back, analyze locally

The Mac is always the control plane. The Windows box never needs its monitor turned on.

In 2026, local development commonly involves multiple API providers and multiple identities. It is normal to switch between work, personal, and research contexts within the same machine and even the same terminal session.

Despite this, API key management during local development is still largely informal. .env files are copied around, shell environments silently accumulate secrets, and key rotation is postponed because it is operationally painful.

The core problem is not “where to store API keys”. Most developers already know the answer is “a password manager or secret manager”. The real problems are subtler.

These issues create friction and, more importantly, increase the risk of accidental leaks. The idea of separating config from code traces back to The Twelve-Factor App, which popularized environment variables over config files. That was a meaningful step forward — but it led to .env files storing credentials in plaintext, protected by nothing more than a .gitignore entry.

What we need is not just secure storage, but explicit lifecycle control.

This post documents a workflow I use daily to manage API keys locally in a way that is explicit, low-leakage, and scalable. The focus is not on tools themselves, but on how to integrate them into a coherent engineering design.

Design principles

Before choosing tools, I defined a few constraints:

• Secrets should have a single source of truth. No duplication, no secondary copies.
• Secrets should not live longer than necessary. A key used for one command should not survive in the shell afterwards.
• Projects should be isolated by default. Entering a directory should not implicitly grant access to unrelated credentials.
• The workflow must remain ergonomic. Security that disrupts daily work will eventually be bypassed.

These principles guided all design decisions below.

High-level architecture

At a high level, the system separates responsibility into three layers:

Long story short:

1Password owns the secrets. The distribution layer provides multiple mechanisms to surface them — FIFO-mounted .env files, the CLI, or native SDKs. Different consumption patterns then control when and how long those secrets are available.

There are three supported usage patterns. Keeping them distinct is intentional.

Pattern 1: Project-scoped mount (primary workflow)

This pattern answers the question: “Which credentials does this project use?”

A 1Password Environment (e.g. Dev-Work) is mounted directly to the project root as ./.env. Under the hood, 1Password creates a UNIX named pipe (FIFO) — not a regular file. Your existing dotenv libraries read it transparently, but no plaintext secrets ever land on disk. The mounted file remains available as long as 1Password is running and locks automatically when 1Password locks.

How the FIFO works. When your app reads the .env path, 1Password intercepts the read via the named pipe and streams the secret values directly to the process through a UNIX pipe. The data passes through memory only. Because the mount is not a regular file, it won’t be staged, committed, or pushed by Git — even without a .gitignore entry.

Step 1: Create and mount an Environment

In the 1Password desktop app, navigate to Developer → View Environments. Create environments such as Dev-Work and Dev-Personal, keeping variable names identical across environments.

Under the Destinations tab, select Configure destination for “Local .env file”, then choose the project root as the mount path:

project/.env

You can import an existing .env file directly, or add key-value pairs manually. 1Password will begin serving the FIFO immediately.

Git housekeeping. If you already have a plaintext .env tracked by Git at that path, delete it and commit the removal before mounting. Otherwise git status may report the FIFO as a changed file. The contents can never actually be staged, so your secrets remain safe — but the noise is annoying.

Step 2: Install and enable direnv

direnv is optional but strongly recommended. It manages shell-level visibility: enter a directory and variables appear; leave and they disappear.

brew install direnv
echo 'eval "$(direnv hook zsh)"' >> ~/.zshrc
source ~/.zshrc

Step 3: Define a global loader for .env

Create a helper that tells direnv how to load project secrets:

mkdir -p ~/.config/direnv/lib

cat > ~/.config/direnv/lib/1password_env.sh <<'SH'
use_1password_env() {
  # Ensure dotenv is available
  type -t dotenv >/dev/null 2>&1 || {
    log_error "direnv stdlib 'dotenv' not available"
    return 1
  }

  # Load project .env (FIFO or regular file)
  if [ -e .env ]; then
    dotenv .env
  else
    log_status "no .env found in this directory"
  fi

  # Optional local overrides (non-secret config)
  type -t dotenv_if_exists >/dev/null 2>&1 && dotenv_if_exists .env.local
}
SH

This helper never stores secrets. It only consumes .env if it exists.

Step 4: Project root .envrc

In the project root:

# .envrc
use 1password_env

Then allow it once:

direnv allow

From now on, entering the project directory automatically injects the secrets; leaving it removes them.

Subdirectories and runtime environments

In real projects, subdirectories often need their own .envrc — for example to activate a conda environment. Because direnv executes only the nearest .envrc, inheritance must be explicit:

# sub-project/.envrc
source_up
source ~/miniforge3/etc/profile.d/conda.sh
conda activate "$(pwd)/.conda"

This ensures secrets loaded at the project root remain available while runtime configuration stays local.

Pattern 2: Command-scoped injection (one-off usage)

This pattern answers a different question: “I just want to run this command once with specific credentials.”

Sometimes there is no project context. You just want to test an API, run a script, or make a quick request. For this case, inject secrets for a single command using op run. Secrets exist only for the lifetime of that process.

Using op run with Environment IDs

Since February 2026, op run supports loading variables directly from a 1Password Environment using the --environment flag. This is cleaner than maintaining separate FIFO mount files for ad-hoc use:

# Find your Environment ID in 1Password:
# Developer → View Environments → Manage environment → Copy environment ID

op run --environment env_1234567890abcdef -- curl -s https://api.openai.com/v1/models

Stdout masking. By default, op run monitors stdout and stderr and automatically conceals any secret values that appear in output. If you need to see the actual values (e.g. for debugging), pass the --no-masking flag. In production scripts, leave masking on.

Using central FIFO mounts (alternative)

If you prefer not to pass Environment IDs, you can maintain central FIFO mounts and reference them by path:

~/.envs/dev-work.env
~/.envs/dev-personal.env

Then inject via:

op run --env-file ~/.envs/dev-work.env -- <command>

Convenience wrapper

For daily use, a small shell function keeps things fast:

# ~/.zshrc
dev-env() {
  local which="$1"; shift
  local env_id

  case "$which" in
    work)     env_id="env_work_1234567890" ;;
    personal) env_id="env_personal_abcdef01" ;;
    *)
      echo "usage: dev-env {work|personal} <command...>"
      return 1
      ;;
  esac

  op run --environment "$env_id" -- zsh -l -c "$@"
}

Usage:

dev-env work 'curl -s https://api.openai.com/v1/models'

Secrets exist only for the lifetime of that command and never pollute the shell.

Pattern 3: Programmatic SDK access

For applications that need secrets at runtime — not just in shell environments — 1Password now offers native SDKs in Go, Python, and JavaScript. This is particularly useful for scripts, internal tools, or CI pipelines that need to fetch credentials on demand.

Reading an Environment with the CLI

The op environment read command returns all variables from an Environment as key-value pairs:

# Read all variables from an Environment
op environment read env_1234567890abcdef

# Pipe to other tools
op environment read env_1234567890abcdef | grep API_KEY

Reading an Environment with the Python SDK

from onepassword import Client

client = Client.authenticate(
    integration_name="my-script",
    integration_version="0.1.0"
)

# Fetch all variables from a 1Password Environment
env_id = "env_1234567890abcdef"
response = client.environments.get_variables(env_id)

for var in response.variables:
    print(f"{var.name}={'*****' if var.hidden else var.value}")

Local authentication. The SDK can authenticate through the 1Password desktop app using biometrics or your account password. No service account tokens needed for local development. This is a human-in-the-loop approval model — 1Password prompts you for consent, then the SDK receives a scoped session.

When to use which pattern

Why direnv is optional but powerful

Nothing in this design requires direnv. Projects can read .env directly, command-scoped injection works independently, and the SDK pattern bypasses the shell entirely.

However, direnv dramatically improves the developer experience by managing shell-level visibility:

• Enter directory → variables appear.
• Leave directory → variables disappear.

This keeps the shell clean while remaining convenient.

The important point is that direnv is a lifecycle helper, not a secret manager. It never stores secrets; it only executes logic. The .envrc file itself can be safely committed to version control because it contains no secrets — only the instruction to load .env.

Known limitations & caveats

The 1Password Environments feature is still in beta, and there are some sharp edges worth knowing about.

Concurrency

FIFO-mounted .env files are not designed for concurrent access. If multiple processes try to read the FIFO simultaneously — for example, an IDE and a terminal session — only the first reader succeeds. Others may hang or return empty data.

Practical impact. If you have your .env open in an IDE (some will auto-read it for IntelliSense), other applications may fail to read the same file. Close the IDE’s file handle or use op run --environment as a workaround for the second consumer.

Platform support, limits, and desktop app dependency

Local .env file mounts are currently supported on Mac and Linux only. Windows support is being explored but is not yet available; on Windows, use op run --environment or the SDK instead. On all platforms, you can have up to 10 enabled local .env file mounts per device. For most workflows this is sufficient, but if you manage many microservices locally, you may need to combine some Environments or lean on the CLI/SDK patterns. All of this also depends on the 1Password desktop app being running and unlocked — these mechanisms are strictly developer workstation features, not something to run on servers or headless CI. For CI/CD, use 1Password Service Accounts instead.

AI agent integration

If you use AI-assisted IDEs like Cursor or GitHub Copilot, 1Password provides an agent hook that validates your FIFO mounts before the agent executes shell commands. You can configure which files to validate using a .1password/environments.toml file at the project root:

# .1password/environments.toml
mount_paths = [".env"]

The hook prevents command execution if any required .env FIFO is missing or disabled, which keeps the agent from running against misconfigured environments.

Final notes

Once this workflow is in place, the benefits compound quickly. Key rotation becomes straightforward: rotate in 1Password, and consumers pick it up on the next read, with no find-and-replace across scattered files. Environment switching is explicit and reversible, whether you remount a different Environment for a project or change the Environment ID in a wrapper command. Just as importantly, secrets avoid the common leak paths: FIFO mounts do not write plaintext to disk, op run helps conceal secret values in command output, and direnv removes variables when you leave a project directory.

The operational impact is bigger than just security posture. Onboarding gets simpler because you share Environment access instead of sending .env files around, and auditing improves because access logs exist by default. Over time, the mental overhead drops: you stop “remembering where keys are” and start relying on a system with explicit lifetimes.

At a design level, this is the main takeaway: treat local secret handling as an engineering system, not a collection of ad-hoc habits. The specific tools can change, but the principles hold — one source of truth, scoped injection, and clear lifecycle control. If you already use 1Password Environments, this workflow aligns with the feature’s strengths; if you do not, the same pattern still applies to other secret managers.

说起来，我采用「RSS信息源 + 一款心仪的多平台阅读器」这样的方式获取信息已经有一年多的时间了。总的来说，它带给了我很不错体验，有效的缓解了我在Daily Input过程中的一些无奈与焦虑：一方面，它使筛选过的优质信息源尽量常驻，另一方面，它使阅读信息的过程尽量纯粹。

其实，RSS背后是由一套挺反商业的逻辑在支持，也因此，很多平台和媒体都并不提供官方的RSS订阅链接，毕竟如果每个人都在自己的一隅空间内，不去访问门户网站页面，那么用户的数据偏好从哪里得到？铺天盖地的广告往哪里投送？

这样的协议无疑站在了消费主义的对立面。所以，刚才提到的一切想法得以实现的一个理论基底，就是RSSHub这个伟大的开源项目的存在。关于RSSHub，官方docs中作了如下介绍:

RSSHub 是一个开源、简单易用、易于扩展的 RSS 生成器，可以给任何奇奇怪怪的内容生成 RSS 订阅源。RSSHub 借助于开源社区的力量快速发展中，目前已适配数百家网站的上千项内容

一言以蔽之，很多并没有提供RSS功能的平台与媒体，通过RSSHub的Route(路由)，或者更简单的，利用其Radar插件，可以很方便的生成订阅源。

更多关于RSS以及RSSHub的介绍就不在这里展开了，下面切入正题：

无尽的折腾

1. 需求

这次折腾之旅的起因是这样的：我经常阅读的一个RSS订阅源-端传媒，由于网站的改版与代码重构，原本的源不能获取到文章的全部内容了，需要跳转到原链接去阅读。而网站上的文章文字显示为繁体，且字体看起来不顺眼不说，文章周围还夹杂着很多乱七八糟的内容，很是无奈。

花着高昂的订阅费，却得不到称心如意的阅读体验，这还得了(也不得不感叹这些对于体验的改造工作居然要消费者来承担)？于是遂至RSSHub docs的相关路由路径下查看，发现如下字样：

付费内容全文可能需要登陆获取，详情见部署页面的配置模块。

也是我第一次了解到原来RSSHub的一整套服务还可以自己部署，至于自建的原因，我是这样理解的：

1. 由RSSHub的官方域名路径构成的源多数都因被污染、被反制、被滥用等等原由而无法使用。
2. 随着很多网站的政策更新，获取其内容所需要的条件越来越苛刻，像是API、Cookies、Token等信息需要预配置。

好在RSSHub的生态还算完整，对于自建这样一个相对小众的需求也有比较详细（当然还不够！不然我也不写这篇blog了）的文档支持。

折腾开始！

2. 基本部署

官方提供的Guideline中有很多种部署方式，我尝试了三种：Docker-Compose部署、HeroKu部署、Vercel部署。最后顺利完成自建是使用的Vercel。

• Docker-compose

9月5日，我开始了第一次尝试。

由于我这一阵子刚刚学完Mosh的Ultimate Docker Course，而古人云：一个人刚刚掌握了一项新的工具后，当他发现能将它立马用到解决自己遇到的实际问题，这无疑是一件很令人激动的事情。于是当我看到支持中有Docker字样的instance时，眼睛放出的光芒四射，我毫不犹豫的优先选择了它。

部署的过程不算困难，只需要在Terminal中零星敲上几个指令，就能在本地端口1200下看到“Welcome to RSSHub”的字样，还蛮顺利的。

运行docker的相关命令，发现：images成功运行在本地，volumes也没有忘记创建，（嗯，我Docker学的没问题！）但是不知道是不是部署在本地的原因，真正将自建的服务用到订阅源的构建时，基本全是报错。只有少数的一些静态page或是比较简单的网页能够成功的解析。碍于我在网络方面的知识储备相当匮乏，在持续扑腾了两个小时以后，我还是像一只沮丧的旱鸭子一样放弃了，并不甘心的在我的LogSeq的Daily Journal中作了如下记录：

• HeroKu

时间来到了9月7日，这天我也是经历了挺疯狂的一晚。

我千方百计的想要疯狂榨干Github Student Package中的每一滴价值，从下午三点开始把自己埋在电脑前一直到了凌晨三点：从零开始完成了两个Vps的部署（这个有机会也可以另起一篇记录下），申请并注册了个人的第二个domain，学习了使用Termius、浏览了上百个webpage……

我将在自己身上时有发生的这种好像进入了某种Zone的状态戏称为“Geeky Time”，也算是另一种比较nerd的“Kenja Taimu”吧。

哈哈哈，好像跑题了。

话说回来，在Student Package中，我瞥见了Heroku的字样，它也是RSSHub官方支持的一种自建方式，且支持一键部署，但无奈其不提供免费服务，每月的额度也十分有限。这不是和我的学生包中提供的条目完美匹配吗？于是我尝试了注册Heroku，但是倒在了最后一步：没能添加正确的Payment methods，也真是挺奇怪的，我的这张Monai卡陪我注册和订阅过大大小小很多个境外服务，怎么到你这就不行了，无奈作罢。

后来分析了下，可能Heroku需要的是国外的本地卡作为支付方式吧，而不是我这样一张简单的Mastercard外币卡。

• Vercel

最后是Vercel，俗话说好饭不怕晚。其实早在部署我的blog时，我就有体验过Vercel的托管服务，但因为一些原因（一切从简与轻量化）还是选择了Github Pages。基于Vercel的部署过程体验下来还算简单，RSSHub的官方Docs中提供了和Heroku一样的一键部署功能，但这里我还是选择了（也更推荐）带有自动更新的部署方式：

1. 在Github中：将RSSHubFork到自己的repo中。
2. 在Vercel中：
   1. 完成对Github Account的绑定。
   2. 新建Project，关联Github中的对应repo并导入。
   3. 按需自定义修改相关设置，等待Build完成

更详细的部署教程（step by step）可以参考这篇Guide：RssHub + Vercel ：在 Vercel 上免费部署你的RssHub。

至此，专属于我自己的RSSHub就已经部署在了Vercel为我提供的Domain下，点击visit即可看到Welcome Page。

Bingo！

3. 自定义配置

但是到此我只实现了刚才提到的“为什么要自建”的第一个理由，我获得了一个没有那么多人同时使用的相对私人的带有RSSHub功能的域名服务，可以把相关路由都迁移过来，生成对应的大部分订阅源。但我还是没有办法获取那些需要特定登陆信息才能完成信息提取的网站，像是Youtube、Bilibili、Pixiv、Instagram等等，当然也包括我的issue：端传媒。

• 配置Environment variables

参考RSSHub的docs和code，我得知我需要为路由指定那些所需的特殊values。基于我选择的托管服务Vercel，这里可以采取两种方法：

1. 在Github的repo中的根目录下新建一个 .env 文件，每行以 NAME=VALUE 格式添加环境变量，例如：

   CACHE_TYPE=redis
   CACHE_EXPIRE=600
   

2. 在Vercel的Dashboard中，点击settings，在左侧栏目中选择Enviroment variables，填入对应的Keys和Values并Save。

这里我选择的是第二种方法。另外值得注意的是，在每次添加新的或是修改现有的Variables后，都要Redeploy该Project才能使这些参数得以在路由中生效。

• 配置Custom Domains

如果你觉得Vercel给你分配的域名不太顺眼（且这个xxx.vercel.app好像是被默认墙的），那么你可以将它部署到自己的域名中。上文提到我手里正好有一个闲置的域名（也是从Github Student Package中薅的羊毛 ^o^，来自Name.com的免费一年的.live域名），于是就将Vercel的服务redirect到了我的这个域名上。相关操作非常简单，按部就班follow好vercel上的引导即可：

1. 添加域名
2. 在域名的DNS解析服务商（我的是Cloudflare）处添加相应的DNS记录
3. 等待redirect成功

4. 成果

至此，已经实现了Self-Host的全部步骤，此时，可以在RSSHub中的官方路由随意挑选几个，将其中域名 https://rsshub.app 的部分替换为我刚才成功自部署的域名，添加到阅读器中看看是否可以正常使用。如果你也同样和我一样使用RSSHub Radar的话，别忘了在设置中修改自定义RSSHub域名，像是这样：

回到我心爱的阅读器Reeder中验证一下，在新的订阅源中，看看端传媒的文章能否完整输出呢？

可以看到，上面的GIF中，我先点击的是自建域名下生成的新订阅中的文章（全文），后点击的是老的订阅源中的文章（部分）

Perfect！

结语

这篇blog算是对又一次的折腾之旅的一次小记录，并不能称之为一篇正经的教程，所以更多的记录的是我的一些思辨过程，写一些我想写的而不是简单的step by step的tracking。

最近这段时间日子过的比较清闲，在做出了可能是人生中的又一个Big Decision后，短暂结束了自己的迷茫与百无聊赖，折腾的频率就也又上来了。

今天难得心血来潮，洋洋洒洒写成此篇，就借此以最美好的祝愿许给RSS（Really Simple Syndication）这一古老朴素而余温无限的协议和其繁盛的生态以最高的敬意吧！