Your own Farcaster.
Three commands.

Before you start: Hetzner

Command 0 uses Hetzner Cloud because it bills by the hour and has a clean CLI. Hetzner has no API for creating projects or tokens, so this part happens in the browser:

1. Sign up at console.hetzner.com. New accounts may need ID or payment verification before they can create servers, which can take a while. Do this first.
2. Create a project, then Security → API tokens → Generate API token with Read & Write access. Hetzner shows it once.
3. Run hcloud context create fc-node and paste the token. It's saved in plain text in ~/.config/hcloud/cli.toml. A project used only for this keeps the token's reach small.

New accounts can only have 1024 GB of volumes in total, and Hetzner won't raise that until the account is older: the Limits page says "Your account is too new to request a limit increase." The official Snapchain installer needs about 2 TB, so we load the database differently (see command 1) and fit in 1000 GB.

Powering a server off doesn't stop the bill. Only deleting it does. This lists what it found, asks you to type fc-node, and deletes the server, volume, firewall and SSH key (34 seconds for us):

curl -fsSL https://raw.githubusercontent.com/eucalyptus-viminalis/create-fc/main/provision/hetzner-delete.sh | bash

The volume holds the database, so the next node re-syncs from scratch. Your app key in ~/.fc-client survives; point the client at the new node by running command 2 again with the new IP.

Command 0: the server

provision/hetzner.sh creates four things, each named so a re-run finds and reuses it: an SSH key, a firewall, a volume, and the server. The volume comes first, so it's attached when the server first boots and formats it at /srv/snapchain.

The firewall opens exactly what a read node needs:

Server types sell out. When Hetzner has no cx43 free in a location, it answers error during placement (resource_unavailable) and creates nothing. We watched cx43 disappear from all three EU locations within a minute, then come back in Nuremberg five minutes later. The script handles it: cx43 in fsn1, nbg1 and hel1, then cpx41 (the same 8 vCPU and 16 GB at about twice the server price) in the same order. It creates the server first and the volume after, in the server's location, because a volume can't move between locations. Pin your choice with TYPE=cx43 or LOCATION=hel1.

If the volume step fails with volumes size limit exceeded (resource_limit_exceeded), your account's volume cap is lower than VOLUME_GB. Check Limits in the console. Other sizes and locations can be set with environment variables: … | TYPE=ccx23 LOCATION=nbg1 bash.

Command 1: the read node

Snapchain is the network that stores Farcaster's messages: every cast, like, follow and profile change. Its official installer, snapchain.sh, runs the node in Docker. node/setup.sh wraps it, starts it as a systemd job so you can disconnect, and changes one thing: how the database gets loaded.

Loading the snapshot

A new node doesn't replay Farcaster from the beginning. It downloads a daily snapshot of each shard (about 397 GB compressed, in ~70 MB pieces) and then fetches the blocks made since. The node's own loader keeps every downloaded piece and an uncompressed copy of each shard until all three are unpacked. We estimate that peaks around 1.5 TB, which is why the docs ask for 2 TB.

fc-load-snapshot streams instead: download a piece, unzip it straight into the database, delete it, repeat. The node only downloads a snapshot when its database folder is empty, so afterwards it boots straight into catching up.

Disk use peaked at 556 GB, the size of the finished database.

Catching up

Our snapshot was 22 hours old by the time it finished loading. The node fetched the missing blocks at about 5 per second per shard and closed the gap by about 4 seconds every second, so it was in sync roughly 5½ hours later. On a second, timed run the snapshot was 19 hours old and the node caught up in 4 hours 25 minutes: 6 h 20 min from command 0 to in sync. The CPU sat 94% idle: the limit is fetching blocks from peers one after another, not the server.

$ fcli status
node http://2.28.135.100:3381 · snapchain 0.14.3
  shard 0  height 48242370  47661s behind
  shard 1  height 48938063  26552s behind
  shard 2  height 48754698  45879s behind
catching up: 13.2h behind. Reads work now, but recent casts may be missing.

That's two hours into catching up. Five hours later every shard read 0–3 s behind. On the server, fc-node status reports the same numbers, and during setup it shows the snapshot's progress instead.

"Behind" is blockDelay from /v1/info: how many seconds each shard's newest block trails the clock. A synced node stays in single digits. In the same response, mempoolSize: 4294967295 is normal on a read node. It means "not reported", not an overflow.

Two things look alarming and aren't. Failed to dial peer … HandshakeTimedOut for a couple of the bootstrap addresses, and a steady trickle of InsufficientPeers ("read-node-peers"). Our node logged both all day and synced fine.

Why not the official one-liner? snapchain-bootstrap.sh reads its prompts from /dev/tty, which doesn't exist over ssh host 'curl … | bash' or in a systemd job. setup.sh answers both prompts in .env ahead of time and runs snapchain.sh upgrade directly.

Command 2: the client

install.sh clones this repo into ~/.fc-client/app, installs three dependencies (@farcaster/core, viem, @scure/bip39), saves your node's address in ~/.fc-client/config.json, and puts fcli in ~/.local/bin. Node.js runs the TypeScript directly, with no build step.

Reading

Every read is a plain GET to your node, so you can repeat any of them with curl:

$ fcli casts pinkmink -n 1
@pinkmink · 2m · via @pinkmink  0x085bf8a4
hello from my own snapchain read node 👋

$ curl "http://<ip>:3381/v1/castsByFid?fid=3355372&reverse=true&pageSize=1"

Snapchain has no "home feed" endpoint. A feed is something a client builds. Ours is the simplest version: ask the node who you follow, fetch the latest casts from each, and merge them by time. That's one request per account you follow. For an account following 1,041 people, the feed took 13.5 seconds from Sydney to our node in Germany, while the same 1,041 requests made on the server itself took 1.7 seconds. Running the client close to the node pays off.

One oddity: a few old casts carry timestamps decades in the future (we found one dated 2061). They would sit at the top of any time-sorted feed forever, so fcli feed skips anything more than 10 minutes ahead.

Posting

fcli login asks for a seed phrase once, uses it to authorize an app key for this client, and then forgets it. Read Seed phrases before you run it. Here's a real run:

seed phrase (hidden): ************ words
  m/44'/60'/0'/0/0  0x97547ffbA3F3e5a7553aA36948F618f39647F2Ea  fid 3355372
storage: 1 unit(s)
app key: 0xaa2778f5b991db794630e34a0e192ce1633c135786ecbadf253406938ebdcf8e
KEY_ADD: 0x23c71047ebe9209753273ca2b33c931989ddad97, nonce 2, ttl 30 days
submitted to your node, which relays it to the validators. Waiting for it to land...
done. App key saved to /Users/sdf/.fc-client/appkey.json (mode 600). Your seed phrase was not saved.

Then the usual verbs. Each one is signed with the app key, sent to your node, and read back from it until it shows up:

@names in a cast become real mentions, --reply user/hash replies, --embed url attaches a link, and --dry-run checks the message with your node without sending it.

A username

fcli username alice claims a name and sets it. It's the one step that uses a service other than your node: the fname server at fnames.farcaster.xyz, run by Farcaster, free, no key. Your custody key signs the claim, the fname server countersigns, the proof reaches the network and then your node, and only then will the node accept a message setting your username.

Filtering by the app that posted

Every cast is signed by an app key, and every app key records which app asked for it. So fcli labels each cast with its app, and filters on it:

$ fcli apps dwr
   1 key   @warpcast (fid 9152)
   1 key   @baseapp.base.eth (fid 309857)
   1 key   @neynar (fid 6131)

$ fcli feed me --not-app warpcast
$ fcli feed me --app fireflyapp --app 9152

In one account's feed of 16,416 recent casts, 89% came through the Farcaster app (fid 9152, still called @warpcast). Excluding it is a quick way to see what everything else looks like.