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 ~/.fameboy 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.

$ ssh root@<ip> fc-node status
catching up: 18.9 h behind, gaining about 4 s per second (~4.7 h to go).

$ ssh root@<ip> fc-node status
  shard 0: 1s behind
  shard 1: 1s behind
  shard 2: 1s behind
in sync. Run command 2 on your own computer.

The first is our demo node right after loading; the second is the same node a few hours later. During setup, fc-node status shows the snapshot's progress instead. On your own computer, fameboy status reports the same numbers.

"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 ~/.fameboy/app, installs three dependencies (@farcaster/core, viem, @scure/bip39), saves your node's address in ~/.fameboy/config.json, and puts fameboy in ~/.local/bin. Node.js runs the TypeScript directly, with no build step.

The browser client

fameboy ui starts a small server on your own computer (127.0.0.1:4747, or the next free port) and opens it in your browser. Your app key stays in that server; the page never sees it. It shows your own account, so it opens on a sign-in page. Approve in the Farcaster app: scan a QR code and approve on your phone, so your seed phrase never leaves it. The request comes from an app account, the account the phone shows as "@name wants to post on your behalf". Set it up once on your server with ssh -t root@<ip> fc-node app-account, and everyone using your node can sign in this way; give each friend an invite code with fc-node invite <name> (sharing your node). Or set one up for this computer alone with fameboy app-account. If it has no username, setup suggests a free @fameboy<color> with a random color, like @fameboyteal, trying another color whenever one is taken; keep it or type your own. Setup also offers a display name, picture and bio for it, so the approval screen looks like an app, not a bare number. Use your seed phrase: the same steps as fameboy login, offered only because the server listens on your computer alone. Sign out in the header deletes the app key from this computer.

Reading from the terminal

Every view above is a handful of plain GETs to your node, so you can repeat any of them with curl:

$ fameboy casts pinkmink -n 3
@pinkmink · 1h · via @pinkmink  0xac0dd681
clear

@pinkmink · 17h · via @pinkmink  0x39d6294b
posting through a fresh create-fc node, three commands later

@pinkmink · 1d · via @pinkmink  0x085bf8a4
hello from my own snapchain read node 👋

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

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 fameboy feed skips anything more than 10 minutes ahead.

Posting

fameboy 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/.fameboy/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

fameboy 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 fameboy labels each cast with its app, and filters on it:

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

$ fameboy feed me --not-app warpcast
$ fameboy 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.

Hosting it for others

Most people won't run a client. Once your node has an app account, ssh root@<ip> fc-node client hosts fameboy on it at a web address named after that account, like https://fameboyteal.<ip with dashes>.sslip.io. Anyone can open it, approve on their phone, and use Farcaster through your node.

Their app key is made in their browser and never leaves it. Every cast, like and follow is signed there, and your server keeps nothing about the people who use it. A copy named @fameboy<color> takes that colour, in four shades like a Game Boy Color screen. The hosting guide covers your own domain, invite-only sign-in, and what people trust you with.