DEV Community: Tom

The Best Open Source Cloud Providers in 2026

Tom — Thu, 22 Oct 2026 02:20:01 +0000

The open source cloud landscape covers a lot of ground. Some platforms give you a full IaaS stack with their own API surface. Others sit on top of existing hypervisors. A few implement the AWS API so your existing tooling carries over unchanged. The right choice depends on what you're replacing, what your team already knows, and whether you can afford to rebuild your operational model from scratch.

This is a practical comparison of the main options in 2026, written from our own vantage point as one of them. We've tried to be honest about where each tool fits and where it doesn't.

OpenStack

OpenStack is the oldest and most battle-tested open source cloud platform available. It covers compute (Nova), object storage (Swift), networking (Neutron), block storage (Cinder), identity (Keystone), and a dozen other services, each maintained as a separate project under the OpenStack Foundation. Telecoms, national research networks, and large enterprises run it in production at serious scale.

The operational complexity is real. Deploying OpenStack on anything other than a managed distribution requires substantial expertise, and keeping it running requires a dedicated team. If you are evaluating OpenStack for a team of five engineers, the maintenance overhead will consume more capacity than the platform returns.

OpenStack has its own API surface. Your AWS CLI, Terraform AWS provider, and eksctl workflows do not carry over. Teams switching from AWS need to learn a new operational model.

Best fit: Large organisations with dedicated infrastructure teams who need maximum flexibility and have no AWS tooling dependency.

Apache CloudStack

CloudStack is a mature IaaS platform originally developed by Cloud.com, open-sourced in 2010, and now under the Apache Foundation. It is simpler to deploy and operate than OpenStack and has been used by several commercial cloud providers as the underlying platform. The API is CloudStack's own, with some AWS EC2 API compatibility that covers basic instance management but not the full surface.

The community is smaller than OpenStack's and development pace has slowed, but the platform is stable and well-understood. For teams that need a proven IaaS layer without OpenStack's operational overhead, CloudStack is worth evaluating.

Best fit: Mid-size organisations building an internal cloud who want something more operationally accessible than OpenStack.

OpenNebula

OpenNebula is a European open source cloud platform with a strong following in HPC, research, and edge computing environments. It manages KVM, LXC, and Firecracker workloads and is designed to run on a lean footprint, making it viable on smaller hardware clusters where OpenStack would be overkill. It has its own API surface and a web interface that is considerably simpler to navigate than OpenStack's Horizon.

OpenNebula's community is smaller than either OpenStack or CloudStack, but the project is actively maintained and the documentation is good. For edge and research deployments where simplicity and low resource usage matter more than breadth of services, it is a credible choice.

Best fit: Research institutions, HPC environments, and edge deployments that need a lightweight IaaS layer.

Proxmox VE

Proxmox is a hypervisor management platform built on KVM and LXC, not a cloud platform in the IaaS sense. It gives you a web interface for managing virtual machines and containers across a cluster, along with Ceph integration for shared storage. It does not give you an API that applications call to provision infrastructure programmatically in the way that AWS, OpenStack, or CloudStack do.

Proxmox's star rose sharply after Broadcom's VMware acquisition triggered 800 to 1,500% price increases for standalone vSphere customers, and it is the most common destination for VMware refugees. The transition from vSphere to Proxmox is relatively straightforward for teams whose operational model is manual VM management through a web interface.

Teams who built their operational model on Terraform, eksctl, and the AWS CLI face a harder transition. Proxmox has no equivalent for those tools.

Best fit: Teams replacing VMware who manage VMs through a web interface rather than programmatically.

Ubicloud

Ubicloud (AGPL-3.0, Ruby, 12,300 GitHub stars) is a managed cloud service running on Hetzner and Leaseweb hardware that offers elastic compute, block storage, managed Postgres, Kubernetes, firewall, load balancer, and AI inference endpoints. Pricing runs 3 to 10x lower than equivalent AWS services, which is the primary pitch.

Ubicloud is a hosted service you access over the internet rather than software you deploy on hardware you own. For teams looking to cut their cloud bill without changing their operational model significantly, it is worth evaluating. For teams with data sovereignty requirements or air-gapped deployments, it is not the right answer because your data still lives on someone else's hardware.

Best fit: Teams on AWS who want to reduce their bill and can tolerate moving to a different hosted provider.

Spinifex

Spinifex (AGPL-3.0, Go, github.com/mulgadc/spinifex) is our product. It implements the AWS API surface — EC2, S3, IAM, EKS, ECS, ECR, VPC, EBS — on standard Linux bare metal, with no external control plane and no internet requirement.

The specific thing Spinifex does that none of the other platforms on this list do is preserve your AWS tooling investment. If your team has Terraform configs written against the AWS provider, eksctl workflows, IAM role structures, and scripts using the AWS CLI, those run against Spinifex with a single endpoint override, meaning far less rework to your operational model.

The performance case is documented in our OnLogic HX401 benchmark: CPU overhead runs 7% (sysbench single-thread: 1,358 events/s guest vs 1,456 bare metal). The docs also cover areas of active improvement.

Spinifex is the right answer for teams in air-gapped or sovereign environments, teams on edge hardware where AWS connectivity is unreliable, and teams with enough AWS tooling investment that rebuilding it on a new API surface is not a viable option. It is not the right answer for teams who need maximum breadth of services, or are primarily doing web-based VM management.

Best fit: Teams deploying to air-gapped facilities, edge hardware, or sovereign environments who have existing AWS tooling they want to preserve.

Choosing between them

The questions that narrow the field fastest:

Do you need AWS tooling compatibility? If your team has significant Terraform, eksctl, or AWS CLI investment, that eliminates OpenStack, CloudStack, OpenNebula, and Proxmox from the running. Ubicloud covers some AWS API surface but is a hosted service. Spinifex covers the core services required to run on hardware you own, with additional AWS service support added regularly.

Do you need to keep data on hardware under your direct control? That eliminates Ubicloud. The on-premise options are OpenStack, CloudStack, OpenNebula, Proxmox, and Spinifex.

Do you need to operate without internet connectivity? OpenStack can run air-gapped with sufficient effort, but it was not designed for it. Spinifex installs from a release tarball with no external dependencies and has no phone-home requirement.

Do you need to replace VMware with something familiar? Proxmox is the most direct path if your team manages VMs through a web interface. If your team provisions infrastructure programmatically, Proxmox does not cover what VMware gave you.

Given the many options for open source cloud providers, we encourage teams to research each option thoroughly to decide which option is best for them.

Full Spinifex documentation is at docs.mulgadc.com. For the other platforms: openstack.org, cloudstack.apache.org, opennebula.io, proxmox.com, ubicloud.com.

The quickest and easiest way to tell if Spinifex is the best option for you is through our hosted sandbox, which gives you 72 hours to try Spinifex without getting your own hardware involved. Sign up here: https://mulgadc.com/signup

From LocalStack to Production: What Changes When Your AWS Code Runs for Real

Tom — Thu, 15 Oct 2026 05:54:45 +0000

Your Terraform applies cleanly against LocalStack. Your boto3 tests pass against Floci or Moto. The code is written, the CI pipeline is green, and now it has to run somewhere real. For most teams that place is an AWS region. There is another option: the same AWS APIs on hardware you own.

This guide walks through what changes when the same AWS code moves from an emulator to Spinifex, an AWS-compatible cloud that runs on your own servers. We go over the configuration to edit and the services you should check first.

The differences

The code stays the same. All you change is the endpoint, credentials and TLS configuration, and the emulation becomes real: EC2 instances boot as virtual machines, security groups filter traffic, resources persist until you delete them, and IAM policies are evaluated on every request.

	Emulator (LocalStack, Floci, MiniStack, Moto)	Spinifex
Endpoint	One HTTP port, 4566 by convention	AWS gateway on 9999, S3 on 8443, both over TLS
Credentials	Any key works, conventionally `test`	Real access keys, verified with SigV4
IAM	Off by default; every call is allowed	Policies evaluated on every non-root request
EC2	Records in memory, or Docker containers	KVM virtual machines booted from AMIs
Networking	Security groups stored, not enforced	Security groups enforced in the hypervisor datapath
State	Gone on restart unless persistence is enabled	Persists until you delete it

Check service coverage first

Emulators are broad. Floci covers 47 services and MiniStack more than 60, because emulating an API is simpler than running the services behind it. A production platform has to implement each service for real, so the list is shorter.

Spinifex serves EC2, EBS, VPC, S3, IAM, STS, ELB, EKS, ECS, ECR, RDS and ACM. It does not serve Lambda, DynamoDB, SQS or SNS. The full list of supported services and operations is on our AWS API coverage page, generated from the gateway on every build.

Endpoints and TLS

An emulator listens on one plain HTTP port. Spinifex splits the work across two TLS endpoints: the AWS gateway on port 9999 for EC2, IAM, STS, EKS, ECS and the rest, and Predastore, the S3 service, on port 8443. S3 uses path-style addressing, which most emulator configurations already set.

If you use tflocal or a hand-written LocalStack provider block, the Spinifex version is shorter:

provider "aws" {
  region = var.region

  endpoints {
    ec2 = var.spinifex_endpoint
    iam = var.spinifex_endpoint
    sts = var.spinifex_endpoint
    s3  = var.predastore_endpoint
  }

  s3_use_path_style           = true
  skip_credentials_validation = true
  skip_requesting_account_id  = true
  skip_metadata_api_check     = true
  skip_region_validation      = true
}

The access_key = "test" lines go away, and the provider reads real keys from your AWS profile instead. Keep the two credential skip flags when the configuration manages S3: without them, AWS provider 6.x reads bucket tags through S3 Control, whose hostname carries your account ID and cannot resolve against an IP address.

Spinifex generates its own certificate authority at install time. Point every SDK and the AWS CLI at it once, with export AWS_CA_BUNDLE=/etc/spinifex/ca.pem, and no application code needs to know about it. We cover the Terraform details, including AMI lookups and passing endpoints through CI, in Terraform on premise.

IAM policies are enforced

This is an important one. LocalStack leaves IAM enforcement off unless you set ENFORCE_IAM=1, and Moto does not evaluate policies by default, so code that has only run against an emulator has never been told no.

Spinifex verifies and evaluates every request the way AWS does. Each call is checked against the caller's identity policies, group policies and any role it has assumed, an explicit Deny wins, and anything not allowed is denied. The first deploy surfaces every missing iam:PassRole, every role that cannot be assumed, and every policy written with a wildcard that the application stopped needing.

Note: the root user bypasses policy evaluation, on Spinifex as on AWS. If you deploy with root keys, IAM looks like it is working because nothing is being checked. Create an IAM user or role for each pipeline and workload, and use root only to create them.

EC2 instances are virtual machines

In Moto and LocalStack's mock mode, RunInstances returns an instance ID and stores a record. LocalStack's paid tiers can back instances with Docker containers. Either way, your Terraform has been creating something that answers DescribeInstances and boots nothing.

On Spinifex each instance is a KVM virtual machine booted from an AMI. User data runs through cloud-init, instances take seconds to boot rather than milliseconds, and an AMI lookup needs to find a real image. Spinifex publishes its images under the placeholder owner account 000000000000, so data "aws_ami" filters that name an AWS account ID, such as Canonical's, need the owner changed.

Workloads that read the instance metadata service meet one more change. Spinifex serves IMDSv2 only, with session tokens required, and the setting cannot be relaxed. Current AWS SDKs use IMDSv2 already. Scripts that call curl http://169.254.169.254/latest/meta-data/ without a token need updating, and they need the same change on Amazon Linux 2023, which requires IMDSv2 by default.

Security groups filter real traffic

An emulator stores your security group rules and returns them when asked. Nothing sits in the packet path. Spinifex enforces security groups as stateful firewall rules in the hypervisor's virtual switch, before traffic reaches the guest, in the same place AWS enforces them on its Nitro cards.

State persists, so tests need to clean up

Emulators start empty. LocalStack keeps nothing between restarts unless persistence is enabled, and most CI pipelines rely on that. Every run gets a fresh account, and teardown is docker stop.

On Spinifex, volumes, buckets, instances and IAM entities exist until something deletes them. Integration tests that used to leak resources now leak real disk and real compute. Give each pipeline its own account, destroy with terraform destroy rather than relying on a restart, and treat Terraform state as production state from the first apply.

Keep the emulator

None of this replaces the emulator. Floci, MiniStack and Moto remain the right tools for unit tests and fast CI, and we compare them in LocalStack alternatives. The emulator makes sure your code calls the API correctly. Spinifex makes sure your infrastructure works: whether the policies grant enough, the instances boot, and the network lets the right traffic through.

An effective pipeline uses both. Run unit tests against an emulator on every commit, then apply the same Terraform to a Spinifex cluster before production, or as production. The provider block above is the only file that differs between them.

Try the move without hardware

The free sandbox gives you a Spinifex endpoint, access keys and a console for 72 hours, which is enough to point your Terraform configuration at it and see what IAM and the network make of it. The source is on GitHub under AGPL-3.0, and the installation guide and Terraform workbooks are at docs.mulgadc.com.

Frequently asked questions

Can I use LocalStack in production?

No. LocalStack emulates the AWS API for development and CI. IAM enforcement is off by default, EC2 instances are records or Docker containers, and security groups are stored rather than enforced. Production needs AWS itself or a platform that implements those services for real, such as Spinifex on your own hardware.

What changes when I move Terraform from LocalStack to a real AWS-compatible endpoint?

The resources stay the same. The provider block changes: the endpoints point at the real service, the placeholder test credentials are replaced with real access keys, and TLS is verified against the platform's certificate authority. Against Spinifex, the AWS gateway runs on port 9999 and S3 on port 8443.

Why does my code get AccessDenied after moving off an emulator?

Emulators allow every call by default, so policies are never tested. A real platform evaluates the caller's policies on every request, an explicit Deny wins, and anything not allowed is denied. Missing iam:PassRole grants and roles that cannot be assumed are the most common first failures.

Which AWS services does Spinifex support?

Spinifex serves EC2, EBS, VPC, S3, IAM, STS, ELB, EKS, ECS, ECR, RDS and ACM on your own servers. It does not serve Lambda, DynamoDB, SQS or SNS, so applications built on those need another home for those components.

Should I stop using an emulator once I run Spinifex?

No. Floci, MiniStack and Moto stay the fastest way to run unit tests and CI. Use the emulator to check that code calls the API correctly, and apply the same Terraform to a Spinifex staging account to check that policies, instances and networking work.

We Have AGI At Home

Tom — Tue, 15 Sep 2026 03:41:36 +0000

The case against open-weight models has always been that they were the cheaper, weaker option, and if you wanted real quality you paid a frontier provider. As of mid 2026 that case has mostly collapsed, with the best open-weight models sitting around 3.4 points behind the best closed one on the Artificial Analysis Intelligence Index, measured across 270 models. Epoch AI cites a roughly four-month lag.

So we find ourselves in a time where the model itself is no longer the bottleneck. In this post we will epxlore the idea that we dont actually need better models, and instead target the setup a small-to-mid-sized organisation needs to run the ones we already have. And by "running" we don't mean a single dev running the latest TMBBs (Trust Me Bro Benchmarks) - we mean building out a tool organisations can use to do actual work. We covered the deployment mechanics in an earlier post on baremetal AI.

The current state of open models

This landscape changes seemingly every other week, but as of the time of writing (mid September, 2026), here's the gist:

At the top, some open models can now hold their own in real agentic pipelines as frontier substitutes. DeepSeek's V4 line reached the low-80s on SWE-bench Verified under an MIT license, while GLM-5.2, Kimi K3, and Qwen's largest models trade the lead on coding and agentic benchmarks.

In the middle sit the 24-to-32-billion-parameter models such as Qwen's 27B, Gemma 4 31B, and Mistral-Small, which handle reasoning and coding well enough for most production work.

At the small end, models like gpt-oss-20b and Phi-4 can do drafting, extraction, and classification on very little hardware.

Most of the frontier-grade open models use a mixture-of-experts design with million-token context windows, so a model with hundreds of billions of total parameters activates only ten to twenty billion per token. The point is that "open" no longer means "compromise" for models doing real work. The deciding factor is where and how you run it.

The Hardware

The common assumption is that serving a capable model means buying or renting the same GPUs the labs use. But as the models get better and increasingly more compatible with commodity hardware, is it really necessary to spend $25,000 to $33,000 on a H100? Or $350,000 on an eight-GPU cluster? That is hyperscaler and AI-lab territory, and we all know hardware prices are only going up.

What small-to-mid-sized organisations can actually buy, without a procurement committee, are workstation-class cards:

Card	VRAM	Approx. price	Notes
RTX 4090	24 GB	$2,400–3,500	ubiquitous, single-user tier
RTX 5090	32 GB	$3,000–5,000	~160 tok/s, 32B at Q4 on one card
Used A6000	48 GB	$2,600–3,800	best value at 48 GB
RTX 6000 Ada	48 GB	~$6,800	70B at Q4 in VRAM
L40S	48 GB	$7,500–10,000	server-grade, strong cost per token
RTX Pro 6000 Blackwell	96 GB	~$8,600	70B at Q8 in VRAM, FP4

So now we can map what you own to what you can run:

VRAM	Fits (quantized)	Good for
16 GB	gpt-oss-20b, Phi-4 14B, 13B at Q8	drafting, classification, light coding
24 GB	14–32B at Q4 (Qwen 27B, Gemma 4 31B, Mistral 24B)	real reasoning and coding
48 GB	70B at Q4/INT4 (Qwen 72B, Llama 3.3 70B)	70B quality, small concurrency
96 GB	70B at Q8 in VRAM	higher fidelity, more headroom
Mac 64–128 GB	70B at Q4, 34B at Q8, ~120B at low quant	low-power single box

Serving a model is bounded by memory, not compute. You budget VRAM as the weights (parameters times bytes per parameter, set by quantisation) plus the key-value cache for in-flight requests plus a few gigabytes of runtime. Get it right and a 27-to-40-billion-parameter model at 4-bit, on one 24-to-48 GB card, delivers reasoning and coding that competes with commercial offerings. That is real work, on hardware that costs about as much as a nice laptop, or that you already own.

The real juice is in the harness

The view that base models do not need to get much better, and that most of the remaining gains live in the harness around them, has gained traction as the AI space has matured. This is backed by evidence. Pure parameter scaling is showing diminishing returns: knowledge tasks plateau beyond about 30 billion parameters, reasoning tasks around 70 billion and up, and high-quality training data is running short.

Meanwhile, the harness continues to pay off. Tool orchestration, persistent memory, environment sandboxing, and automated feedback loops now separate a good agent from a useless one, and many leading agents reach frontier performance through scaffolding rather than a bigger underlying model.

In any case, the harness dictates not only how effective the model is for the individual user, but also its usability for organisations - Orchestration, autoscaling, retrieval plumbing, access control, and audit are just as crucial as how elegantly or autonomously your agent can write code.

The jump from one card to a platform

So now you have open-weight models running on actually obtainable hardware. How do you build that up from a single dev rambling about benchmark scores into a platform an entire organisation can use for real work? Well, such a shared service needs four things.

GPU capacity that scales with demand.
Model weights that are versioned and delivered wherever they run.
Endpoints that are access-controlled and audited.
Enough utilisation to justify the hardware.

That last one determines the economics. Self-hosting beats a frontier API only once the GPUs are busy, on the order of tens of millions of tokens a day at high utilisation. Keeping expensive silicon fed means autoscaling and sharing one fleet across teams.

Each one of the aforementioned requirements already has a solution in the AWS toolkit. The only catch is that using it means running on AWS. But you just went to all that effort ditching the cloud-served frontier models in favour of the open ones, and buying your own commodity hardware to run them, only to realise you still need the cloud!?

Until now, this was the "rock" to the proverbial "hard place" of the increasingly concerning token economics of the frontier labs. Luckily, there's a new kid on the block that can help with this.

Spinifex implements the aforementioned AWS toolkit on hardware you own, so the platform you would have built in the cloud maps onto your own GPUs with tooling your team already knows. EC2 provisions and scales the GPU instances. EKS schedules the vLLM or SGLang pods and scales replicas with demand, which is what keeps utilisation and the economics where they need to be. S3, backed by Spinifex's erasure-coded Predastore, becomes the model registry that versions and distributes weights. IAM and STS gate which teams reach which endpoints, with an audit trail. ELBv2 spreads load across replicas.

So now you get the same Terraform and the same AWS CLI, with one provider override pointing at your endpoint. We walked through a concrete build, an EKS cluster on a Supermicro X14 with two RTX Pro 6000 GPUs wired entirely in Terraform, in the earlier baremetal AI post and the reference architectures in our docs. Unlike a premium integrated rack, none of it requires special hardware, and unlike a hyperscaler cluster, none of it requires a cluster. You start on the commodity box you own and grow the fleet.

Is it worth it against a frontier API?

Often, but not always. But the direction of travel is clear: by some counts more than half of enterprise inference now runs on-premise or at the edge, up from about an eighth in 2023. One representative scenario puts break-even at roughly four months at 30 million tokens a day.

So it becomes a question of how much commodity compute is obtainable for your organisation, what kind of work needs to be done and at what rate. Spinifex provides the tools to help make the economics more viable by relicating what you'd usually use AWS for. But for those with the right set of circumstances, a fully functional open weight model, running on on-prem, obtainable hardware, with a harness that makes the platform effective at both the individual and organisational level, is actually within reach.

What could that look like?

Retrieval over private corpora. Point SGLang at your legal, financial, or internal knowledge base and let prefix caching absorb the repeated system prompt. The documents never leave your control.
High-volume batch inference. Classification, extraction, and summarisation pipelines run the GPUs hard and steady, which is exactly where owned hardware wins on cost.
Agents on internal systems. With open models clearing the low-80s on SWE-bench, agents that read and act on private codebases are viable with no token bill and no data-egress review.
Fine-tuning on data that cannot leave. Train and serve on the same fleet, with the tuned weights landing in self-hosted S3 next to the base models.
Air-gapped and sovereign inference. The model never phones home and the stack runs disconnected, which is the requirement for defence, healthcare, and finance operators who cannot use a public API at all.

Get started

Our reference architectures cover deploying GPU-backed EKS clusters and AI workloads on your own hardware, including the air-gapped install path. The source is on GitHub, written in Go and AGPL-3.0 licensed. Or sign up for the free sandbox to explore the AWS-compatible API surface before you commit hardware.

Fakecloud vs Spinifex: AWS Emulator vs Production Platform

Tom — Thu, 10 Sep 2026 06:59:32 +0000

Fakecloud and Spinifex both answer to the AWS API, which is enough to land them in the same search results. They are not alternatives to each other. Fakecloud covers local development and CI. Spinifex covers production when that environment is hardware you own. Knowing which is which keeps a dev tool out of production and a production platform out of your CI pipeline.

What Fakecloud is

Fakecloud is a free, MIT-licensed AWS emulator built around the AWS Smithy service models. Instead of hand-writing each service, it generates its API surface from the same models AWS publishes, and that is how it reaches 105 services and 7,396 operations. The breadth is the point: model-driven coverage rather than hand-tuned depth.

The runtime is a single binary of around 19 MB that idles near 10 MiB, so it fits into a CI job or a laptop without much overhead. Covered services include S3, DynamoDB, SQS, Lambda, IAM, STS, ECS, ECR, EC2, and Bedrock, plus RDS backed by six real database engines and 80 more beyond those. The project is younger and smaller by star count than Floci or LocalStack, and it targets a wider slice of the API than either.

Fakecloud does not run real infrastructure. Call ec2 run-instances and you get a well-formed response that matches the model, but no virtual machine boots. Call s3 put-object and the bytes land somewhere convenient for the test, with no erasure-coded storage engine enforcing durability. For an emulator that trade-off is correct, because a developer's inner loop and a CI job need fast, faithful responses rather than production behaviour under load.

What Spinifex is

Spinifex is an AWS-compatible cloud platform for hardware you own. It implements EC2, S3, IAM, EKS, and the rest of the common AWS service surface on standard Linux bare metal, and the implementation is real. An aws ec2 run-instances call provisions a virtual machine through QEMU. S3 objects go to Spinifex's built-in object store, which spreads them across nodes with Reed-Solomon erasure coding. IAM policies evaluate against real principals and enforce across real network boundaries.

Spinifex is built for production where AWS itself is unavailable: disconnected field deployments, air-gapped secure facilities, and data sovereignty rules that forbid sending data to infrastructure outside your control. It runs with no external control plane, makes no phone-home call, and installs from a release tarball with no internet access. The AWS CLI, Terraform with the AWS provider, eksctl, and any AWS SDK work against it with a single endpoint override.

Why these two get compared

Both tools answer aws s3 ls correctly, and Fakecloud's model-driven conformance means it answers a long list of other calls too. That breadth is what surfaces it next to Spinifex when a team searches for a way to run the AWS API off Amazon. The choice comes up whenever a team replacing LocalStack is also weighing where production will run.

Conforming to the API model and provisioning real infrastructure are different jobs. Fakecloud checks that your requests are well-formed and that your code handles the responses. Spinifex runs the workload. A suite that passes against Fakecloud tells you the integration code is correct. It does not tell you the VM will boot, the volume will survive a lost node, or the policy will deny the call it should deny.

How they fit together

Plenty of teams run both, at different stages of one pipeline. Fakecloud sits in development and CI, giving engineers a broad, quick AWS surface to build against with no account and no bill. Spinifex sits in production when that production is hardware the team controls, serving the same AWS API the application was written against.

The endpoint changes between stages. The application code does not. Teams whose production target is AWS finish with a validation pass on real AWS. Teams whose production target is their own hardware finish on Spinifex: the same API, running on the machines that are the production environment.

Get started

Fakecloud is at github.com/faiscadev/fakecloud, MIT-licensed and needing no account to run. Spinifex documentation, including the air-gapped installation guide for disconnected deployments, is at docs.mulgadc.com. The source is on GitHub, written in Go and AGPL-3.0 licensed. Or sign up for the free sandbox to explore the AWS-compatible API surface before deploying on your own hardware.

MiniStack vs Spinifex: AWS Emulator vs Production Platform

Tom — Thu, 10 Sep 2026 06:58:48 +0000

MiniStack and Spinifex both speak the AWS API. That surface similarity is what puts them in the same search results, but they're built for different stages of the software lifecycle. MiniStack is a development and CI testing tool. Spinifex is a production cloud platform. Teams that run both aren't hedging; they're using the right tool at each stage.

What MiniStack is

MiniStack is a free, MIT-licensed AWS emulator that emerged after LocalStack archived its Community Edition in March 2026. It runs on port 4566, covers 60+ AWS services, and requires no account or auth token. The Docker image is around 270 MB with roughly 30 MB idle memory, and startup is under two seconds.

The design choice that distinguishes MiniStack from other emulators is that it backs some services with real infrastructure. When your test code calls its RDS endpoint, a real PostgreSQL instance is handling the storage. ElastiCache maps to a real Redis instance. That backing means test behaviour for database-heavy workloads more closely mirrors what the production database will do, including edge cases in query behaviour that a pure mock might smooth over.

For teams whose biggest CI risk is database logic rather than AWS API surface coverage, MiniStack's real-infrastructure approach is a meaningful improvement over in-memory emulators.

What Spinifex is

Spinifex is an AWS-compatible cloud platform that runs on standard Linux bare metal hardware. It implements EC2, S3, IAM, EKS, and the rest of the common AWS service surface against real underlying infrastructure. When you call aws ec2 run-instances, it boots a real virtual machine using QEMU. EBS volumes are real block storage with real persistence. IAM policies are enforced across actual network boundaries. S3 is served by Predastore, which uses Reed-Solomon erasure coding to distribute objects across nodes so data survives hardware failures.

Spinifex runs fully offline, with no external control plane and no phone-home dependency. It installs from a release tarball on any x86_64 or ARM64 Linux server. The AWS CLI, Terraform with the AWS provider, eksctl, and any AWS SDK work against it with a single endpoint override.

Where they each fit

MiniStack belongs in your dev environment and CI pipeline. It gives your application code a realistic AWS surface to run against without cloud costs or credentials, and the real database backing means your ORM queries and migration code get a more honest workout than they would against a pure in-memory mock.

Spinifex belongs in production when that production environment is hardware you own. It's built for teams deploying to disconnected edge hardware, air-gapped secure facilities, and sovereign environments where data cannot leave infrastructure under direct control. The goal is that Terraform configs, IAM policies, and application code written for AWS run unchanged on your own hardware, because the API they're calling is the same API.

What emulators can't catch

MiniStack's real-database backing improves test fidelity for a specific class of problem, but the emulator model has structural limits that matter when correctness at the margins is the requirement.

An emulator intercepts API calls and returns plausible responses. What it doesn't do is enforce real IAM policy evaluation against real principals, manage real VM lifecycle state, or replicate the durability and concurrency behaviour of a production storage system under load. These aren't gaps in MiniStack specifically; they're inherent to the emulator category. Emulators are optimised for development speed, not production parity.

For teams whose production target is AWS, this gap is bridged by deploying to real AWS for final validation. For teams whose production target is hardware they own, there is no "real AWS" step in the pipeline. Spinifex is what fills that position: the same API, on the hardware that is the production environment.

Getting started

MiniStack documentation and installation instructions are at ministack.org. Spinifex documentation, including the air-gapped installation guide and Terraform workbooks, is at docs.mulgadc.com. The source is on GitHub, written in Go and AGPL-3.0 licensed. The free sandbox lets you test the API against a live Spinifex instance before deploying on your own hardware.

Floci vs Spinifex: AWS Emulator vs Production Platform

Tom — Wed, 09 Sep 2026 01:59:32 +0000

Floci and Spinifex both implement the AWS API surface, and that surface-level similarity puts them in the same search results. They're not alternatives to each other. Floci covers local development and CI. Spinifex covers production when that environment is hardware you own. Understanding why helps you use both without expecting either to do the other's job.

What Floci is

Floci is a free, open-source AWS emulator built to replace LocalStack Community Edition after LocalStack archived its free tier in March 2026. It's built on Quarkus and compiled to a native binary via GraalVM, which produces its headline numbers: startup time around 24ms and idle memory around 13 MiB. It covers 47 AWS services, requires no account or auth token, and is MIT-licensed.

The design intention is explicit drop-in compatibility. Floci listens on port 4566 and accepts the same credential pattern as LocalStack, so existing SDK configurations, Docker Compose setups, and CI scripts work without changes. It also translates LocalStack environment variables automatically for teams migrating from older configurations. Beyond AWS, it supports Azure and GCP endpoints, which is useful for codebases that target more than one cloud provider.

What Floci doesn't do is run real infrastructure. When your code calls s3.put_object, Floci intercepts that call and stores the data somewhere convenient for the test. There's no actual storage engine enforcing durability guarantees, no real IAM policy evaluation against a real principal, and no hypervisor managing virtual machine state. That's the correct trade-off for a development tool: speed and breadth of service coverage matter more than production-grade correctness when you're running a developer's inner loop or a CI job.

What Spinifex is

Spinifex is an AWS-compatible cloud platform for hardware you own. It implements EC2, S3, IAM, EKS, and the rest of the common AWS service surface on standard Linux bare metal, and the implementation is real: an aws ec2 run-instances call provisions an actual virtual machine using QEMU. S3 objects go to Predastore, which distributes them across nodes using Reed-Solomon erasure coding. IAM policies are evaluated against real callers and enforced across real network boundaries.

The use cases are production environments where AWS itself isn't available: disconnected field deployments, air-gapped secure facilities, and data sovereignty requirements that prohibit sending data to infrastructure outside your direct control. Spinifex runs without any external control plane, has no phone-home requirement, and installs from a release tarball with no internet access needed. The AWS CLI, Terraform with the AWS provider, eksctl, and boto3 all work against it with a single endpoint override.

Why these two get compared

Both tools answer aws s3 ls correctly. That's enough to surface both in the same search, and the question "should I use Floci or Spinifex?" comes up whenever a team with existing LocalStack infrastructure is evaluating on-premise options at the same time.

The architecture underneath is completely different, and the appropriate contexts don't overlap. Floci is optimised for startup time, low resource footprint, and broad service coverage in a container, because those are the properties that matter in a developer's inner loop. Spinifex is optimised for production reliability, real hardware management, and disconnected operation, because those are the properties that matter when bare metal is the production environment.

A benchmark between them would measure the wrong things. Floci starts in 24ms; Spinifex starts VMs on real hardware. Floci fits in a Docker container; Spinifex manages your infrastructure. Neither is trying to do what the other does.

How they fit together

Many teams use both across different stages of the same pipeline. Floci runs in the development environment and CI so that engineers can write and test code against AWS APIs without a cloud account or a cloud bill. Spinifex runs in the production environment when that environment is hardware the team controls, and provides the same AWS API surface that the application was developed against.

The endpoint changes between stages. The application code doesn't.

Get started

Floci is at github.com/floci-io/floci, MIT-licensed and requiring no account to run. Documentation for Spinifex is at docs.mulgadc.com, including the air-gapped installation guide for disconnected deployments. The source is on GitHub, written in Go and AGPL-3.0 licensed. Or sign up for the free sandbox to explore the AWS-compatible API surface before deploying on your own hardware.

Equinix Metal Shut Down: What Bare Metal Cloud Users Can Do Now

Tom — Mon, 07 Sep 2026 04:40:11 +0000

Equinix Metal went offline on June 30, 2026. If your infrastructure ran on it, you already know that: the API is gone, servers provisioned on the platform were wiped at the cutoff, and what was once an on-demand bare metal cloud with ten-minute provisioning times is now a 404. Equinix announced the shutdown in November 2024, which gave customers eighteen months to plan a migration, but knowing it was coming and knowing what to do next are two different things.

This post covers the options, what each one involves, and where each one makes sense.

What Equinix Metal was

Equinix acquired Packet in March 2020 for $335 million and rebranded the service as Equinix Metal. The value proposition was simple: dedicated physical servers, no hypervisor overhead, API-first provisioning in under ten minutes, and native integration to Equinix's Fabric interconnection network so you could reach cloud providers and private networks with low latency without building your own cross-connects. It sat in a gap that very few services filled: genuine bare metal performance with the kind of developer experience people expected from cloud VMs.

The shutdown came because Metal represented only around 1.25% of Equinix's revenue, and the company decided its future was in colocation, interconnection, and hyperscale rather than competing with AWS on compute. That's a reasonable business decision, but it leaves a real gap for the teams who built on it.

The honest options

There is no single direct replacement for what Equinix Metal was, because what made it valuable was the combination of physical performance, API-first control, and Equinix's interconnection fabric in a single product. Each migration path recovers some of that but not all of it.

Move to a managed bare metal provider

The most direct substitution is another bare metal cloud, and several have been actively courting Equinix Metal refugees. Latitude.sh markets itself specifically as an Equinix Metal replacement and offers a developer-friendly API, Terraform provider, and fast provisioning across a smaller number of locations. Hetzner offers bare metal dedicated servers with decent API support and competitive pricing, especially in Europe. OVHcloud covers a wider range of locations and has API-driven provisioning, though the experience is more configuration-heavy than either of the others.

The main trade-off with any of these is that you're still in someone else's data centre, on someone else's hardware, subject to their pricing changes and service decisions. You solve the immediate migration problem without changing the underlying dependency structure.

Move to a hyperscaler

AWS, GCP, and Azure all offer bare metal instance types, and if your workload was on Equinix Metal for performance reasons rather than cost or data residency reasons, moving to an AWS i4i.metal or a GCP bare metal option is technically straightforward. The existing AWS SDK and Terraform tooling transfers directly and you gain the full breadth of managed services around your compute.

The obvious cost is that bare metal in a hyperscaler is expensive relative to dedicated servers elsewhere, and egress costs compound quickly. For teams that chose Equinix Metal partly because hyperscaler economics didn't work for their workload, moving to AWS metal is probably not the answer, but for teams that valued the Equinix Fabric interconnection to those same hyperscalers, it removes an indirection layer entirely.

Own the hardware and bring your own cloud API

A smaller subset of Equinix Metal customers chose it not just for managed convenience but because they wanted hardware performance with a cloud-compatible API surface, and for some of them the managed nature of the service was a compromise rather than a requirement. For those teams, the migration path is colocation plus software that gives them the API layer back.

Spinifex is an open-source, AGPL-3.0 licensed cloud platform written in Go that implements the AWS API surface on hardware you own and operate. It covers EC2, S3, IAM, EKS, and more of the common AWS API surface, which means the same Terraform configs, AWS CLI scripts, and SDK integrations that worked against your Equinix Metal infrastructure or against AWS can be pointed at a Spinifex node in a colocation facility with a provider override:

provider "aws" {
  endpoints {
    ec2 = var.spinifex_endpoint
    iam = var.spinifex_endpoint
    sts = var.spinifex_endpoint
    eks = var.spinifex_endpoint
  }
}

Spinifex is not a managed service, and it is not a drop-in Equinix Metal replacement in the sense that Latitude.sh is. You take on the operational responsibility for the hardware: firmware, failure, and physical network uplinks. In return you get full control over the platform, no per-hour billing, and an AWS-compatible API surface your existing tooling already talks to. For teams with the operational appetite for it, and for teams with data sovereignty or security requirements that constrain which managed providers they can use, this is the migration path that preserves the most control.

The Equinix colocation business is still open, so one option is keeping your hardware in an Equinix facility and running Spinifex on it. You lose the API-driven bare metal provisioning that Metal provided, but you keep the Equinix Fabric interconnection that many teams valued for reaching cloud providers and private peers.

What to think about when choosing

The right path depends on a few things that are specific to each team's situation.

If the main value of Equinix Metal was the interconnection fabric, look at whether that can be reproduced in the new environment. Equinix's colocation and Fabric products are separate from Metal and still exist, and some managed bare metal providers have their own interconnection partnerships.

If the main value was the API-first provisioning and developer experience rather than the physical hardware specifically, moving to a hyperscaler or a well-provisioned managed bare metal provider is probably the cleanest migration.

If the main value was the combination of physical performance and a cloud-compatible API surface, and the workload has data residency or sovereignty requirements that constrain which managed providers are acceptable, owning the hardware with Spinifex providing the API layer is the path to evaluate.

If the deadline passed before a clean migration was in place, get workloads off any remaining dependencies on a service that no longer exists and onto something stable, even if that means a temporary home on a hyperscaler while the longer-term architecture is figured out.

Get started

Full Spinifex documentation, including the installation guide and Terraform workbooks for common infrastructure patterns, is at docs.mulgadc.com. The source is on GitHub, written in Go and AGPL-3.0 licensed. If you're working through a migration from Equinix Metal and want to talk through what makes sense for your specific situation, get in touch.

OpenStack vs Spinifex: Why AWS API Compatibility Changes the On-Prem Equation

Tom — Fri, 04 Sep 2026 00:25:20 +0000

The decision to move workloads off public cloud onto hardware you control usually comes with a secondary question that gets answered too late: what happens to the tooling? Terraform configs, CLI automation, IAM role structures, Kubernetes clusters provisioned with eksctl, all of that was written against the AWS API, and the answer to "does it work on our private cloud?" depends almost entirely on which private cloud platform you choose. OpenStack and Spinifex give different answers to that question, so let's dive into what they both are and where you'd pick either one.

What OpenStack actually is

OpenStack is the incumbent open source private cloud platform, governed by the OpenInfra Foundation and running at serious scale. According to the OpenInfra Foundation, OpenStack deployments now exceed 55 million cores in production worldwide, with organisations including Walmart, Workday, and CERN among the large-scale operators. Telecoms have leaned heavily on it for 5G and Open RAN backbone infrastructure through the StarlingX project. It is a mature platform with over fifteen years of production hardening behind it.

The core services cover the same ground as any cloud platform: Nova for compute, Neutron for networking, Cinder for block storage, Swift for object storage, Keystone for identity and authentication, Glance for image management, and Heat for orchestration. Each is a full project in its own right, with its own API, documentation, and upgrade lifecycle.

The operational reality

Deploying OpenStack for production use is not a weekend project. The most accessible deployment path today is Kolla-Ansible, which containerises OpenStack services and uses Ansible to orchestrate the install, and it has simplified what used to be an extremely manual process. The official documentation acknowledges that Kolla "permits operators with little experience to deploy OpenStack quickly," which is true in the sense that a motivated team can get a cluster running, but running it at production quality and knowing how to troubleshoot failures across distributed containerised services still requires operational expertise. OpenStack networking in particular, built on Neutron with OVN or OVS, has a learning curve that most teams underestimate.

For organisations with a dedicated cloud operations team, this is a reasonable trade. Engineering teams whose core expertise is software development rather than infrastructure operations will carry the operational overhead with less to absorb it.

The AWS API question

The challenge for teams moving from AWS tooling is that OpenStack has its own API surface. Nova is not EC2, Cinder is not EBS, and Keystone is not IAM. Terraform resources written for AWS use the aws provider and EC2/EBS/S3 resource types, and those don't translate to OpenStack without a rewrite using the OpenStack provider.

There was an OpenStack project called ec2-api that provided an AWS EC2 compatibility wrapper for OpenStack, but that project is retired and no longer maintained. An organisation moving workloads from AWS to OpenStack is taking on a migration project at the Terraform and automation layer, not just at the infrastructure layer. Every aws_instance, aws_security_group, and aws_eks_cluster resource in your configurations needs to be rewritten for the OpenStack equivalents.

Your existing AWS tooling transfers to Spinifex without modification. It does not transfer to OpenStack without rewriting it.

What Spinifex does differently

Spinifex takes the opposite approach to the API question. Rather than building a new cloud platform with its own API surface, it implements the AWS API on hardware you own, covering EC2, S3, IAM, EKS, and the rest of the common AWS service surface. The endpoint changes; the API does not. A Terraform config that targets AWS today can target a Spinifex node with a single provider block override, and the resource definitions, modules, variable files, and state management stay exactly as they are.

The operational profile is also different. Spinifex runs as a single platform on standard Linux hardware, coordinated by NATS and managed by systemd, with no separate etcd cluster and no external control plane components. It also installs and runs in fully air-gapped environments with no internet connectivity, which is a requirement OpenStack can satisfy in principle but which requires additional planning and configuration to achieve.

Spinifex is AGPL-3.0 licensed and written in Go, with the source at GitHub.

When OpenStack is the right choice

OpenStack is the right choice when the scale and multi-tenancy requirements of the deployment justify its operational complexity. Service providers running public or community cloud infrastructure, telecoms deploying 5G core, and large enterprises with dedicated cloud operations teams are the natural users of OpenStack, and it serves them well. If you need a platform that hundreds of teams can share with strong tenant isolation and a mature ecosystem of plugins, integrations, and management tooling built up over fifteen years, OpenStack is where you start looking.

When Spinifex is the right choice

Spinifex is the right choice when your team has existing AWS tooling and the requirement is to run that tooling on hardware you own, without a migration project at the automation layer. Disconnected environments, data sovereignty requirements, and edge deployments are where the AWS API compatibility matters most. Teams that can't justify a dedicated cloud ops function benefit from Spinifex's simpler operational profile.

Before choosing between them, ask what your team needs to operate the platform and whether you have it. For teams whose existing capability is AWS, that question often determines the outcome before the feature list does.

Get started

Platform documentation for Spinifex, including the air-gapped installation guide and Terraform workbooks for common infrastructure patterns, is at docs.mulgadc.com. The source is on GitHub. OpenStack documentation and deployment guides are at docs.openstack.org, and the OpenInfra Foundation can be found at openinfra.org. Or sign up for the Spinifex free sandbox to explore the AWS-compatible API surface before deploying on your own hardware.

VMware Alternatives in 2026: Where Teams Are Landing After the Broadcom Pricing Shock

Tom — Thu, 03 Sep 2026 00:02:54 +0000

Broadcom completed its $69 billion VMware acquisition in November 2023 and within weeks eliminated every perpetual license. Customers moved to subscription-only terms, forcing small deployments into bundles sized for enterprise. Standalone vSphere customers reported price increases of 800 to 1,500%. AT&T sued after receiving a quote representing a 1,050% increase. Customers already running the full VMware Cloud Foundation bundle — vSphere plus vSAN plus NSX — saw prices hold roughly flat or fall around 50%, but anyone running vSphere on its own absorbed the full shock.

A CloudBolt survey published in early 2026 found that 86% of respondents were reducing their VMware footprints, with just over half planning phased transitions rather than full replacements.

Where teams are landing

Proxmox is the clearest beneficiary. Community subscriptions and forum traffic grew substantially after the Broadcom announcement, and it is consistently the first alternative named in VMware migration threads across r/sysadmin, r/homelab, and enterprise IT forums. Proxmox is open source, runs on the same x86 hardware VMware ran on, and manages VMs and containers through a familiar web interface with no licensing floor.

Other destinations include Nutanix, which has been pointed in its VMware-refugee marketing, OpenStack for teams already familiar with it, and public cloud for workloads where on-premise was never a compliance requirement.

The gap Proxmox does not fill

Proxmox replaces the hypervisor and gives you a working KVM environment. It does not give you the AWS API surface.

Teams that spent years building Terraform modules against the AWS provider, writing IAM policies, running eksctl for Kubernetes cluster provisioning, and scripting against the AWS CLI now face a choice: learn a new operational model on Proxmox from scratch, or find something that brings the API surface they already know to the hardware they are migrating to.

Spinifex (github.com/mulgadc/spinifex, AGPL-3.0, Go) runs on standard Linux bare metal, which means it runs on the same hardware you are already evaluating for your post-VMware migration. It implements EC2, S3, IAM, EKS, ECS, ECR, VPC, and EBS through the AWS API that your existing tooling already speaks. A Terraform config that provisions infrastructure on AWS provisions the same infrastructure on Spinifex with a single provider endpoint override. The eksctl and kubectl workflows, the IAM role structures, the AWS CLI scripts all run unchanged.

Teams rebuilding private cloud after VMware need a hypervisor to replace vSphere and an operational model to replace the management layer they had built around it. Proxmox answers the first question. For teams whose operational model was built on AWS tooling, Spinifex answers the second.

The licensing parallel

Broadcom's move from perpetual licences to subscription minimums is worth noting because it shapes how teams evaluate everything that comes after VMware. Spinifex is AGPL-3.0, meaning the source is available, auditable, and free to use with no minimum core count and no subscription floor. Documentation including the multi-node setup guide and hardware reference architectures is at docs.mulgadc.com.

For teams that watched a perpetual VMware licence turn into an 800% price increase, the AGPL licence and open source development model is not a footnote.

Get started

Spinifex documentation, including the multi-node setup guide and hardware reference architectures, is at docs.mulgadc.com. The source is at GitHub, AGPL-3.0 licensed and written in Go. Or sign up for the free sandbox to explore the AWS-compatible API surface before deploying on your own hardware.

Every Tool That Implements the AWS API in 2026

Tom — Tue, 01 Sep 2026 23:55:02 +0000

The AWS API has become infrastructure's common language, and a whole ecosystem has grown up around running it somewhere other than AWS. Some tools mock it for testing. Others implement it for real. Knowing which is which saves you from deploying a dev tool to production or wiring a production platform into your CI pipeline.

Two categories

The tools split into emulators and real cloud platforms. Emulators intercept AWS API calls and return plausible responses without provisioning real infrastructure, where state is usually ephemeral, VMs never boot, and the goal is behavioural approximation fast enough for a developer's inner loop. Real cloud platforms provision actual infrastructure where EC2 calls boot real virtual machines and block storage carries real persistence guarantees.

Emulators

Moto

Moto (github.com/getmoto/moto, Apache 2.0, 8,400+ stars) has been around since 2013, making it the oldest option here. It works differently from the rest because rather than running a local server, it patches boto3 calls in-process through a test decorator. A function wrapped in @mock_aws intercepts all AWS SDK calls and returns mock responses without any network traffic. This makes it fast and easy to drop into Python test suites, but it only works for Python. Teams using the AWS CLI, Terraform, or Go SDKs need a server-based option.

LocalStack

LocalStack (github.com/localstack/localstack, 64,000+ stars) is the dominant name in local AWS development. It runs as a Docker container exposing the AWS API on localhost:4566 and covers over 120 services. In March 2026, LocalStack archived its Community Edition repository and moved core services behind a paid plan. A free tier remains for non-commercial use and open source projects, but the Base plan covering Cloud Pods persistent state costs $39 per month and the Ultimate plan runs $89 per month. Teams that depended on CE for commercial CI pipelines are now evaluating alternatives.

Floci

Floci (floci.dev, github.com/floci-io/floci, MIT, 22,800+ stars) launched in March 2026 as a direct response to the LocalStack CE archival. It covers 84 AWS services on localhost:4566, requires no account, collects no telemetry, and ships as a single Docker image built on Quarkus and GraalVM native. The result is a 24ms startup time and a 13 MiB idle memory footprint. The star count reflects genuine demand from teams who wanted a zero-friction replacement and found one fast.

Fakecloud

Fakecloud (fakecloud.dev, github.com/faiscadev/fakecloud, MIT, ~500 stars) covers 105 services and 7,396 operations, claiming full Smithy conformance against the AWS service model. The binary is around 19 MB and idles at roughly 10 MiB. Services include S3, DynamoDB, SQS, Lambda, IAM, STS, ECS, ECR, EC2, RDS with six real database engines, Bedrock, and 80+ more. It is a newer and smaller project than Floci but more ambitious in scope.

MiniStack

MiniStack (github.com/ministackorg/ministack, MIT, 4,300 stars) covers 60+ services including S3, SQS, DynamoDB, Lambda, SNS, IAM, STS, Kinesis, EventBridge, Secrets Manager, SSM, CloudWatch, and SES. It supports Terraform, boto3, the AWS CLI, and CDK, and handles multi-account and multi-region configurations. The multi-region support puts it ahead of simpler options for teams testing region-aware workloads.

Real cloud platforms

Ubicloud

Ubicloud (github.com/ubicloud/ubicloud, AGPL-3.0, Ruby, 12,300 stars) is a managed cloud service running on Hetzner and Leaseweb hardware. It offers elastic compute, block storage, firewall, load balancer, managed Postgres, Kubernetes, AI inference endpoints, and IAM, at prices running 3 to 10x lower than equivalent AWS services. Teams evaluating it should understand that Ubicloud is a hosted service accessed over the internet rather than software you deploy on your own hardware. Moving to Ubicloud means moving from one cloud to a cheaper cloud.

Spinifex

Spinifex (github.com/mulgadc/spinifex, AGPL-3.0, Go) implements EC2, EBS, S3, VPC, IAM, EKS, ECS, ECR, and RDS on hardware you own, with no external control plane and no internet requirement. An aws ec2 run-instances call boots a real VM via QEMU. S3 calls go to an erasure-coded object store. IAM policies enforce against real network boundaries. The same Terraform configs, eksctl workflows, and AWS CLI scripts that run against AWS run against Spinifex with a single provider endpoint override.

Spinifex targets environments where data cannot leave hardware under direct control and where the infrastructure needs to operate with no external dependencies, covering air-gapped facilities, edge deployments, and sovereign environments. Full documentation including air-gapped install and reference architectures for specific hardware is at docs.mulgadc.com.

What to use when

For Python test suites, Moto is the natural choice because it is in-process, fast, and has been maintained for over a decade. For local dev or CI in any language, Floci offers the smallest footprint with zero account requirements, LocalStack offers the widest service coverage for teams already on a paid plan, and MiniStack or Fakecloud fill the gap for multi-region needs or specific services those two cover. For a cheaper cloud alternative where connectivity is not a concern, Ubicloud cuts the bill without changing the operational model. For hardware you own, Spinifex runs the AWS tooling you have already built on infrastructure that never calls home.

Most teams end up using something from both categories because an emulator covers dev and CI while a real platform handles production or sovereign workloads. The endpoint changes; the code does not.

Ubicloud vs Spinifex: Two Approaches to Open Source Cloud

Tom — Tue, 01 Sep 2026 23:30:41 +0000

The phrase "open source alternative to AWS" covers a lot of ground. It can mean a dev-time emulator, a managed service that runs on someone else's hardware, or software you install on bare metal you own and operate entirely within your own network. Ubicloud and Spinifex are both open source, both AGPL-3.0 licensed, and both designed to give teams cloud-like compute without the AWS bill. But they are built for different problems, and picking the wrong one for your context costs real time to undo.

What Ubicloud is

Ubicloud is a YC-backed open source cloud platform written in Ruby. It provides elastic compute via virtual machines, block storage (non-replicated), virtual networking with firewalls and load balancers, managed Postgres with automatic backups and point-in-time restore, Kubernetes, GitHub Actions runner integration, AI inference, and attribute-based access control. You can self-host it on bare metal from providers like Hetzner or Leaseweb, or use their managed service which runs on the same bare metal providers and handles the operational overhead for you.

Ubicloud gives you cloud convenience at a cost closer to bare metal pricing, with the option to avoid the operational burden of managing it yourself. For teams whose primary motivation is reducing their AWS bill rather than taking infrastructure fully in-house, this is a practical path.

What Spinifex is

Spinifex is an open source AWS-compatible cloud platform, written in Go and AGPL-3.0 licensed, that runs on standard Linux bare metal hardware you own and operate. Rather than defining a new cloud API, it implements the AWS API itself, covering EC2, S3, IAM, EKS, and the rest of the common AWS service surface, so the Terraform configs, CLI scripts, IAM roles, and SDK integrations your team has already written work against it without modification. The endpoint changes; the tooling doesn't.

Spinifex imposes one hard constraint: no external control plane, no phone-home, no dependency on any infrastructure outside the boundary you define. It runs air-gapped, in classified facilities, at the tactical edge, and in any environment where traffic to a US-headquartered cloud provider is either technically impossible or operationally prohibited.

Where the two products diverge

The key difference is not the feature list but the deployment model and what it implies about your operational context.

Hosting model. Ubicloud runs on provider hardware, either managed by Ubicloud or self-managed by you on Hetzner or similar. Your data and compute still live on a third party's physical infrastructure. Spinifex runs on hardware you own, in a facility you control, with no third party in the stack below the OS. For most cost-reduction use cases this distinction doesn't matter. For organisations with data sovereignty obligations, regulatory constraints, or contractual requirements around physical infrastructure ownership, it is the whole point.

AWS API compatibility depth. Ubicloud provides cloud-like services but does not expose the AWS API surface directly. Your Terraform configs written for AWS, your eksctl commands, and your aws ecr get-login-password calls won't work against Ubicloud without changes because Ubicloud has its own interface layer rather than the AWS API. Spinifex implements the AWS API itself, so existing tooling and automation work against it without modification. The endpoint changes; nothing else does.

Disconnected operation. Ubicloud is designed for connected infrastructure, either cloud-hosted or hosted on a connected bare metal provider. There is no air-gap installation path and no documented support for fully disconnected operation. Spinifex installs from a tarball with no internet dependency and runs with no ongoing external connectivity required, which makes it the appropriate choice for edge deployments, industrial sites, and environments where network egress is restricted or prohibited.

S3 and block storage. Ubicloud's block storage is non-replicated by design. Predastore, Spinifex's S3 implementation, uses Reed-Solomon erasure coding to distribute objects across nodes so that a node failure doesn't result in data loss. Teams that need the durability model AWS S3 provides should factor this in.

Managed database. Ubicloud has an advantage here. Its managed Postgres offering includes automatic backups, point-in-time restore, and high availability, comparable to RDS in terms of operational convenience. Spinifex exposes an RDS-compatible API for database connectivity, but the database management layer is your responsibility. For teams that want managed Postgres without the AWS bill, Ubicloud is the stronger choice for that service specifically.

Which one is right for a given situation

For teams whose goal is reducing cloud costs while remaining on hosted infrastructure and who want a managed service option, Ubicloud is a reasonable choice. The Ruby codebase has an active community, the managed service option lowers the operational entry bar, and the managed Postgres offering covers a gap that Spinifex doesn't fill at the same level.

For teams whose requirements include hardware ownership, disconnected operation, air-gapped installation, or AWS API compatibility so that existing Terraform and CLI tooling transfers without changes, Spinifex is the appropriate platform. It's also the more natural choice for defence, government, and regulated industry contexts where the deployment environment may be a Pelican case at a forward operating position or a classified facility with no external network routes at all.

The two products share a broad category label but address different operational contexts. Evaluate each against the environment you're actually deploying into.

Get started

Spinifex documentation, including reference architectures and the air-gapped install guide, is at docs.mulgadc.com. The source is at GitHub, AGPL-3.0 licensed and written in Go. Ubicloud's source and documentation are at github.com/ubicloud/ubicloud. Or sign up for the Spinifex free sandbox to explore the AWS API surface before deploying on your own hardware.

LocalStack vs Spinifex: the Right Tool for Dev, the Right Tool for Production

Tom — Tue, 01 Sep 2026 00:57:06 +0000

LocalStack versus Spinifex comes up often enough to address directly. They don't compete because they solve different problems at different points in the software lifecycle. Conflating the two leads to reaching for the wrong tool and being frustrated when it doesn't fit.

What LocalStack is for

LocalStack is an AWS emulator. You run it locally in a Docker container and it intercepts calls to AWS API endpoints, returning responses that closely approximate what the real AWS would return. It covers over 120 services and understands the same SDKs, CLI commands, and Terraform provider that you use against real AWS. For local development and CI testing, it's excellent: you can write a Lambda that reads from S3, test it locally against a LocalStack instance, and be confident the code will behave the same way in AWS without incurring API costs or requiring a real AWS account to be wired into your local dev loop.

The emulation is not perfect at the edges, and LocalStack itself is clear that it's a development tool rather than a production platform. State is ephemeral by default, meaning a container restart loses everything. There are no real virtual machines being managed, no actual block storage with persistence guarantees, and no genuine network enforcement between services. The goal is behavioural approximation fast enough to run in a developer's inner loop, not correctness guarantees at the margins.

In March 2026, LocalStack archived its Community Edition GitHub repository and moved core services behind a paid plan, which drew a strong reaction from the developer community given the project had accumulated over 64,000 GitHub stars. A permanent free tier remains available for non-commercial use, and students and open-source projects can access the full suite without charge, but the Base plan covering persistent state via Cloud Pods costs $45 per month. That change is largely why "LocalStack alternative" has become a high-volume search query, and it's a reasonable frustration for teams that relied on CE for commercial CI pipelines.

What Spinifex is for

Spinifex is not a development tool and not an emulator. It implements the AWS API surface on real bare metal hardware so that the hardware you own becomes the production environment, while preserving every piece of AWS tooling you've already built competency around. EC2 calls provision actual virtual machines with real CPU and memory allocation. EBS volumes are actual block storage with real persistence guarantees. IAM policies are enforced across real network boundaries. The S3-compatible object storage layer, Predastore, distributes objects across nodes using Reed-Solomon erasure coding so data survives node failures.

The use case is environments where AWS itself isn't available or appropriate: disconnected field deployments, air-gapped secure facilities, data sovereignty requirements that prohibit data leaving infrastructure under your direct control, and workloads where owning the hardware is more economical than cloud compute and egress costs. Spinifex runs without any external control plane or cloud dependency and installs from a release tarball with no internet access required.

Why the comparison comes up and what it gets wrong

These two tools get compared because they both speak the AWS API. If you run aws s3 ls against a LocalStack instance or against a Spinifex instance, you get the same command syntax and a similar response format. The surface-level similarity creates the impression they're doing similar things, but the underlying architecture is completely different and the appropriate use cases don't overlap.

LocalStack is optimised for speed and breadth of service coverage in a single Docker container, because those are the properties that matter for a dev inner loop. Spinifex is optimised for production reliability, real hardware management, and disconnected operation, because those are the properties that matter when the hardware you're running on is the production environment. Neither tool is trying to do what the other does.

The analogy is SQLite versus PostgreSQL. SQLite is an excellent embedded database and the right choice for a huge range of applications. PostgreSQL is a production database server designed for concurrent multi-user workloads with real persistence and replication. They both speak SQL. Choosing between them isn't really a comparison because the contexts in which each is correct don't overlap, and a benchmark between them would be measuring the wrong things.

When to use each

LocalStack is the right answer if you're writing application code against AWS APIs and you want a fast, cheap, offline-capable way to run that code in your local dev environment or CI pipeline without hitting real AWS. The free tier covers non-commercial use, and even the paid plans are inexpensive relative to the time and API cost savings for a team running hundreds of CI builds a day. If you've moved from the Community Edition and want a free alternative, Floci and MiniStack are MIT-licensed emulators that appeared in early 2026 and cover similar territory.

Spinifex is the right answer if the hardware you're running on is the production environment and you want that hardware to behave like AWS, rather than approximating AWS behaviour in a dev mock. The Terraform configs, IAM policies, CLI scripts, and SDK integrations you've written for AWS work against Spinifex without modification because the API is identical, not approximated. Spinifex is driven by operational requirements: a disconnected edge deployment, a data sovereignty obligation, or a cost calculation at scale.

Many teams run both: LocalStack or an equivalent in their dev and CI environments for the same reasons they've always used it, and Spinifex for the production edge or sovereign deployment that the real workload targets. The endpoint your application points at changes; the code doesn't.

Get started

Full Spinifex documentation is at docs.mulgadc.com, including the air-gapped installation guide for disconnected deployments. The source is on GitHub, written in Go and AGPL-3.0 licensed. Or sign up for our free sandbox to explore the API surface against a live instance before deploying on your own hardware.