Today we're cutting Spinifex 1.2.0, the first version of our open-source edge cloud platform that we're explicitly calling production-ready. EC2-style compute, EBS-compatible block storage, and S3-compatible object storage, running on commodity hardware, with zero dependency on a hyperscaler control plane. The release is on GitHub now.
Spinifex started as a question we kept being asked by defence and industrial operators: "We've already invested years in cloud-native tooling. Why does running it on our own hardware, in environments where the cloud isn't an option, have to mean throwing all of that away?" 1.2.0 is the version that answers that question, in production, today.
What's new since 1.0
1.0 was a feature-complete first release. 1.2 is the version we trust to handle real workloads in real conditions. The headline changes:
- Predastore multi-node clustering with Reed–Solomon erasure coding. Lose a node, keep the data. Lose a disk, keep the bucket. Rebuilds run online, no operator intervention.
- Viperblock NVMe write-back cache with crash-consistent replay. We've measured a 4–6× reduction in p99 write latency on our reference rugged hardware, with no loss of durability guarantees.
- Cloud-init parity at the level we needed: the same images you build for AWS boot on Spinifex without modification, including user-data, instance metadata, and SSH key injection.
- PCIe passthrough for accelerators: GPUs, SDRs, and capture cards now attach to a Spinifex VM at near-native performance. This is the foundation for the AI inference work we've been doing with partners.
- SigV4 across the board. Predastore now passes the complete public AWS S3 conformance tests we've open-sourced alongside the release.
The full changelog is in the GitHub release notes. We've also published the upgrade path from 1.0: no schema migration is required, but Predastore clusters need a one-time recoding pass to enable the new erasure profile.
Try it
The fastest path to running Spinifex 1.2.0 is the bootable ISO from the release page. Boot it on bare metal, follow the on-screen prompts, and you'll have a single-node cloud answering AWS-compatible API calls in under ten minutes.
# From any AWS-CLI-aware shell
# Launch an EC2 instance in the default VPC subnet
aws --endpoint-url https://your-spinifex-node:9999 \
ec2 run-instances --image-id ami-spinifex-ubuntu-2404 \
--instance-type t3.medium
# View available VPC subnets
aws --endpoint-url https://your-spinifex-node:9999 \
ec2 describe-vpcs
# Create a new S3 bucket
aws --endpoint-url https://your-spinifex-node:8443 \
s3 mb s3://hello-edge
# Copy a large file locally to the new S3 bucket
aws --endpoint-url https://your-spinifex-node:8443 \
s3 cp /tmp/largefile.bin s3://hello-edge/For multi-node deployments (the configuration we recommend for any production setting), see the Spinifex documentation. We've also refreshed the cluster bootstrap guide with the new Predastore replication primitives.
Let's chat
If any of this is interesting, whether you want to deploy Spinifex, contribute to it, or talk to us about your edge workload, get in touch via our contact page. The most interesting deployments we've seen so far have come from operators who started with "this seems too good to be true" and found out it wasn't.
Thanks to the early access customers, our community for feedback, and the team. It's time to build!
