Gump runs your applications on your own servers, from one machine to a cluster. It is one 24 MB binary. Give it a signed package and it places the work, starts it, keeps it running, replaces it safely, and recovers it after failures.
It runs ordinary programs, containers, microVMs and Cloudflare Workers-style functions side by side, under one manifest and one command line.
What it does
- Deploys signed, encrypted releases. An application and its configuration ship as one immutable package, a Capsule. Secrets travel inside it, sealed to the cluster, and reach the process only in memory.
- Runs five kinds of workload. Native binaries, scripts, OCI images under
rootless
runc,workerdfunctions, and Firecracker microVMs with a jailer and per-workload networking and egress rules. - Places work across machines. Each member reports what it can run. The scheduler handles spread, require and prefer rules, anti-affinity, priorities and preemption, gangs, and one-per-node coverage.
- Replaces releases safely. The old attempt keeps running until the new one proves it is ready. Readiness is declared evidence, never a guess from process state.
- Keeps its control state in replicated memory. Cluster memory is Raft held in RAM, with no database to run. Encrypted state backups are available when you want them, and S3-compatible storage holds the sealed Capsules.
- Heals its own membership. Members leave, get evicted, restart and rejoin through any other member. A singleton can declare that it must stop when its node is cut off, so it never runs twice.
- Introduces workloads to each other. Hiccup, an authenticated upgrade of the ordinary health check, lets an application advertise what it offers and learn who else is present. It needs no sidecar and no service registry.
- Carries telemetry. Output and application records flow through Ratatouille, with bounded capture and relay.
- Controls custody. A cluster starts sealed until an operator unseals it, with Shamir-shared recovery keys. A single host can opt into unsealing itself at start.
One server or many
gump server --init --standalone DIR makes one machine a complete platform. State is
kept on its own disk within about a second of every change, and native, script and
worker applications outlive Gump itself: the next start takes over the same running
processes.
The application model stays the same as you add machines. The manifest, the Capsule and the commands do not change between one server and a cluster.
With Kismet
Gump runs independently and pairs with Kismet, Frogfish's edge. Kismet terminates public HTTPS with automatic certificates and finds applications through Hiccup. A workload advertises its hostname from its own health check, and traffic flows directly from Kismet to the application. Gump never relays application traffic.
Measured
On DigitalOcean droplets with 1 vCPU and 1 GB of memory:
| What | Result |
|---|---|
| Gump's resident memory | about 18 MiB |
| Gump restart, upgrade or crash on one server | no interruption: the same Kismet process answered every probe |
| Full host reboot, unattended | edge back in 24 s |
| Worker directly | 2,169 requests per second, p50 0.43 ms |
| Three-node faults | leader kill, member and leader isolation, 90 ms and 210 ms links, total loss with and without backups |
A real API, Aroiv's, rewritten as a Gump worker and run on trial data, with its database on a second droplet:
| What | Result |
|---|---|
| 40-dish public menu read through Kismet | p50 34 ms, p99 50 ms |
| Atomic publish of a menu | 9 to 13 ms |
| Database host rebooted | 503s for 16 s, no hung requests, recovered without action |
| Database's ingress restarted | every read answered |
Why it matters
Small teams and single products face a bad choice. Hosted platforms are easy but own
the machines, the data path and the bill. Kubernetes keeps control but demands a
platform team. Many end up with hand-kept systemd units and scripts that have no
signed releases, no safe replacement and no way to grow.
Gump gives one operator the guarantees of a serious platform on machines they already rent. A 1 GB server is a real target, and the first server does not have to be rebuilt to become a cluster.
It also unifies what is normally separate. A function, a container and a VM-isolated workload share one release format, one secret path, one scheduler and one set of commands, so the isolation of each workload becomes a line in its manifest and not a choice of platform.
The state pattern matters too. A stateless worker with a light database client, shown here with Residiuum, lets a whole class of applications run like edge functions on infrastructure you own.
Compared to others
| Gump | What is different | |
|---|---|---|
| Kubernetes | One binary, no etcd, no CNI or ingress to assemble | Kubernetes is an ecosystem to operate; Gump is a program to run |
| Nomad | The closest relative: a single binary that schedules mixed workloads | Gump's control state lives in replicated memory, not on server disks. Releases are signed and encrypted by format. Workers and Firecracker are built in, and Hiccup does discovery |
| Fly.io | Firecracker microVMs too, and a similar deploy-and-run experience as the goal | Fly.io is a hosted service on its own hardware. Gump runs on machines you choose |
| Cloudflare Workers | The same workerd runtime and module format |
Workers runs on Cloudflare's network. Gump runs functions on your servers, next to your other workloads |
Docker Compose, systemd |
The same ease on one machine | Gump adds signed releases, sealed secrets, safe replacement and a path to many machines |
The facts
- Written in Rust, with one Cargo workspace and one binary for every role.
- Builds for Linux x86-64 and macOS arm64.
- Transport is authenticated QUIC. Object storage is treated as untrusted for both confidentiality and integrity.
- Created and owned by Alexander R. Croft. Binaries are licensed by Frogfish LLC under the Frogfish Binary License 1.0.