Scalix vs Fly.io
Fly.io is a mature public cloud that has refocused on Sprites: persistent, hardware-isolated Linux computers for AI agents. Scalix is a cloud platform written as one system, where database, inference, compute, storage and auth sit behind one identity model, one key and one usage ledger.
Both platforms run microVMs, so isolation is a tie and we say so below. Fly is ahead on regions, scale, support and years of production hardening, and those rows are in the table too. Every claim about Fly here is sourced from Fly’s own documentation, blog or pricing pages, cited inline.
What each platform is for.
These are not the same product with different logos. They solve overlapping problems from opposite starting points, and the right choice follows from which problem you actually have.
Fly.io: the computer
Fly describes a Sprite as a hardware-isolated execution environment for arbitrary code, a persistent Linux computer, and positions it as the simplest answer to where a blob of code should run. It comes up in about a second from pre-warmed pools, checkpoints in roughly 300 ms, keeps a 100 GB thin-provisioned filesystem billed on bytes written, and Fly documents no compute charge while idle.
Choose this shape when the agent mostly needs somewhere durable and safe to execute, and you are content to compose the database, object storage and model calls yourself.
Scalix: the platform
Scalix is a managed cloud platform written as a single system in Rust: a purpose-built storage engine speaking the Postgres wire protocol, containers and functions on hardware-isolated microVMs, object storage, auth, DNS and inference behind one gateway, one identity system and one metering ledger.
Choose this shape when the agent needs the whole stack, and you would rather hold one credential and read one error surface than integrate four vendors and reconcile four bills.
Where the differences are real.
Rows are included only where the difference is verifiable and material. Where Fly is ahead, the row says Fly. Where the two platforms simply made different bets, the row says so rather than inventing a winner.
Sprites run as Fly Machines, which Fly describes as "approximately OCI containers repackaged as KVM micro-VMs", with an inner container boundary and outbound network policy.
Untrusted code runs in hardware-isolated microVMs with a per-workload jail and cgroup limits.
Sprites are persistent Linux computers: an ext4 filesystem thin-provisioned to 100 GB billed on bytes written, live checkpoints in roughly 300 ms, and restore to any checkpoint.
Sandboxes are ephemeral, persistent or scheduled, each with its own database branch. There is no checkpoint and restore of a whole running filesystem.
Managed Postgres is first-party and mature: high availability, backups, connection pooling, pgvector and PostGIS. Fly documents Postgres 16.
First-party Postgres-compatible engine on Postgres 16, 17 and 18, with database branching and point-in-time recovery in the same system.
Managed Postgres runs in 12 regions: ams, fra, gru, iad, lax, lhr, nrt, ord, sin, sjc, syd and yyz.
One region today, in the EU. India is next. If you need a specific market now, Fly covers more ground.
Object storage and Redis are operated by third parties. Fly’s pricing page states: "When you provision their services, you become their customer, and you pay their list prices via your monthly Fly.io bill."
First-party object storage on the same API key, the same access-control model and the same usage ledger as the database and compute.
No first-party model inference API. Connectors broker authenticated calls from a Sprite out to third-party providers without the Sprite holding the credential.
First-party inference endpoint behind the same gateway and the same key, with tokens metered into the same ledger as compute and storage.
Scoped, expiring macaroon tokens for the Fly platform, which is a strong auth primitive. Sprites authenticate separately with a SPRITES_TOKEN against api.sprites.dev, and third-party services issue their own keys.
One identity system and one scope model. A single scoped key is accepted across database, storage, inference and deploy.
Sprites meter CPU time, memory time and storage. Third-party services bill at their own list prices and appear as line items on the Fly invoice. Organizations roll up into a parent billing organization.
One meter registry and one usage table across every service. A test in continuous integration fails the build if a priced meter has no emitter.
A remote MCP server with OAuth 2.1, published to the MCP registry, exposing 18 tools that are all Sprite-scoped. The fly mcp commands in flyctl are marked experimental.
MCP spans the platform, not one product: create a project, deploy and roll back a service, scale it, branch a database, run queries and migrations, create a storage bucket, invoke a function, add a domain and check usage.
Fly has published the view that "In 2026, MCP is the wrong way to extend the capabilities of an agent. The emerging Right Way to do this is command line tools and discoverable APIs."
We took the other side and made MCP a first-class interface to the control plane. Reasonable engineers disagree here, and Fly argued their case in public.
Quota and scope shaped: restricted tokens can cap sprite count, pin a name prefix, scope to a label and expire, with per-connector endpoint allow and block lists enforced on every call.
Approval shaped, and currently narrower: destructive SQL is gated behind a two-step confirmation token or an out-of-band human approval. Storage, deploy and domain deletions are not yet gated.
More than 37,000 customers, more than 8,000 of them described as agent-native, and a $25M Series D co-led by Dell Technologies Capital and Intel Capital announced on 24 July 2026.
Two engineers, pre-revenue, launched publicly this year. On track record there is no argument to have.
Paid support plans are published: Standard at $29 per month, Premium at $199 per month, Enterprise from $2,500 per month.
No SLA yet. Support is direct access to the two people who built the platform, which suits some teams and disqualifies us for others.
A public cloud running its own fleet in its own regions. We found no documented bring-your-own-cloud, on-premises or operator-deployable offering. Compliance posture is SOC 2 practices and HIPAA with a BAA.
Built to be deployed as a Scalix region inside a data centre operator’s own facility. The onboarding path and charts exist; no partner region is live yet, so treat this as the plan and not the record.
Fly.io figures are taken from Fly’s public documentation, blog and pricing pages as of 28 July 2026. Pricing and capabilities on both sides change; verify current details with each provider before you commit. If you believe a row here is wrong or unfair, tell us and we will correct it.
One system, or composed services.
Strip away the feature rows and one structural difference is left. It is not isolation, and it is not performance. It is whether the pieces were built together or assembled.
Composed services
On Fly, an agent that needs compute, a database, a bucket and a model call assembles them: Sprites authenticating with a SPRITES_TOKEN against api.sprites.dev, Managed Postgres with its own connection credentials, object storage from a third-party operator, and inference from another provider brokered through Connectors. Fly’s pricing page describes the third-party arrangement plainly:
“Fly.io offers managed services operated by third parties, such as Tigris Object Storage and Upstash Redis. When you provision their services, you become their customer, and you pay their list prices via your monthly Fly.io bill.”
This is a deliberate partner strategy, not a shortcoming. It gets a customer to specialist products quickly, run by teams who do that one thing well. The cost is that the customer, or the agent acting for them, carries the seams.
One system
Scalix was written the other way. There is one identity system with one scope model, and a single scoped key is accepted by the database, object storage, inference and deploy paths alike. There is one meter registry and one usage table, so database compute, storage bytes, inference tokens and vCPU hours land in the same ledger and reconcile against each other.
A test in continuous integration fails the build if a priced meter has no emitter. That is an unusual thing to enforce, and it is the part of this we are most confident about: a price cannot exist in the catalog without code that actually emits it.
Two honest caveats. The Postgres wire path also accepts a per-database password as an alternative to the platform key, so the accurate statement is that one key works across all of it, not that no other credential exists. And a consolidated invoice is aggregation; we can only speak to the customer-visible surface on either side.
Why this matters more for an agent than for a person
A human engineer absorbs integration cost once. They read four dashboards, store four secrets, learn four error formats, and then it is done. An agent pays that cost on every run. Each additional credential is another secret to hold and another way to leak it, each additional service is another error vocabulary to interpret, and each additional bill is another number the agent cannot reconcile against its own actions. One credential and one error surface is not an aesthetic preference at that point, it is a reduction in the number of ways an autonomous run can go wrong. That is the bet we made, and it is the reason to look at Scalix rather than at a better sandbox.
Which one you should pick.
There are real cases where Fly is the correct answer and we would say so on a call. Here they are in writing.
Choose Fly.io if
- You need a durable computer for an agent and little else. Sprites are purpose-built for exactly that, and checkpoint and restore of a whole running filesystem is a capability we do not have.
- You need a database close to a specific market today. Fly runs Managed Postgres in 12 regions; we run one.
- You need a support contract with a commercial commitment behind it. Fly publishes support plans from $29 per month. We do not offer an SLA yet.
- You are buying on operating history. More than 37,000 customers and years of production hardening is a real answer to a real risk, and we cannot match it.
- You already run on Fly Machines. Sprites are Fly Machines underneath, so staying put is the shorter path.
- You prefer command line tools and skills over MCP as the way an agent drives infrastructure. Fly has published that position and built for it deliberately.
Choose Scalix if
- Your agent needs more than compute. Database, object storage, inference and a deploy target under one credential and one meter is the case we are built for.
- You want the control plane itself operable by an agent, not just the sandbox the agent runs code in.
- You want destructive SQL to pause for a human. Isolation cannot help when the agent is authorised to drop the table.
- You want database branching next to the compute rather than as a separate purchase, and point-in-time recovery on the same machinery.
- You want first-party inference on the same key and the same bill as the rest of your infrastructure.
- You are planning for a Scalix region inside your own facility. Talk to us early, because this is a roadmap conversation and not a purchase today.
What we have not built yet.
A comparison page written by one of the two vendors is worth reading only if it discloses its own gaps first. Ours, plainly.
Two engineers
Scalix is built by two people. That is why it is one system, and it is also a concentration risk you should price into your decision.
One region today
We run one region, in the EU, with India next. Fly documents Managed Postgres in 12 regions. If you need presence in a market we do not serve, we are the wrong choice this quarter.
No SLA yet
We do not publish an availability commitment, because we are not yet in a position to stand behind one. Uptime is published at status.scalix.world instead.
Approval gates cover SQL only
Two-step confirmation and out-of-band human approval are real and enforced for destructive SQL. Deleting a bucket, removing a service or removing a domain is not gated yet.
Missing managed services
No managed Redis, Kafka or CDN today. Those are roadmap, and if one of them is load-bearing for you then the gap is a real one.
Operator regions are a plan
Node onboarding, deployment charts, and region and residency as first-class concepts are all built. No data centre partner is live. It is the plan, not the record.
Frequently asked questions
Is Scalix a Fly.io alternative?
For part of what Fly does, yes. If you are running containers, functions and a Postgres database and you want one credential and one bill across all of it, Scalix is a direct alternative. If what you need is a persistent, checkpointable Linux computer for an agent, Fly Sprites is a more specialised product than anything we ship, and we would point you there.
Do Scalix and Fly.io use the same isolation technology?
Effectively yes, and this is a tie. Fly describes Fly Machines as approximately OCI containers repackaged as KVM micro-VMs, with an inner container boundary and outbound network policy. Scalix runs untrusted code in hardware-isolated microVMs with a per-workload jail and cgroup limits. Anyone telling you one of these is fundamentally safer than the other is selling something. Isolation is not our differentiator.
What is the difference between Fly Sprites and Scalix Sandboxes?
Scope. A Sprite is a persistent Linux computer with a 100 GB thin-provisioned filesystem, live checkpoints in roughly 300 ms and restore to any checkpoint, and Fly documents no compute charge while it is idle. A Scalix Sandbox is an isolated environment that comes with its own database branch, file system and code execution, and it is wired into the rest of the platform on the same key. Sprites are the better standalone computer. Sandboxes are the better fit when the agent also needs the database, storage and inference beside them.
Does Fly.io have an MCP server?
Yes. Fly ships a remote MCP server with OAuth 2.1, published to the official MCP registry, exposing 18 tools. Every one of those tools is Sprite-scoped: creating a sprite, executing commands, managing checkpoints, services and network policy. There are no tools for provisioning a database, creating a bucket, deploying an app to Machines, or reading usage. The fly mcp commands inside flyctl are marked experimental. The honest difference is scope, not existence.
Can an AI agent operate the whole Scalix platform over MCP?
Most of it. Over MCP an agent can create a project, deploy a container and roll it back, scale a service, branch and drop a database branch, run queries and migrations, inspect a schema, create a storage bucket and upload to it, invoke a function, add and verify a domain, run code in a sandbox and check its own usage. Two things worth knowing: creating a database itself is a REST call to POST /v1/databases rather than an MCP tool, and log reading is not on the MCP surface today, so logs come from the console or the CLI.
Does Fly.io offer object storage and AI inference?
Object storage and Redis are available on Fly, operated by third parties. Fly’s own pricing page is explicit about what that means: when you provision those services you become that vendor’s customer and pay their list prices via your monthly Fly.io bill. On inference, Fly has no first-party model API. Their Connectors feature instead brokers authenticated calls from a Sprite out to third-party providers so the Sprite never holds the credential, which is a well-designed answer to a different question.
Which platform has more regions?
Fly, clearly and by a wide margin. Fly documents Managed Postgres in 12 regions across North America, Europe, Asia Pacific and South America. Scalix runs one region today, in the EU, with India next. If low latency in a specific market is a hard requirement this quarter, that is a reason to choose Fly and we would rather you heard it here than found out after signing up.
Does Scalix offer an SLA?
Not yet. We are two engineers, we run one region, and we are not going to publish an availability commitment we cannot yet stand behind. Uptime is published at status.scalix.world so you can judge the record rather than the promise. Fly publishes paid support plans starting at $29 per month; if a contractual commitment is a procurement requirement, that gap is real.
How does database branching work on Scalix?
You branch from a backup to a point in time, and the branch carries your data. Each branch gets its own compute and is fully isolated from the parent, so an agent can be handed a branch, allowed to make a mess, and have the branch dropped afterwards. Point-in-time recovery runs on the same machinery.
Can I run Scalix in my own data centre?
That is what the platform is designed for, and it is not something you can buy today. The node onboarding path, the deployment charts and region and residency handling as first-class concepts are all built. No partner region is live yet. If you operate a data centre and this is interesting, the useful conversation is a pilot, not a purchase.
How do Fly Sprites and Scalix Run pricing compare?
They are not directly comparable, and any table that puts the rates side by side without saying so is misleading you. Fly meters Sprites on cumulative CPU time actually consumed at $0.07 per CPU-hour plus $0.04375 per GB-hour of memory, which is well suited to bursty agent work and can be very cheap for it. Scalix Run meters allocated capacity while a service is awake at $0.036 per vCPU-hour plus $0.004 per GiB-hour, billed per second, and the meter stops when the service scales to zero. For a spiky agent session Fly’s consumption model may cost less; for a service holding steady capacity the Scalix rate is lower. Model your own workload rather than trusting either headline number.
Judge it against your own workload
The fastest way to settle a comparison is to deploy something. Create a project, point an MCP client at the platform, and watch an agent deploy a service and read its own usage back. If Fly turns out to be the better fit for what you are building, that is a good outcome too.
Related reading: ScalixNova for the database and branching, Scalix Run for containers and MCP server hosting, and Scalix Sandboxes for isolated agent environments.