Your own node and client for Farcaster.

1Rent a server

A node keeps a full copy of the network's data. On 18 October 2026 that was 557 GB once loaded, from a snapshot of about 400 GB compressed. Outpost streams the snapshot straight into the database, so it never needs room for both at once, and asks for a 1.2 TB volume to leave room to grow (--disk to change it). It also asks for 32 GB of RAM: there are reports of nodes with 16 GB crashing.

On Hetzner it asks for 1 TB, because new Hetzner accounts can hold at most 1024 GB of volumes. Hetzner is not tested on a real server yet: our real runs used DigitalOcean, and the Hetzner commands have only run against a simulated Hetzner in our tests. We expect a full node to fit in 1 TB but have not measured it there.

./outpost provision --provider do
# or: ./outpost provision --provider hetzner

Here is what it runs, shown with --dry-run (long lines and your home path shortened):

The first three lines give the price. Each line starting with + is one command sent to DigitalOcean.

DigitalOcean: droplet outpost-node (s-8vcpu-32gb-amd) in fra1 with a 1200 GB volume.
Billed by the hour while it exists: the volume about $0.16/h, plus the droplet
(s-8vcpu-32gb-amd is $0.25/h). October 2026 list prices; check yours.
+ doctl compute ssh-key import outpost-node-key --public-key-file /home/you/.ssh/id_ed25519.pub
+ doctl compute volume create outpost-node-data --region fra1 --size 1200GiB --fs-type ext4 --desc outpost\ snapchain\ data
+ doctl compute tag create outpost-node
+ doctl compute firewall create --name outpost-node-fw --tag-names outpost-node --inbound-rules protocol:tcp\,ports:22\,... protocol:udp\,ports:3382\,...
+ doctl compute droplet create outpost-node --region fra1 --size s-8vcpu-32gb-amd --image ubuntu-24-04-x64 --ssh-keys f8:bd:...:0a --user-data-file /tmp/tmp.6oiXwl8gsl --volumes \<volume-id\> --tag-name outpost-node --wait

The firewall opens two ports: 22 for SSH and 3382/udp for gossip, which is how your node talks to the rest of the network. The node's API ports stay closed. Your client reaches them through an SSH tunnel. This matters: by default, a node with an open API port lets anyone on the internet send messages through it.

Already have a server? Skip this step and run OUTPOST_HOST=<ip> ./outpost node. It needs Ubuntu 24.04, root SSH and the disk above.

2Start a read node

./outpost node

setting up the read node on 142.93.168.228
[node-setup] data directory: /mnt/snap (1356 GB free)
[node-setup] starting snapchain 0.14.3 (read node)
 Container snapchain-snapchain-1  Running
 Container snapchain-statsd-1  Running
snapchain-snapchain-1 Up 9 hours
snapchain-statsd-1 Up 24 hours (healthy)
[node-setup] done. HTTP API on 127.0.0.1:3381 once the snapshot has loaded.

The node downloads a snapshot of the network (about 560 GB), loads it, then catches up
on the blocks since. On our test server loading took about 1 hour 45 minutes and
catching up about 4 hours more. The client works once loading is done; the newest casts
appear as it catches up. You can press Ctrl-C at any time; the node keeps going.
Check later with ./outpost status.
03:50 synced: every shard is within 0 blocks of the tip
next: ./outpost client

This is a second run on our already synced node, so it found the node running and returned at once. On a new server the last lines show download and loading progress until the node is synced.

This runs the official farcasterxyz/snapchain Docker image, pinned to version 0.14.3, with the official compose file. Outpost does not use the official installer script, because it reads from /dev/tty and so fails without a terminal, and because with no operator FID it exits before starting the node (issue #1030).

Our test server was a DigitalOcean one with 8 vCPU, 32 GB RAM and a 1.2 TB volume, on 18 to 19 October 2026: loading took 1 hour 43 minutes and catching up 4 hours 11 minutes. Snapchain's own loader took 6 hours 40 minutes to load on the same kind of server. Catching up takes longer the older the snapshot is. ./outpost status shows where it is:

node: loading snapshot: shard 1: 200 of 2672 chunks loaded, 20 GB on disk

Once it has caught up:

./outpost status

"Within 1 blocks of the tip" means your copy of every shard is at most one block behind the newest.

server: 142.93.168.228 (OUTPOST_HOST)
node: synced: every shard is within 1 blocks of the tip

Our node was set up before ./outpost provision existed, so we pointed Outpost at it with OUTPOST_HOST. A server made by ./outpost provision shows its provider and name on the first line instead.

3Connect an account

./outpost client

your node is reachable through an SSH tunnel on 127.0.0.1:13394 (no port opened on the server)
open http://127.0.0.1:8381 in your browser. Ctrl-C stops the client.
client: http://127.0.0.1:8381
node:   http://127.0.0.1:13394 (requests to /v1/* are forwarded there)

We ran it as OUTPOST_TUNNEL_PORT=13394 ./outpost client, because the default local port, 13381, was already in use on our machine. Yours will say 13381 unless you change it.

On a phone, run ./outpost client --phone instead. It serves the client from your server over HTTPS, using a free <ip>.sslip.io name so you need no domain, and puts a password in front of everything, including the node's API.

Not tested on a real server yet: --phone has only run in our tests, against a simulated cloud provider, so there is no real output to show here.

Open the address it prints. To post, choose Sign with a wallet if your account's custody address lives in a wallet, or Use a test account's recovery phrase. The command-line version is ./outpost cli login.

The outputs in this step and the next are from mainnet, with our test account (FID 3355358), on 18 October 2026. The warning printed before the first question is left out here, and the home path is shortened.

./outpost cli login

Before it asks you to sign, Outpost shows the custody address, the FID that address owns, its storage units and what the key may do.

Is this a test account, and do you accept the above? [y/N] y
Recovery phrase (input hidden):

custody address  0x15020a39b36cF852CDBD1aC036DF1f45ea4ccafa
FID              3355358
storage units    1
app key          can cast, react and follow; expires 30 days after last use
Sign the app key authorization for this FID? [y/N] y

app key 0xe0bb564ae0787b31ade0ac66856fcfb745b0eb98846e6370235332ca837cebde is live. Saved to ~/.config/outpost/appkey.json.
Your recovery phrase was not saved anywhere. Revoke this key any time with: ./outpost cli uninstall

./outpost cli whoami

FID 3355358, app key 0xe0bb564ae0787b31ade0ac66856fcfb745b0eb98846e6370235332ca837cebde
scopes: cast_add, cast_remove, reaction_add, reaction_remove, link_add, link_remove
expires: 2026-11-17T22:50:31.000Z unless used before then

Before any account is involved, you can check the signing code against your own node. This builds every message type Outpost uses with throwaway keys, asks the node to validate each one, and checks that two tampered messages are rejected. It sends nothing.

./outpost cli selftest

PASS  KEY_ADD (gasless, scoped, 30-day TTL): node says valid=true, expected true
PASS  CAST_ADD: node says valid=true, expected true
PASS  CAST_REMOVE: node says valid=true, expected true
PASS  LINK_ADD follow: node says valid=true, expected true
PASS  LINK_REMOVE follow: node says valid=true, expected true
PASS  REACTION_ADD like: node says valid=true, expected true
PASS  REACTION_ADD recast: node says valid=true, expected true
PASS  REACTION_REMOVE like: node says valid=true, expected true
PASS  KEY_REMOVE (self-revoke): node says valid=true, expected true
PASS  CAST_ADD with text changed after signing: node says valid=false, expected false
PASS  KEY_ADD with TTL widened after signing: node says valid=false, expected false

all 11 checks passed against http://127.0.0.1:13392

This run was against our mainnet node, through the tunnel on port 13392. The node's validator checks signatures and message rules, not account state, so it cannot tell you whether a custody signature matches a real account. The unit tests (npm test) cover that with known test vectors.

4Read and post

Snapchain has no home timeline endpoint. A following feed is the list of accounts you follow (/v1/linksByFid), the latest casts of each (/v1/castsByFid), merged by time. That is one request per account you follow, which is fine on your own node.

./outpost cli feed --fid 99 --limit 3

Each cast takes three lines: time, author and the app that posted it; the text; the author's FID and the cast's hash. The last lines count casts per app.

2026-10-18 22:46  @catra.eth  via warpcast (app fid 9152)
  @higherathletics proof  [1 embed]
  9318:0xbe6ca325398da8036c64f40605447a4b965f4231
2026-10-18 22:43  @trish  via own key
  My cat just dragged 32 oz of perfectly cooked medium rare flank steak off a hot pan and into the bathroom. Any suggestions for dinner? 162g of protein gone 😭
  4877:0x00eb1eece902ca6cf186c0aedb4bce2dc5c829d6
2026-10-18 22:39  @pichi  via warpcast (app fid 9152)
  As always, @kenjiquest crushed this one as well. I will never tire of this use of AI as a creative outlet.
  234616:0xf873c07770c4758afd0e0ec9da5a7c876c602586

3 casts in 4.51 s from http://127.0.0.1:13392
    2  via warpcast (app fid 9152)
    1  via own key

This is the following feed of FID 99, read from our mainnet node on 18 October 2026. Any account's following feed is public, so you can read one without logging in.

./outpost cli cast "Outpost test cast 1: testing a self-hosted client"
./outpost cli follow 1
./outpost cli like 3355358 0x0fe046f163063a3200260f1fbec8338d871d2ef0
./outpost cli recast 3355358 0x0fe046f163063a3200260f1fbec8338d871d2ef0

cast: 0x0fe046f163063a3200260f1fbec8338d871d2ef0 (confirmed: your node returns it)
follow: 0x43e3c752147f247248d92577bdba8272ac2be313 (confirmed: your node returns it)
like: 0x7a0cf348a93aa9c6e56955e3d7f776830c80b0d0 (confirmed: your node returns it)
recast: 0x06fcb40fa0fbd70a3caa344afd4704b7bd5a046f (confirmed: your node returns it)

Each line is a message hash. "Confirmed" means Outpost read that exact message back from your node. We liked and recast our own test cast, and undid all three afterwards with unlike, unrecast and unfollow.

5Filter by app

A cast does not say which app posted it. But it is signed by an app key, and every app key records the FID of the app that requested it. Outpost looks this up on your node for every author (/v1/signersByFid) and labels each cast. In the client, tap an app to show only its casts, again to hide them, again to reset. In the command line:

./outpost cli feed --fid 2 --limit 2 --exclude 9152

With app 9152 (warpcast) hidden, the feed shows casts from other apps and from people's own keys.

2026-10-18 22:06  @baseddesigner.eth  via puffinapp (app fid 3355363)
  testing
  196957:0x1fcb5aedc4a0a8ea2372b7f8a6e021400f67b29f
2026-10-18 21:16  @b05  via own key
  Amazon Discounts New Mac Mini by Up to $149, Mac Studio by $200 https://www.macrumors.com/2026/10/18/new-mac-mini-149/ via /feedme app by @b05
  196142:0x018d27bf1bff4e8e8cf6386b6c7e64cfd4c1bc59

2 casts in 4.04 s from http://127.0.0.1:13392
    1  via puffinapp (app fid 3355363)
    1  via own key

./outpost cli feed --fid 37 --limit 2 --include 16823

Only casts from app 16823 (fireflyapp) are left.

2026-10-17 05:50  @vitalik.eth  via fireflyapp (app fid 16823)
  Fun fact of the day: Bitcoin mining cost is split about 50/50 between compute capex and electricity. Meanwhile, AI inference is almost completely dominated by compute capex.  [2 embed]
  5650:0x9252885364ac7db01ac427e97dd246b7af619949
2026-10-15 03:39  @vitalik.eth  via fireflyapp (app fid 16823)
  Big congratulations to the @zksync airbender team for this milestone. At this point, I consider the battle for speed to be definitively won, and the top priority for zkEVMs should shift fully to secur  [1 embed]
  5650:0x2939942b565704c087d33fd818fac745551776e6

2 casts in 0.58 s from http://127.0.0.1:13392
    2  via fireflyapp (app fid 16823)

What this can and cannot tell you:

• A key a user signed for themselves carries their own FID as the app. Tools that do this, including Outpost by default, all look the same: "own key".
• A service that signs for many apps under one FID shows up as one app.
• An app key copied into another program cannot be told apart.
• The requesting app cannot be faked: the network checks the app's custody signature. But one developer can register several FIDs.

6What a keyless node cannot do

Your node runs without an Ethereum RPC endpoint. That is what makes it keyless, and it costs three things. It rejects, and so you cannot submit through it:

• .eth usernames and other ENS names,
• ENS username proofs,
• address verifications for smart-contract wallets.

Casts, reactions, follows, profile fields, plain usernames, normal wallet verifications and app keys all work. To get the three back, add l1_rpc_url with any Ethereum mainnet RPC to the node's config.

7Societies: a charter file

Filtering by app is one rule. A society is a set of them, written down and signed: who the members are, which apps' posts count, which channels and keywords, and a link to the society's code of conduct. Outpost calls this a charter. It is one JSON file.

The repository has an example built from public data: the 24 accounts that posted most in the /network-states channel in the last 90 days. It is unofficial and names no issuer, because nobody from that channel signed it.

./outpost cli charter verify examples/network-states.charter.json

OK: "network-states channel (example)", 24 members, signed by 0x71bFF431251Afc3E941f6f606B9016Ff3660D6F4. It names no issuer FID, so only the address vouches for it

The signature covers every field. Change one member and the file is rejected:

jq '.members += [3]' examples/network-states.charter.json > tampered.charter.json
./outpost cli charter verify tampered.charter.json

REJECTED: the file was changed after it was signed (signature does not match its content)

If the charter names an issuer FID, Outpost also checks on your node that the signer is that account's custody address. Nobody else can sign for the society.

In the client, load a charter in the Society panel. The feed then shows the society's members and channels, through its rules. Join follows its members with your app key. Leave drops the lens. Your keys, follows and posts do not change, because they were never the society's to begin with. Leaving is one tap.

The census counts members, members who posted in the last 7 days, casts per day, and the apps members post from. It reads only your own node, so anyone with a node and the same file gets the same numbers.

./outpost cli charter census examples/network-states.charter.json

"network-states channel (example)"
census 2026-10-11 to 2026-10-18 (7 days), from your node
  members            24
  active (posted)    23
  casts              1071  (153 per day)
  apps members posted from:
     1023  warpcast (app fid 9152)
       32  own key
       16  fireflyapp (app fid 16823)
computed in 0.5 s

To check it, scripts/manual-census.sh counts the same thing with only curl and jq, none of Outpost's code. Run a few seconds later, it agreed:

scripts/manual-census.sh examples/network-states.charter.json 7

members 24
active 23
casts 1071
casts_per_day 153.0

A charter is a lens, not a wall. It changes what you see and whom you follow. It cannot stop anyone posting, and it hides nothing from anyone else.

8Share your node

A node costs money for every hour it runs, so it makes sense for a society to share one. In society mode your server stops being only yours: members of your society use it from their own browsers, with their own accounts, for free.

That means members trust you a little. Outpost keeps that trust small, in code anyone can read. Your server serves no page and no script, so you cannot change the client a member runs. Their app keys stay in their browsers, so you cannot post as them. Their client checks every message it reads, so you cannot alter or invent what they see. What you can still do, such as see what they read, is listed in TRUST.md.

./outpost society on

open (or close) 443/tcp in your server's firewall yourself; Outpost did not create this server.
[society] serving the node API at https://142-93-168-228.sslip.io to members only (no web page)

society node: https://142-93-168-228.sslip.io (the node API for members; no web page)
add a member: ./outpost members add <name>
the first request can take a minute while the certificate is issued.
turn it off with: ./outpost society off

Shortened: the lines that download the gate's container image are cut. Our node was set up before ./outpost provision existed, so we ran this with OUTPOST_HOST and opened 443/tcp in its firewall ourselves.

A gate now sits in front of the node. It lets a request through only with a member's token, only for reads and for posting, and only as fast as that member's rate limit allows. Add a member:

./outpost members add test1

invite link for test1 (shown once; send it privately, whoever has it can use the node as test1):
it works once society mode is on (./outpost society on). Remove with: ./outpost members remove test1

Shortened: the line with the link is cut, because it holds test1's token.

The link opens the client from GitHub Pages, built from this repository by a public workflow, and tells it which node to use. The token comes after #, so the browser never sends it to GitHub. Your server only ever stores a hash of it. ./outpost members remove test1 turns the token off at once.

Any member can check the gate from outside with curl. With test1's token in a file:

scripts/society-check.sh https://142-93-168-228.sslip.io token.txt

without a token:          401
with a wrong token:       401
with your token:          200
a page (/):               403
POST /v1/validateMessage: 403
DELETE /v1/info:          403
type of a reply:          application/json
300 reads at once (count, status, Retry-After):
 111 200 
 189 429 1

401 means no access without a valid token; 403 means the gate refuses everything except reads and posting; 429 means the member hit their rate limit (by default 20 reads a second, with bursts of 100) and should wait the number of seconds given.

The command-line client works against a society node too. It checks every message, and asks a second node (Farcaster's public one, unless you pick another) about keys that have no onchain record:

npm ci && npm run build
node dist/cli.js feed --fid 3 --limit 8 --node https://142-93-168-228.sslip.io --token-file token.txt

2026-10-19 08:48  @grin  via warpcast (app fid 9152)
  Marrakech goes hard  [1 embed]
  1970:0x4ca01b4642ff443661db6812a0ef49e0765aac1e
2026-10-19 02:26  @brixbounty  via own key  [signer confirmed by second node]
  18723:0x45e4db64566b2ba0b92a4ba4e1f08043f033f60b

8 casts in 7.74 s from https://142-93-168-228.sslip.io
    7  via warpcast (app fid 9152)
    1  via own key
warning: Your node sent 1 of 4160 messages that failed verification (1 altered); they are not shown.

Shortened: 6 of the 8 casts are cut.

"Signer confirmed by second node" means the cast was signed with a key added without an onchain transaction, and a second, independent node confirmed it is the author's. In our samples about 1 honest message in 10,000 is encoded in a way the client cannot rebuild exactly; it is dropped and counted with the rest, never shown as if it were fine.

./outpost society off stops the gate, and on a server Outpost made, closes 443/tcp.

9Clean up

./outpost uninstall

revoking the CLI's app key with the key itself (no recovery phrase needed)
revoked app key 0xe0bb564ae0787b31ade0ac66856fcfb745b0eb98846e6370235332ca837cebde for FID 3355358. No recovery phrase was needed.
deleted ~/.config/outpost/appkey.json
keys added in the web client are revoked from its 'Your app key' panel.

Casts the key signed stay on the network after it is revoked. (Checked on mainnet with Snapchain 0.14.3: our test cast is still there after its key is revoked.) Delete them first with ./outpost cli delete <hash> if you want them gone.

The key signs its own removal (KEY_REMOVE), so no recovery phrase is needed. If you never revoke it, it expires 30 days after its last use.

./outpost destroy

This deletes the server, the volume and the firewall after you type the server's name. Your account, follows and casts are not affected; they live on the network.