Built, not assembled

Most cloud platforms are not platforms. They are holding companies.

A database startup gets acquired. A serverless product gets bolted on. An AI inference layer arrives via partnership. Storage, auth, CDN — each built by a different team, on different assumptions, with different data models. They get unified at exactly one layer: billing. You get one invoice. Underneath, six systems that do not know about each other.

You feel the seams. Auth tokens from the identity service do not propagate cleanly to the database layer. Metering in compute runs at a different granularity than metering in storage. Scale-to-zero works for functions but not databases, or it works for databases but not the way your functions expect. Your first week is spent wiring things together that should already be wired.

We built Scalix World as one system. Two engineers who decided that the integration layer is the product.

The storage engine

ScalixNova is not a managed wrapper around upstream Postgres. It is a purpose-built storage engine that speaks the Postgres wire protocol, with a term-fenced, fsync-durable write-ahead log at its core. We designed it from day one for Paxos-style quorum replication as we grow from one region to many, rather than bolting replication on later as an afterthought. Durability correctness is the foundation of the storage layer, not a feature we added.

What that means in practice: ScalixNova shares the same identity system and metering pipeline as every other Scalix World service. The API key that calls a function also connects to your database. The compute units your database consumes show up on the same bill as your function invocations and AI tokens. There is no impedance mismatch because there was never a boundary to bridge.

The isolation model

Functions and containers on Scalix World do not run in shared-kernel containers. Each workload gets its own microVM — a lightweight virtual machine with hardware-level isolation, its own kernel, its own memory boundary. MicroVMs boot in roughly 76ms. This is not a premium tier. It is the default for every function invocation and every container deployment.

Because the microVM lifecycle is managed by the same orchestration layer that manages databases and storage, scale-to-zero works uniformly. A cold function does not tick. Neither does a paused database. The system does not need to keep resources warm across service boundaries because there are no service boundaries to keep warm across.

The gateway

Every request to Scalix World — database connection, function invocation, AI inference call, storage operation — enters through one gateway. That gateway authenticates against one identity system, meters usage into one ledger, and routes to the appropriate backend.

This sounds simple. It is deceptively hard to get right and nearly impossible to retrofit. When services arrive by acquisition, each brings its own auth model, its own session semantics, its own usage tracking. Unifying those retroactively means translation layers. Translation layers are where bugs, inconsistencies, and security gaps live.

We did not unify anything. We built one identity system, one metering pipeline, and one gateway from the start. A single API key works across every service not because we mapped keys between systems, but because there is one system.

What falls out of this

The practical consequence of one-system architecture is that primitives compose without glue.

An AI agent with a single API key can provision a database, store data, invoke a function, call an AI model, and check its own usage. Same authenticated session, same metering, same project context. No cross-service token exchange. No credential federation. No billing reconciliation job running overnight.

Scale-to-zero works the same way everywhere because every service shares the same lifecycle management. When nothing runs, nothing meters. No service opted out because it was acquired before that pattern existed.

The bill is coherent because it comes from one meter, not from six usage databases reconciled after the fact.

These are not features. They are properties that emerge from building one system instead of assembling six.

Deliberate scope

We built this with two people, in Rust, on dedicated European infrastructure we operate. That is a statement about scope, not velocity.

We chose fewer primitives that work together deeply over a broad catalog of loosely integrated services. Database, compute, functions, AI inference, object storage, auth, DNS. Seven categories sharing one identity layer, one gateway, one metering system. The alternative — wrapping existing open-source projects behind a unified API — would have shipped faster and covered more ground. It would also have reproduced exactly the integration problems we set out to eliminate. Every wrapper is a seam. Every seam is where auth breaks, metering drifts, or scale-to-zero stops working.

Depth over breadth. That is a trade-off and we own what it costs. One EU region today, India next. No managed Redis, no managed Kafka, no CDN — those are roadmap, not product. No SLA yet. When something breaks, you talk to the engineers who built it. Those engineers are us.

The deal we are offering is not “trust our SLA.” It is: verify our uptime at status.scalix.world, start free at scalix.world, and tell us what to build next. We are running a founding design-partner cohort — grandfathered pricing, direct access, a seat at the table for what gets built. If that sounds right, DM us on X or find us on Discord.