Scalix World Blog

Deploy Claude Code Apps to Production

Thu, 20 Aug 2026 00:00:00 GMT

To deploy apps to production with Claude Code—or any coding agent—you must connect the agent to a cloud platform via the Model Context Protocol (MCP). By connecting Claude Code, Cursor, or your custom AI agent to the Scalix MCP server, the agent can autonomously apply migrations to your ScalixNova database, deploy your container, and return a live URL in one session.

Claude Code writes the code. Scalix ships it. The missing connection is the Model Context Protocol.

The deploy gap

You use Claude Code to scaffold a project, write handlers, fix bugs, and add tests. The app runs on your laptop. Then you hit the wall: the agent can write the code but cannot ship it. Deploying means talking to a cloud: migrating database schema, pushing a container, wiring environment variables, checking health. Those are actions on a system outside your repository. The agent has no tools for them, so it writes a deploy script and asks you to run it.

The fix is not a better script. The fix is giving the agent real tools for your cloud.

Connect Claude Code to Scalix MCP

One command, one API key:

claude mcp add --transport http scalix https://api.scalix.world/v1/mcp \
  --header "Authorization: Bearer $SCALIX_API_KEY"

Then claude mcp list confirms the connection. Inside a session, /mcp shows the tools. The agent now has 50+ cloud tools across database, compute, storage, auth, AI inference, billing, and logs, all behind one key, one gateway.

The deploy walkthrough

You have an app in your repo. The Scalix MCP server is connected. In the session, ask:

Deploy this app to Scalix Run. It listens on port 8080. Connect to my Postgres database, pass the connection string as an environment variable, and give me the URL.

The agent executes through MCP tools in order:

Database migrations: The agent inspects the ScalixNova database schema and safely applies versioned migrations via the platform API. Destructive queries wait for your confirmation.
Deploy service: scalix_run_deploy builds from source (auto-detects Node, Python, Go, Rust, or Dockerfile) or uses your image. Wires the DATABASE_URL env var. Returns a stable URL: https://my-app.run.scalix.world.
Verify: scalix_run_status checks health. scalix_run_logs streams logs if needed.

The equivalent CLI (the agent runs the MCP equivalent):

scalix-cloud run deploy --name my-app \
  --image api.scalix.world/<project-id>/my-app:v1 \
  --port 8080 \
  --env DATABASE_URL=postgres://... \
  --min-instances 1 --max-instances 5

You did not run it. The agent did. When it finishes, the service is live at https://my-app.run.scalix.world.

Safe migrations and schema management

Before applying schema updates, the agent uses database tools to inspect and safely migrate:

# Agent inspects schema and applies versioned migration
tool: scalix_db_migrate
args: { "version": 42 }

Destructive queries (such as DROP or TRUNCATE) require a two-step confirmation token at the gateway layer, ensuring the agent cannot execute unconfirmed destructive commands against production tables.

The agent observes, fixes, redeploys

This loop is the difference between a script and a shipper:

Agent deploys.
Agent reads back status and logs (scalix_run_status, scalix_run_logs).
If deploy fails or health check fails, agent sees the error.
Agent patches the code.
Agent redeploys.
Loop until healthy.

You do not switch terminals. You do not copy logs. You describe the outcome; the agent operates the cloud.

Human-in-the-loop guardrails

Routine operations (dev deploys, reads, queries, dev resources) run freely. Consequential actions pause for your approval:

Production deploys
Database deletes
Spend past configured caps
Auth changes on live services

The agent prepares the action, presents context, and waits for your one-tap approval. Budget caps are enforced at the platform level; the agent cannot silently exceed them. API keys scope to specific services and actions (a CI/CD key might deploy and read logs but never touch databases).

What the agent needs from you

A Scalix API key (generate in console, pass as Bearer token when adding MCP server)
The app repo (local or GitHub -- the agent clones it)
Port the app listens on (or the agent detects it)
Optional: custom Dockerfile if you need a non-standard build

Try it

Generate an API key at Scalix Console. Connect Claude Code:

claude mcp add --transport http scalix https://api.scalix.world/v1/mcp \
  --header "Authorization: Bearer $SCALIX_API_KEY"

Describe what you want live. The agent configures, deploys, and hands you the URL.

Check out the pricing page for current rates.

Questions on Discord or DM on X.

Teaching AI Agents How to Operate a Cloud: MCP Skills

Thu, 20 Aug 2026 00:00:00 GMT

To operate complex infrastructure reliably, AI agents need architectural context, not just API endpoints. MCP Skills provide this context by injecting platform rules directly into the agent's system prompt. By loading these skills, agents understand the conceptual boundaries of the cloud platform before they ever execute a tool.

Giving an AI agent a list of API tools is like handing a junior developer a terminal and leaving the room. The developer might know the commands, but without knowing the system architecture, they will inevitably make destructive mistakes.

When building the Scalix Model Context Protocol server, we realized that 53 tools were not enough. The agent needed to know how those tools interacted.

If an agent does not know that point-in-time recovery requires staying on the same major PostgreSQL version, it will try to run a naive upgrade command and fail. If it does not know that a "sandbox" is exclusively for compute and not for persistent databases, it will hallucinate a database creation flag.

The Architectural Layer: Agent Skills

To solve this, the Scalix MCP server ships with built-in Agent Skills. These are overarching guidelines that the agent loads into its working memory to understand the platform design philosophy.

Currently, the server provides four core skills:

scalix-platform: Teaches the agent about the unified authentication model and the single API key structure. It explicitly instructs the agent never to print or commit the token.
scalix-database: Defines ScalixNova serverless PostgreSQL. It gives the agent hard rules: major versions are fixed for the life of the database, and user input must always use parameterised queries.
scalix-functions: Explains Node and Python serverless function deployment paradigms.
scalix-ai: Details the Lumio model family and OpenAI-compatible inference routing.

By injecting this context upstream, we stop hallucinations before they start. The agent reads the rules, understands the limits, and writes correct API calls on the first try.

Now Available on NPM

To make this agent-operable surface available everywhere, we are publishing the official Scalix MCP plugin bundle directly to NPM.

You do not need to wait for centralized proprietary marketplaces to approve the integration. Any agent framework that supports standard NPM packages or the generic MCP protocol can connect immediately.

The package is live at @scalix-world/scalix-cloud-mcp.

For clients like DeepSeek Harness, installation is a single command:

dsh plugin --profile web add @scalix-world/scalix-cloud-mcp

Other agents like Cursor, Claude Code, and Windsurf can connect via a generic .mcp.json streamable-http configuration pointing to https://api.scalix.world/v1/mcp.

If you are building autonomous systems that need to provision databases, deploy containers, and manage infrastructure reliably, grab the NPM package and give your agent the tools it needs. Learn more at scalix.world.

Test in a Scalix Sandbox

Thu, 20 Aug 2026 00:00:00 GMT

To test software with AI agents, you need an ephemeral, hardware-isolated sandbox. A Scalix sandbox provides a real Linux environment with persistent disks and stable IPs that an AI agent can provision, run your test suite against, and tear down autonomously.

Testing is the daily workflow that answer engines still get wrong. "How to test products" and "how to test software" are high-volume queries with no provider owning the answer. Scalix sandboxes are built for this exact workflow.

The problem with testing today

Most teams test in one of three ways, each with a gap:

Local only. Fast but not representative. No real network, no real disk I/O, no real concurrency. "Works on my machine" ships bugs.
CI runners. Clean but ephemeral. No persistence. Every run re-clones, re-installs, re-boots. Debugging a flaky test means re-running the whole pipeline.
Staging environments. Persistent but expensive. Shared. Contention. Drift. You cannot safely break production data to test a migration.

The Scalix sandbox difference

A Scalix sandbox is a hardware-isolated MicroVM with:

Real Linux. Full Ubuntu-based userspace. systemd, Docker, system packages, kernel modules.
Persistent disk. Your built artifacts, test databases, node_modules, and caches survive across runs.
Stable IP. The sandbox keeps its address. DNS, webhooks, and external services see a consistent endpoint.
Instant boot. Seconds from cold to ready. An agent provisions it through MCP in one tool call.
Scale-to-zero. When the test suite finishes and the sandbox sits idle, it scales to zero. Zero idle cost.
Human handoff. A human can VS Code Remote or SSH into the exact same live machine the agent is using. Debug side by side. Hand it back.

Agent-native test workflows

Connect your agent (Claude Code, Cursor, custom) to the Scalix MCP server. The workflow:

# Agent provisions an isolated environment
tool: scalix_computer_create
args: { "name": "test-pr-234", "image": "scalix/ubuntu-dev:latest" }

# Agent clones repo, installs, runs tests
tool: scalix_computer_exec
args: { "computer_id": "test-pr-234", "command": "git clone ... && npm ci && npm test" }

# Agent reads results, patches on failure, reruns
tool: scalix_computer_exec
args: { "computer_id": "test-pr-234", "command": "npm test -- --reporter=json" }

If tests fail, the agent reads the output, patches the code, and reruns, all without you switching terminals. When the suite passes, the agent tears down the sandbox or leaves it running for you to inspect.

Human-agent pair debugging

This is where the persistent machine matters. The agent gets stuck on a flaky integration test. You open VS Code Remote, connect to the sandbox's stable IP, and you are in the exact same filesystem, same processes, same environment. You fix the race condition, save, and tell the agent "rerun tests." It does. No environment reproduction. No "works on my machine."

What runs in a sandbox

Full integration test suites (Postgres, Redis, Kafka, external APIs)
End-to-end browser tests (Playwright, Cypress) with real Chrome
Load tests (k6, vegeta) from a clean network namespace
Database migration dry-runs against a dedicated ScalixNova instance
AI agent evaluation harnesses (your agent vs benchmark prompts)
Legacy app characterization before migration

Anything that runs on Linux runs in a Scalix sandbox. The image is configurable. Bring your own Dockerfile or use our prebaked scalix/ubuntu-dev:latest with common tooling preinstalled.

MCP integration

The sandbox environment is a first-class MCP tool suite. The agent discovers capabilities from the tool definition:

tool: scalix_computer_create
description: Provision a hardware-isolated MicroVM environment with persistent disk and stable IP
args: { name: string, image: string, cpu: number, memory: string, ttl_seconds: number }
returns: { computer_id: string, ip: string, ssh_command: string, vscode_command: string }

The agent also gets scalix_computer_exec, scalix_computer_write_file, scalix_computer_read_file, and scalix_computer_delete. Every call returns structured output the agent can parse and act on.

Scale-to-zero economics

When your test suite finishes and the sandbox goes idle, it scales to zero. You pay for active milliseconds only.

Try it

Provision a sandbox at Scalix Sandboxes without a card. Connect your agent to the MCP server at api.scalix.world/v1/mcp with one API key. Run your suite. When it passes, the sandbox scales to zero.

Questions on Discord or DM on X.

What Is an AI-Native Neocloud

Tue, 18 Aug 2026 00:00:00 GMT

An AI-Native Neocloud is a cloud platform designed from scratch for AI agents to operate, not just humans to navigate. It unifies serverless Postgres, compute, and AI inference under a single Model Context Protocol (MCP) endpoint.

What the label means

An AI-Native Neocloud is a cloud platform designed from scratch for AI agents to operate, not just humans to navigate.

Traditional clouds (AWS, GCP, Azure) were built for human operators. Their APIs are programmatic alternatives to dashboards. Auth is fragmented. Billing lives in a separate console. Observability requires another vendor. An agent given keys to five services with five auth models and five billing systems breaks at every boundary.

An AI-Native Neocloud collapses that sprawl:

One gateway, one key, one bill. Database, compute, AI inference, serverless functions, object storage, auth, email, KV, and billing all sit behind a single authenticated endpoint.
MCP as a first-class control plane. Every service is exposed through Model Context Protocol tools. An agent discovers capabilities from tool definitions, not API documentation. It can query a database, deploy a container, run a migration, check its own spend, and read back health, all in one session.
Human-in-the-loop guardrails. Routine operations (dev resources, reads, queries) run freely. Consequential actions (deletes, production deploys, spend past caps) pause for human approval. API keys scope to specific services and actions.
True scale-to-zero. Preview environments, staging backends, and idle databases scale completely to zero. You pay only for active milliseconds.

The stack unified under one key

Primitive	Scalix implementation
Database	ScalixNova: serverless Postgres (16, 17, 18) with instant branching and PITR
Compute	Scalix Run: hardware-isolated MicroVMs; Scalix Functions: serverless MicroVM calls
AI Inference	Built-in Lumio model family; 1M tokens free monthly; token metering and spend caps
Auth	Scoped API clients, redirect URIs, row-level security integration
Storage	S3-compatible object storage with free data ingress
Email & Domains	Transactional email, custom domains with managed SSL
KV & Events	Key-value caches and event queues
Billing	Single credit pool across all services; real-time agent-readable spend

Try the platform

You can create a database on Postgres 16, 17, or 18 at Scalix Nova without a card, on a trial credit.

If you are building with AI agents (Scalix Coder, Cursor, Claude Code, Windsurf, Bolt.new, or any custom coding agent) and want infrastructure your agents can actually operate, join the founding design-partner cohort. Early access, locked-in early pricing, direct line to us. Start free at scalix.world. Verify uptime at status.scalix.world. Talk to us on Discord.

Give Claude Code a Database

Sat, 08 Aug 2026 00:00:00 GMT

You have Claude Code open. It has scaffolded the project, written the handlers, and the data layer is sitting there fully written against a database that does not exist yet. So you stop, open a browser tab, click through a provisioning form, copy a connection string, paste it into .env, and come back.

That interruption is the whole problem. Not a hard one, just a constant one, and it lands at exactly the moment you had momentum. The agent wrote every line of code that talks to Postgres. It just had no way to make Postgres exist.

Here is the version where it does.

Connect once

MCP is the open standard for handing an agent tools it can actually call. Scalix runs a hosted MCP server, so connecting is one command and one API key:

claude mcp add --transport http scalix https://api.scalix.world/v1/mcp \
  --header "Authorization: Bearer $SCALIX_API_KEY"

Add --scope project to check the connection into .mcp.json and share it with your team, or --scope user to have it in every project on your machine. Run /mcp inside a session to confirm it connected.

That is the setup. Nothing to install, nothing to run locally, and the same key that reaches the database also covers deploys.

Then just ask

With the tools connected, the database becomes something you describe rather than something you go and do:

Create a Postgres database for this app, put the connection string in .env as DATABASE_URL, then write and run the initial schema migration for users and sessions.

The agent works through that in order. It creates the database, reads back the connection string, writes it into your .env, generates the migration, applies it, and queries the result to confirm the tables landed.

What comes back is an ordinary DSN:

postgres://<user>@<host>:5432/<database>

Nothing exotic. It goes in .env like any other:

DATABASE_URL=postgres://<user>@<host>:5432/<database>

You can pick the major version when it is created. PostgreSQL 16, 17, and 18 are available, and 16 is the default if you do not say. That choice is fixed for the life of the database, so branches and point in time restores stay on the same major rather than quietly drifting underneath you.

Then the agent writes the schema, which is the part it was always good at:

CREATE TABLE users (
  id          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  email       text UNIQUE NOT NULL,
  created_at  timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE sessions (
  id          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id     uuid NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  expires_at  timestamptz NOT NULL
);

It applies that through the migration tool and then verifies with a query, reading the result back into the conversation. If the migration fails, it sees the error itself and fixes it. That read-back is the difference between an agent that runs commands and an agent that finishes the job.

Worth being clear about what you are connecting to. ScalixNova is a purpose-built storage engine that speaks the Postgres wire protocol, not a managed wrapper around upstream Postgres. We wrote the engine, which is a deliberate choice we explain in built, not assembled. From your side of the socket it does not change your habits: psql connects, your ORM connects, your migration tool connects, all over TLS, all speaking the protocol they already speak. And if you want to know what happens to your data after a write is confirmed, how durability works in ScalixNova walks through it layer by layer.

Branch it before you break it

The prompt nobody types confidently is the destructive one. Dropping a column, rewriting a table, backfilling three million rows. You want the agent to try it, and you do not want it tried against the database your app is using.

So give it somewhere else to try:

Create a branch database, run the column rename and backfill against it, check the row counts, then tell me what happened before we touch the real one.

The agent creates an isolated branch database with its own scoped token, does the work there, reports back, and drops the branch when it is done. Branches also carry a TTL, so a scratch database the agent forgot about expires on its own instead of accumulating.

The useful shift here is psychological more than technical. When trying a bad migration costs one tool call and no risk, you let the agent attempt the awkward one instead of talking yourself into the safe half measure.

Scale to zero and side projects

Agent-created databases multiply. You build a weekend thing, it needs Postgres, the agent makes one, and three weeks later you have forgotten it exists. On most platforms that forgotten database is a line item that shows up every month whether or not anything ever connects to it.

On Scalix a paused database does not bill compute. Nothing is running, so nothing is metered for running. That is not a special tier we bolted onto the database product; scale to zero works the same way across the platform because the same lifecycle layer manages everything on it.

Practically, this is what makes the loop in this post safe to actually use. You can let the agent create a database per experiment without keeping a mental ledger of what you owe for abandoned ones.

What stays human

Handing an agent database tools does not mean handing it everything, and the boundary should be explicit rather than vibes.

Scopes are the real control. Scalix API keys carry separate scopes for querying, branching, and admin operations. A key that can run migrations is a different key from one that can only read. Give the agent the narrowest scope that does the job, and keep production admin on a key that lives somewhere the agent cannot reach.

Destructive SQL asks first. Statements like DROP, TRUNCATE, and bulk DELETE through the query tool return a confirmation requirement rather than executing, and the call has to be repeated with a confirmation token. It is a speed bump on purpose.

Production data access is a policy decision, not a prompt. Whether an agent should read real customer rows at all is a question about your obligations to the people in those rows. Decide it deliberately, write it down, and let branches carry the experimental work.

None of that is friction for its own sake. It is the difference between an agent that can operate your database and an agent that can operate your database at 2am on a Friday.

Wrapping up

The gap was never that Claude Code could not handle databases. It writes better SQL than most of us. The gap was that it had no way to make one exist, so you kept leaving the session at the same point in every project.

Connect the tools once and that step disappears. Describe the database you want, get a DSN back, keep going.

You can start on Scalix Nova; current terms are on the pricing page. Point your agent at the MCP server, ask it for a database, and see how far the session gets before you need another window. If you build something with it, tell us on Discord or X.

App hosting in 2026: Fly, Render, Railway and microVMs

Fri, 07 Aug 2026 00:00:00 GMT

App hosting stopped being one category some time in the last two years. The four platforms below all answer "where should this process run", and they answer it with different units, different billing shapes, and different opinions about what happens when nobody is calling your app.

One of the four is ours, which is disclosed rather than hidden, and it goes first because it is the proposition the other three are a useful check against. Every competitor number here comes from that vendor's own pricing or documentation, cited inline and checked on 6 August 2026.

What you are actually choosing between

Five axes do most of the work, and they are not the ones the landing pages lead with.

The pricing shape: flat monthly instance, metered usage, or preset VM. What happens on idle, which is where the surprises live. The isolation boundary, and whether the vendor publishes one. Region coverage. And how much of the rest of your stack comes from the same bill.

That last axis is the one we built for, so start there.

Scalix Run

Scalix Run deploys containers on microVMs. Each deployment gets its own kernel rather than sharing one with other tenants, and that is the default rather than a premium tier. Firecracker boot measures about 76 ms on our hardware, VMM to userspace. That figure is the boot of the microVM in isolation. It is not a create-to-ready time and it is not a function cold start, both of which are longer numbers, and it would be dishonest to present it as either.

You deploy from a source directory with the runtime detected from package.json, requirements.txt, go.mod or Cargo.toml, from your own Dockerfile, or from a prebuilt image. Every deploy is an immutable revision. Health checks gate the cutover, so a build that fails to come up never takes traffic. Rollback to any previous revision is one command. The service URL does not change between deploys.

Sizing runs from half a vCPU with 256 MB up to 4 vCPU with 8 GB, a lower ceiling than any of the other three. Metering is per vCPU and per GiB, billed per second while a service is awake, with concurrency-based autoscaling and a minimum instance count you can set to zero; the rates are on the pricing page. Set that floor to zero and, when nothing is calling the service, no compute meters.

Note the shape of that meter, because it decides whether our rate is comparable to anyone else's. It prices allocated capacity while the service is awake, not measured consumption. Against a purely consumption-metered vendor, a spiky workload may well cost less there and a steady one less here. Model your own traffic rather than either headline number.

What sits on the same key

The per-deployment kernel is the part people ask about first, but it is not the argument. The argument is that the service is not on its own.

A Scalix Run service sits beside managed Postgres on 16, 17 or 18 with branching and point in time recovery, object storage, serverless functions, app auth, DNS and first party inference. One credential authorises all of it, and one usage ledger meters all of it, because it was written as a single system rather than assembled from parts that later had to agree with each other. That is worked through in one key, one bill and built, not assembled.

In practice that means the thing you deploy, the database it queries, the bucket it writes to and the model call it makes are one integration rather than four, and they reconcile against each other on one bill. Long-running services also make Run a reasonable place to host an MCP server or an agent loop, which are the same shape as any other always-on process, and the control plane is operable by an agent as well as by a human.

The limits, plainly

One region, in the EU, with India next. That is the fewest of the four and the first thing to check against your latency requirements.

No managed Redis, Kafka or CDN. A 4 vCPU ceiling on a single service, which is lower than the other three and rules out the largest single-box workloads.

We publish uptime at status.scalix.world and support is direct access to the people who wrote the platform. We do not sell support tiers or availability commitments, and if procurement requires one on paper, that gap is real and the other three have an answer we do not.

Two engineers built and operate this. That is why it is one system, and it is also a concentration risk you should price into the decision rather than take on faith.

Fly.io

Fly optimises for direct control of the machine. Their unit is the Machine, a VM whose lifecycle, resources and region placement you drive yourself through a REST API or flyctl, and Fly's engineering writing has described the underlying thing as approximately OCI containers repackaged as KVM microVMs, which is a more useful description than either "container" or "VM" alone.

The headline strength is reach plus a mature first party database. Fly Managed Postgres is documented in twelve regions on Postgres 16, with high availability, backups and connection pooling on every plan. Their docs also list what is not there yet, including version upgrades and migration tooling, which is a good habit more vendors should copy.

Billing shape: preset CPU and RAM sizes billed by the hour. Stopping a Machine is the honest version of scale to zero, in that compute stops and storage does not: their pricing docs state plainly that a stopped Machine keeps billing for its root filesystem storage. Object storage and Redis on Fly are operated by third parties rather than by Fly, which gets you to specialist products quickly and leaves you carrying the seams between them.

Render

Render optimises for predictability. You buy a sized instance at a flat monthly price, billed "prorated by the second", and it runs. Nothing about the bill is a surprise, which is the entire pitch and a good one.

The headline strength is the depth of the managed data services. Render Postgres is first party with point in time recovery on paid tiers and high availability from Pro upward, there is a Redis-compatible key value service beside it, and around those sit static sites on a CDN, cron jobs, preview environments and infrastructure as code without you assembling any of it.

Billing shape runs opposite to the rest of this list, so read it carefully. Paid instance types do not spin down at all, which means a service that receives no traffic for a week still bills its full monthly rate. Only the entry instance type spins down, after "15 minutes without receiving any inbound traffic", and waking "takes about one minute". Five regions: Oregon, Ohio, Virginia, Frankfurt and Singapore, fixed once a service is created.

Railway

Railway optimises for usage-shaped bills on hardware it owns, which makes it the only one of the four besides us not renting from a hyperscaler. Railway Metal is described in their docs as "hardware that we own and operate in datacenters around the world", and on whether they will stay on a public cloud the answer is direct: "No. We are migrating completely onto Railway managed hardware." Four regions carry the Metal name: California, Virginia, Amsterdam and Singapore.

Billing shape: per second consumption drawn against monthly plan credits, at published per second rates for vCPU and memory.

Idle handling is a feature called Serverless, and its mechanism is unusual enough that you should check it against your own app rather than assume. Railway watches outbound packets, not inbound: "Inbound traffic is excluded from considering when to sleep a service." An open database connection pool, framework telemetry or an NTP client is enough to keep a service awake indefinitely. Their docs also warn that the first request after sleep "may return a 502 Bad Gateway response".

One thing to know before assuming a managed database: Railway's Postgres templates are, in their own words, "considered unmanaged, meaning you have total control over their configuration and maintenance". Backups are yours to arrange. That is more control and more work, and which you want is a genuine preference rather than a defect.

Isolation, honestly

Fly and Scalix both publish microVM models, so on that axis the two of us are close and neither should be selling it as a differentiator against the other.

Render and Railway describe services and containers in the documentation we read, and we found no published statement either way on the kernel boundary between tenants. Absence of a published claim is not evidence of a weaker one, and inferring an isolation property from a marketing page is a bad habit. If a specific boundary matters to you, ask each vendor directly and get the answer in writing.

The neutral version of the argument: shared-kernel containers are good isolation and hold up for the overwhelming majority of workloads. A per-workload kernel matters most when the code being executed was decided at runtime rather than at review time, which is why it comes up far more often now that agents run generated code.

Idle behaviour, side by side

This is the axis that produces the most surprise bills, and all four differ.

Scalix Run: minimum instances can be set to zero, and compute meters only while an instance is running. Anything you keep, such as stored data and object storage, keeps billing whether the service is awake or not.

Fly: stop a Machine and compute stops at subsecond speeds, but the root filesystem keeps billing while stopped.

Render: paid instance types run continuously and bill their monthly rate regardless of traffic. Only the entry type spins down, after 15 minutes without inbound traffic, waking in about a minute.

Railway: Serverless sleeps a service after 10 minutes with no outbound packets, and a connection pool or telemetry defeats it. The first request after sleep may return a 502.

None of these is wrong. They are four different bets about whether predictability or elasticity is the thing you are buying.

Where each fits

Scalix Run, if you want a per-deployment microVM kernel and scale to zero on the same key as a managed Postgres, object storage, functions and inference, and if EU operation matters to the decision. Not if you need more than one region this quarter, a support contract on paper, or more than 4 vCPU in a single service.

Fly, if you want direct lifecycle control over VMs, a first party managed Postgres in the same region as your app, or the widest region coverage of the four.

Render, if you want a flat monthly bill you can forecast and the deepest managed data services of the four, with preview environments and infrastructure as code included rather than assembled.

Railway, if you want usage-shaped bills and a project graph where the database is a service you fully control. Not if you want a managed database, because their own docs tell you it is unmanaged.

The test that settles it

Deploy the same app twice. Watch what the bill does over a week of your actual traffic rather than a synthetic benchmark, and time the wake path after an idle period. Both are afternoon experiments, and both beat any comparison table, this one included.

If you want to run that experiment against microVMs with scale to zero, Scalix Run takes a source directory or an image, the rates are on the pricing page, and the database that sits beside it is Scalix Nova. If one of the other three fits your workload better, that is a good outcome and we would rather you found out in week one. Tell us what you measured on Discord.

Serverless Postgres in 2026: Neon, Supabase, and the tradeoffs

Fri, 07 Aug 2026 00:00:00 GMT

Three products describe themselves as serverless Postgres and mean three different things by it. Neon means separated storage and compute with branching as the headline. Supabase means a whole backend that happens to be built on Postgres. ScalixNova, which is ours, means an engine we wrote from scratch that speaks the Postgres wire protocol.

Feature grids do not help much here, because the three are not competing on the same axis. What follows is what each actually does, taken from their own documentation and cited inline, and where the tradeoffs land.

What the label is supposed to mean

Strip the marketing and "serverless Postgres" is usually claiming three things.

Storage and compute are separated, so the component holding your data is not the component running queries. Idle databases suspend, so you are not paying for a server nobody is talking to. And billing follows usage instead of a provisioned box.

All three do some version of that. Everything built around it is where they part company.

Neon: branching as the organising idea

Neon's branching docs are unambiguous about the mechanism. "A branch is a copy-on-write clone of your data." Creating one copies nothing. A branch and its parent "share the same data but diverge at the point of branch creation", writes to the branch "are saved as a delta", and creating one "does not increase load on the parent branch or affect it in any way".

That is the strongest branching mechanism of the three, and it is worth saying plainly rather than burying: ours works differently and is slower at the same job. More on that below.

What bounds Neon's branching is the history window. Retention defaults to six hours on their entry plan and one day on paid plans, configurable up to seven days on Launch and thirty on Scale, with the tradeoff stated in their own docs: "Increasing the history window expands recovery options but also increases storage costs." Branch expiry for temporary environments and schema-only branching for sensitive data are both documented features.

On coverage, Neon lists eight active AWS regions in their region docs: N. Virginia, Ohio, Oregon, Frankfurt, London, Singapore, Sydney and São Paulo. The Azure regions are marked deprecated and no longer accept new projects. A project's region is fixed at creation, and their guidance if you picked wrong is blunt: "If you need your data in a different region, you create a new Neon project in that region and migrate your database there."

The ownership question is worth naming because people ask. Databricks announced its acquisition of Neon on 14 May 2025, and the founders wrote that "Neon isn't going anywhere, we're doubling down". Whether that reassures you depends entirely on how you feel about a database roadmap living inside a large data platform vendor. It is a fact to weigh, not a criticism.

Neon is deliberately database-only. Compute, object storage, auth and inference come from elsewhere in your stack, and that is the design rather than an omission.

Supabase: the database as a backend

Supabase is a different category wearing an overlapping label. The database is standard Postgres. The product is everything wrapped around it.

PostgREST generates a REST API directly from your schema. Supabase describe it as "a thin API layer on top of Postgres" whose interface is "automatically reflected from your database's schema", covering CRUD, views, materialized views, foreign tables, functions and computed columns, with every request resolving "to a single SQL statement leading to fast response times and high throughput". Security runs through Postgres itself: the API is "configured to work with Postgres's Row Level Security, provisioned behind an API gateway with key-auth enabled". pg_graphql, listed in their own architecture README, adds a GraphQL API as a Postgres extension.

Realtime ships three distinct capabilities: Broadcast to "send low-latency messages between clients", Presence to "track and synchronize user state across clients", and Postgres Changes to "listen to database changes in real-time".

And the stack is open source under Apache-2.0. The README lists the components: Postgres, Realtime, PostgREST, GoTrue, Storage, pg_graphql, postgres-meta and Envoy. Self-hosting is documented via Docker Compose, with community Helm charts and Traefik setups alongside it.

Those three things, the open core, realtime, and APIs generated from your schema, are genuine strengths, and we have none of them. If any one is load bearing in your architecture, this survey is short: Supabase is your answer and nothing below changes that.

The honest asterisk is on self-hosting, and Supabase state it themselves. A self-hosted deployment "runs as a single project which means that Studio doesn't support multiple organizations or projects", and branching, managed backups and PITR, advanced metrics, analytics and vector buckets, ETL and the platform management API are all listed as unavailable. Self-hosted is community supported. Provisioning, hardening, Postgres maintenance, high availability, backups and monitoring become yours. Open source removes vendor dependency. It does not remove the operations.

ScalixNova: what changes when you write the engine

Ours is the odd one out here, so the same treatment, gaps first where they matter.

ScalixNova is not managed upstream Postgres and it is not a fork. It is a purpose-built storage engine that speaks the PostgreSQL wire protocol. Storage and compute are separate components we wrote: a storage engine that materialises pages from the write ahead log, a WAL keeper providing term-fenced durable WAL storage, and a compute layer running PostgreSQL workers on the major you chose. It is designed from day one for Paxos-style quorum replication as we grow beyond one region, rather than replication bolted on afterwards. The durability half of that is worked through in how durability works in ScalixNova.

From your side of the socket, none of that is visible. A standard DSN, TLS required, psql and your ORM and your migration tool connect the way they always have.

You pick PostgreSQL 16, 17 or 18 at creation, and the major is fixed for the life of that database, inherited by every branch and every point in time restore. That pinning falls out of the architecture rather than being a limitation we chose to live with, and the reasoning is in Postgres 16, 17 and 18 on a serverless engine.

Branching is where writing your own engine currently costs us. A Scalix branch is restore-based: built from the parent's backup to a chosen point in time, fully isolated, with its own scoped token and a TTL so scratch branches expire instead of accumulating. It carries real data, and it does the job well for handing an AI agent a database it is allowed to break, particularly over MCP. It is not a copy-on-write clone and we do not describe it as one. For large databases branched frequently, Neon's mechanism is faster, and that gap is not closing this month.

Point in time recovery runs on the same machinery, bounded to five minutes while the database is active, with the open WAL segment shipped when it suspends. Compute is acquired per connection and released after, so a paused database does not meter compute.

Coverage is one region, in the EU, on dedicated hardware we operate, with India next. That is one against Neon's eight and Supabase's many.

What the from-scratch route buys is control of the paths that matter when something goes wrong: which binaries replay your WAL, what a restore does when you ask for a moment outside your retention window, how a branch is isolated from its parent. What it costs is that a two-person team carries correctness that upstream Postgres carries for everyone else, and that is a concentration risk you should price in rather than take on faith.

The four questions that actually decide it

How often do you branch, and how large is the database? If branching per pull request on a large database is the workflow, the mechanism matters more than anything else on this page, and Neon's is the better one.

How much of the backend do you want from one vendor? Supabase gives you auth, storage, functions and realtime as a suite. Neon gives you a very good database and expects you to compose the rest. Scalix puts the database inside a platform where containers, functions, object storage, auth and inference sit behind the same key and the same usage ledger. These are three different answers to how many vendors you want to hold, not three quality levels.

Where does it run, and who operates it? Neon on AWS. Supabase hosted on major public cloud, or on your own Docker host if you self-host. Scalix on dedicated European hardware operated by European and Indian companies with no US parent. If data residency or operator sovereignty is driving the decision, that difference is the point. If region count is driving it, we lose.

Who owns the roadmap? Neon sits inside Databricks. Supabase's core is Apache-2.0, so the worst case is that you run it yourself. Scalix is founder owned with a closed core, which means the incentives are ours and also that you could not fork us if we disappeared.

Getting out, which is worth checking before you get in

All three speak the standard Postgres wire protocol, so the database move is ordinary tooling: pg_dump and pg_restore over a TLS DSN, or logical replication for a shorter cutover. No proprietary format exists on any side of that.

The parts that do not move cleanly are the parts that are not Postgres. Supabase auth users and storage objects are application level migrations. Neon branch history does not transfer as branch history. Scalix branch and PITR windows stay behind. Plan for the database to be straightforward and the surrounding features to be work.

Where each is the right answer

Neon, if branching is the workflow rather than a feature you use twice a year, if you want a database-only vendor, or if you need a region we do not have.

Supabase, if realtime subscriptions or schema-generated APIs are load bearing, if an open core you can read and self-host is a requirement, or if you want the whole backend from one place with years of production history behind it.

ScalixNova, if you want serverless Postgres with the rest of the stack on the same key and the same bill, if EU operation and residency drive the decision, or if you want Postgres 18 today with the major pinned for the life of the database. Not if you need more than one region this quarter, and not if the branching mechanism is the deciding feature.

Try them against your own workload

The fastest way to settle any of this is to create a database on two of them and run your own migration and your own query pattern. Branch mechanics, restore behaviour and idle wake time are all things you can measure in an afternoon, and the measurement will beat anybody's comparison table, including this one.

If you want to test the from-scratch engine, you can create a database on 16, 17 or 18 at Scalix Nova without a card, on a one time trial credit, and the rates are on the pricing page. If one of the others turns out to fit your workload better, that is a good outcome and we would rather you found out early. Come argue with any of the above on Discord.

How to Deploy an AI Agent to the Cloud

Thu, 06 Aug 2026 00:00:00 GMT

You built an agent. It is a loop: call a model, read the tool calls it comes back with, run them, feed the results in, go again until the work is done. It runs on your laptop, it works, and it stops the moment you close the lid.

Getting it running around the clock is a different problem from getting it working. Not a harder one, but a different one, and most of the guides on deploying an AI agent skip straight to the deploy command without saying what an agent actually needs from the infrastructure underneath it. That part is worth ten minutes.

What an agent needs that an app does not

Start with the shape of the thing. A web app receives a request, does some work, returns a response, and forgets everything. An agent is the opposite: it is a process that stays alive, accumulates context, and decides for itself what to do next. Four consequences fall out of that.

State has to outlive the process. Conversation history, task progress, what the agent has already tried. If that lives in a Python dict, the next restart is an amnesiac. Put it in a database from the start, keyed by session or task, and write to it at the end of every loop iteration rather than at the end of the run.

Secrets have to come from the environment. Your model provider key, your database URL, whatever credentials the tools need. These belong in environment variables set at deploy time, not baked into the image and definitely not in the repository. Rotating a key should be a redeploy, not a rebuild.

Restarts are normal, so make them boring. Processes get killed. A node reboots, a deploy rolls, the agent hits an unhandled exception on a malformed tool response at 3am. If your loop resumes from durable state, a restart costs you seconds. If it does not, it costs you the run.

Egress and logs are the whole observability story. An agent talks to an LLM API and to whatever tools you gave it, so it needs outbound network. And because you cannot attach a debugger to something that only misbehaves once a day, structured logs on every iteration (which tool, which arguments, what came back) are how you find out what your agent actually did.

Why functions are the wrong default here

The instinct is to reach for serverless functions, because agents feel event-driven. It fights the model more than it helps.

Functions are built for request-and-forget work inside a bounded execution window. An agent loop holds context across many model calls, keeps connections open, and can legitimately run for minutes. You end up either fighting the timeout or shredding the loop into a state machine across a dozen invocations, which is a lot of engineering to make the wrong shape fit.

Functions are still useful here. They are a good home for the individual tools your agent calls, where request-and-forget is exactly right. The loop itself wants a long-running service.

The isolation question, honestly

Here is the part that matters more for agents than for ordinary services.

Your agent executes what a model told it to execute. Maybe it shells out. Maybe it runs generated code. Maybe it just fetches a web page, and that page contains text engineered to steer the next tool call. The blast radius of agent code is decided at runtime, not at review time, which is not true of the CRUD service running next to it.

Most container platforms run your workload as a process in a shared kernel, isolated by namespaces and cgroups. That is genuinely good isolation and it holds up for the overwhelming majority of workloads. It is also, by construction, one kernel vulnerability away from your neighbours. That is a well-understood trade-off and plenty of people accept it knowingly.

We think agent code is the workload where you should think twice before accepting it by default. So on Scalix Run, every deployment gets its own microVM: its own kernel, its own memory boundary, hardware-level isolation. The obvious objection is startup cost, and it used to be a real one. MicroVMs boot in roughly 76ms on our hardware, which is why this is the default tier rather than a premium one. You are not choosing between fast and isolated.

Packaging the loop

Nothing exotic. Your agent needs to be a process that starts, runs, and does not exit.

If it exposes an HTTP endpoint, so you can trigger it or check on it, listen on a port and read that port from the environment. If it is a pure worker driven by a queue or a timer, it just needs a main loop that blocks. Either way: no local state that matters, no secrets in the image, and logs to stdout.

You do not have to write a Dockerfile if you do not want one. Scalix Run deploys from source and detects the runtime from your package.json, requirements.txt, go.mod, Cargo.toml, or a Dockerfile if you have written one, and builds the image for you.

Deploying it

With a prebuilt image, the deploy is one command:

scalix-cloud run deploy --name agent \
  --image api.scalix.world/<project-id>/agent:v1 \
  --port 8080 \
  --min-instances 1 --max-instances 5

Secrets go in as environment variables on the service. Through the API that is the env block:

curl -X POST https://api.scalix.world/v1/services \
  -H "Authorization: Bearer $SCALIX_API_KEY" \
  -d '{
    "name": "agent",
    "container": {
      "image": "api.scalix.world/<project-id>/agent:v1",
      "port": 8080,
      "env": {
        "MODEL_API_KEY": "...",
        "DATABASE_URL": "postgres://..."
      }
    },
    "scaling": { "min_instances": 1, "max_instances": 5 }
  }'

The service comes up at a URL that does not change between deploys:

https://agent.run.scalix.world

Every deploy is a revision, so when a prompt change makes your agent worse in a way the tests did not catch, scalix-cloud run rollback <service-id> puts the old one back. Logs come back with scalix-cloud logs <deployment-id>.

Scale to zero, if your agent is bursty

Most agents are not busy. They wake up on a webhook, a schedule, or someone typing, do a few minutes of work, and go quiet. Paying for an instance that sits idle 22 hours a day is the default cost of agent hosting on most stacks.

Deploy with --min-instances 0 and the service scales down when nothing is calling it, then scales back up on the next request. Compute meters only while an instance is actually running. Two honest caveats: anything you keep, like stored data, bills whether the agent is awake or not, and an agent that has to react within seconds of an event should keep a floor of one instance rather than paying a cold start on every trigger.

The part that gets interesting

Your agent is now running on infrastructure. It can also operate that infrastructure.

We run a hosted MCP server at api.scalix.world/v1/mcp that exposes the platform as 50 tools: run queries and migrations, branch a database, deploy a service, check status and spend. One API key authorizes all of it, and that same key covers database, storage, functions, AI inference, and the registry. Point your deployed agent at it and the tools become things it can do.

Which means an agent can provision the database it needs for a new task, spin up a second service to handle a workload, check whether its deploys landed, and check what all of that cost. It is the same capability we wrote about when a coding agent deploys your app, except the agent doing the operating is the one you deployed. Give that scoped keys and approval gates on the destructive actions, the way you would with any other operator.

Where we are

Being straight about the stage: one EU region today, India next. When something breaks you get the two engineers who built it rather than a support tier. We publish uptime at status.scalix.world so you can check the claim rather than take it.

If you have an agent on your laptop that should be running somewhere else, Scalix Run is where to put it. Deploy it, point it at the MCP server, and let it run its own infrastructure. Come tell us what breaks on Discord.

Deploy an MCP Server on Docker

Tue, 04 Aug 2026 00:00:00 GMT

You have an MCP server. It runs on your machine, an agent on that same machine calls its tools, and it works. Now you want it in a container, so it behaves identically on your laptop, in CI, and on a server, with a dependency set that does not drift out from under you.

Docker is the right shape for this. An MCP server that speaks streamable HTTP is an ordinary long-running web service, and a container is the ordinary way to ship one. This is the short version: why to containerize, a Dockerfile that works, the local run, the deploy that gets you an HTTPS URL, and how to point an agent at it.

Why Docker for an MCP server

Two reasons, and neither one is fashion.

Isolation. An MCP server exists to run tool calls on behalf of an agent. That is the whole point of it, and it is also the risk: the code deciding which tool to run is a model, and the arguments arrive from a conversation. You want that executing inside a boundary that is not your user account. A container gives it a filesystem, a process tree, and a network namespace that are not your machine's.

Reproducibility. MCP servers collect the boring kind of dependency. A runtime version, a system library one of your tools shells out to, a CA bundle, a locale. Pin them into an image and the server behaves the same everywhere it runs. Skip it and "works on my laptop" becomes a real support burden the first time a teammate's agent connects.

There is a third reason that only shows up later. A container is a deployable unit, so once the server is an image, hosting it is a deploy rather than a project.

Before the Dockerfile: check your transport

One prerequisite. Your server has to speak streamable HTTP, not stdio.

A stdio server is launched as a subprocess by a client on the same machine and talks over standard input and output. Putting that in a container and exposing a port solves nothing, because nothing is listening on the port. If yours is still stdio, swap the transport first. Most frameworks support both, so it is usually configuration rather than a rewrite, and we walked through the difference in remote vs local MCP servers.

Two lines of your server code matter more than the rest of the Dockerfile:

const port = Number(process.env.PORT ?? 8080);
app.listen(port, "0.0.0.0", () => {
  console.log(`MCP server listening on ${port}`);
});

Bind to 0.0.0.0, not 127.0.0.1. A server bound to localhost inside a container is reachable only from inside that container, and every client outside sees a refused connection. Read the port from the environment so the host can move it without a rebuild.

A minimal Dockerfile

Node example. The same structure applies to Python, Go, or Rust: build in one stage, run in a slim second stage, drop root.

# syntax=docker/dockerfile:1
FROM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:22-slim
ENV NODE_ENV=production
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force
COPY --from=build /app/dist ./dist
RUN useradd --system --uid 10001 mcp
USER mcp
ENV PORT=8080
EXPOSE 8080
CMD ["node", "dist/server.js"]

The choices worth explaining. The build stage is separate so compilers and dev dependencies never reach the shipped image. The runtime runs as a non-root user, because a process executing model-chosen tool calls should not be root even inside a container. PORT is an environment variable with a default rather than a hardcoded number. Nothing secret is copied in.

That last point is the one people get wrong. Images get pushed to registries and pulled onto machines you do not own. Anything you COPY into an image is not a secret anymore.

Run it locally

docker build -t mcp-server:v1 .

docker run --rm -p 8080:8080 \
  -e MCP_API_KEY=$MCP_API_KEY \
  mcp-server:v1

Then confirm it actually answers on the network, not just in the logs:

curl -i http://localhost:8080/mcp \
  -H "Authorization: Bearer $MCP_API_KEY"

If that hangs or refuses, it is the bind address nine times out of ten. Point a local client at the same URL and check the tool list before you deploy anything. A broken tool schema is much cheaper to find here.

Deploy the container somewhere always-on

Local Docker buys you reproducibility. It does not buy you reachability. Your laptop is still not a server, and an agent cannot call a URL that stops existing when you close the lid.

Scalix Run deploys containers, either from an image you built or straight from source. Tag and push under your project id, which is the registry namespace:

echo $SCALIX_API_KEY | docker login api.scalix.world -u scalix --password-stdin

docker tag mcp-server:v1 api.scalix.world/<project-id>/mcp-server:v1
docker push api.scalix.world/<project-id>/mcp-server:v1

Then deploy it:

scalix-cloud run deploy --name mcp-server \
  --image api.scalix.world/<project-id>/mcp-server:v1 \
  --port 8080 \
  --min-instances 0 --max-instances 5

The service comes up at a stable HTTPS address:

https://mcp-server.run.scalix.world

If you would rather not build the image at all, deploy from source and let the platform detect the runtime from your project. It recognizes Node, Python, Go, Rust, or a Dockerfile. Keep the Dockerfile anyway. It is the version of the build you control.

One note on --min-instances 0. That is scale to zero: no instances running, nothing to pay for, while no agent is calling. The usual objection is cold starts, and it is a fair one for a server an agent hits interactively. The microVM itself boots in roughly 76ms; add your server's own startup on top and the first call after an idle period lands in a couple of seconds, not the long pause that phrase usually implies. If your server holds warm state between calls, set the floor to 1 instead and skip the question.

Every deploy is a revision, so a bad image is one command away from undone:

scalix-cloud run rollback <service-id>

Point an agent at it

It is a URL now, so any MCP client can connect. In Claude Code:

claude mcp add --transport http my-mcp https://mcp-server.run.scalix.world/mcp \
  --header "Authorization: Bearer $MCP_API_KEY"

Use whatever path you mounted the transport on. Confirm with claude mcp list, or /mcp inside a session, which shows the connection status and the tools it picked up. Add --scope project to check the connection into a shared .mcp.json so teammates get it too. Cursor and other MCP clients take the same two inputs: a URL and a header.

Auth is not optional now

The moment your server has a public URL, every tool it exposes is public too. A stdio server needed no network auth because the trust boundary was your machine. An HTTP one has no such luck.

The workable default is a bearer token. Your server reads the Authorization header on every request, compares it against a key you issued, and rejects anything else. Keep the key in the environment, rotate by issuing a new one and retiring the old. The Model Context Protocol also defines an OAuth 2.1 based authorization model for HTTP transports, which is where you go when the callers are real end users rather than your own agents.

Whichever you pick, run the check before dispatching the tool call, not after it.

When not to self-host at all

Worth saying plainly, because a container tutorial has an obvious bias. Sometimes the correct amount of MCP server to run is none.

If what you want is tools for your cloud, so an agent can deploy a service or work a database, that server already exists and building it is wasted work. Scalix runs a hosted MCP server at api.scalix.world/v1/mcp that exposes the platform as 50 tools, with one API key authorizing all of them:

claude mcp add --transport http scalix https://api.scalix.world/v1/mcp \
  --header "Authorization: Bearer $SCALIX_API_KEY"

Nothing to build, nothing to host, no Dockerfile. Write and containerize your own when the tools are genuinely yours: internal APIs, your own data, domain logic nobody else has. That is when everything above earns its place. The longer version of that decision is in how to host an MCP server, and what an agent can actually do once it has cloud tools is in deploy with Claude Code.

Wrapping up

Containerizing an MCP server is not an MCP problem. It is the same job as containerizing any long-running service: pin the runtime, bind 0.0.0.0, read PORT, drop root, keep secrets out of the image. What is specific to MCP comes after the build, because the process in that container executes tool calls a model chose, which is why the isolation is doing real work and the auth is not a nice-to-have.

Build the image, run it locally, push it, deploy it, hand your agent the URL. You can start free at scalix.world with no card, and if you get stuck on the deploy, come find us on Discord.

How to Deploy with Claude Code (to a real cloud)

Sun, 02 Aug 2026 00:00:00 GMT

You have used Claude Code to write an app. It scaffolded the project, wrote the handlers, fixed its own bugs, and the thing runs on your laptop. Then you hit the wall every coding agent hits: it can write the code, but it cannot ship it. Deploying is still your job, in a different terminal, by hand.

That wall is not a Claude Code limitation. It is a missing connection. An AI agent can only act on the systems it has tools for, and by default it has no tools for your cloud. Give it those tools and deploying with Claude Code (or any MCP-compatible coding agent) stops being a figure of speech. The agent runs database migrations, pushes the app, and hands you a live URL, without leaving the conversation.

The gap between writing code and shipping it

A coding agent is good at the part that happens inside your repository. It reads files, edits them, runs your tests, and reasons about what broke. All of that lives on your machine, which is exactly where the agent already has reach.

Shipping is different. To deploy an app you have to talk to a cloud: create a service, run database migrations, push an image, wire up an environment variable, read back a status. Those are actions on a system outside the repository, and an agent cannot take an action it has no tool for. So it writes a perfect deploy script and then asks you to run it. Close, but you are still the one shipping.

The fix is to hand the agent real tools for your cloud. That is what the Model Context Protocol is for, and it is what turns "generate a deploy command" into "deploy an app with an AI agent."

Connect Claude Code to a hosted MCP server

MCP is an open standard for giving an agent tools it can call. An MCP server exposes a set of actions, and an MCP client, which is what Claude Code is, calls them. Point Claude Code at a server and its tools become things the agent can do, not just describe.

Scalix runs a hosted MCP server for exactly this. It sits at api.scalix.world/v1/mcp and exposes the platform as 50 tools: run queries and migrations, branch a database, deploy a service, check status, and so on. One API key authorizes all of it. Because the server is hosted and always on, you run and maintain nothing to use it. (If you would rather host your own MCP server instead, we wrote a full guide to that.)

Connecting Claude Code to an MCP server takes one command. Grab a Scalix API key from the console, then add the server over HTTP:

claude mcp add --transport http scalix https://api.scalix.world/v1/mcp \
  --header "Authorization: Bearer $SCALIX_API_KEY"

That registers the Scalix server for the current project. Add --scope project to share the connection with your team through a checked-in .mcp.json, or --scope user to make it available in every project on your machine.

Confirm the agent can see it:

claude mcp list

Inside a session, /mcp shows the connection status and how many tools it picked up. Once it reports connected, Claude Code has a working set of cloud tools. There is nothing to install. Claude Code MCP setup is a URL and a key, and the tools show up in the session.

What the agent can do once it is connected

With the Scalix tools available, the agent's reach extends past your repository and into your cloud. In plain language, you can now ask it to:

Set up and work the database. The agent creates a Postgres instance through the platform API with the same key, reads back the connection string, and from there the MCP tools take over: run queries, inspect the schema, apply migrations, spin up a database branch to test something risky. The same agent that writes the code querying a database can now stand up and operate the database it queries.
Deploy to Scalix Run. The agent builds or references a container image and creates a running service from it, then returns the URL.
Read status. It can check whether a deploy succeeded and see whether a service is healthy, which means it can also react when something is wrong. For the full log stream, scalix-cloud logs is a CLI command like any other, and a coding agent can run those too.

The last one matters more than it looks. An agent that can only fire off actions is a fancy script. An agent that can also read back what happened can deploy, notice the deploy failed, fix the code, and redeploy on its own. That loop is the difference between generating a deploy command and actually shipping.

A deploy walkthrough

Here is the concrete version. You have an app in your repo, the Scalix MCP server connected, and you want it live. Ask the agent, in the session, to ship it:

Deploy this app to Scalix Run. It listens on port 8080. Provision a Postgres database, pass the connection string in as an environment variable, and give me the URL.

The agent works through the tools in order: it detects the runtime, provisions the database, deploys the service, wires the connection string into the environment, and reports back. Scalix Run deploys straight from source and recognizes Node, Python, Go, Rust, or a Dockerfile, so if the agent just wrote the code, there is no separate build step to babysit.

The deploy itself maps to the same run command you would type by hand. With a prebuilt image it looks like this (the registry namespaces images under your project id):

scalix-cloud run deploy --name my-app \
  --image api.scalix.world/<project-id>/my-app:v1 \
  --port 8080 \
  --min-instances 1 --max-instances 5

You did not run it. The agent did the equivalent through MCP, which is the whole point. When it finishes, the service is live at a stable URL:

https://my-app.run.scalix.world

From here the loop stays inside the conversation. Tell it the app is throwing a 500 and it can check the status, pull logs through the CLI, patch the code, and redeploy without you switching tools. You describe the outcome; the agent operates the cloud.

Wrapping up

Deploying with Claude Code (or Cursor, or Windsurf) is not a special mode or a new product. It is your agent, plus tools for a real cloud, connected over one open protocol. Write the code in the session you already use, then let the same agent run database migrations and put the app online, and read back whether it worked.

If you want to try it, Scalix Run is the service the agent deploys to, and Scalix Coder is our own coding agent on the same platform if you would rather not bring your own. Point an agent at the MCP server, describe what you want live, and let it ship.

PostgreSQL 16, 17, and 18 on a Serverless Engine

Sat, 01 Aug 2026 00:00:00 GMT

On most managed Postgres, choosing a major version is a dropdown you touch once. You pick something recent, you forget about it, and eighteen months later a maintenance window quietly moves you along.

On a serverless engine that choice behaves differently, and it took us a while to say clearly why. When a database can branch, restore to a timestamp, and suspend to nothing between connections, the major version stops being a property of a running server. It becomes a property of the data.

ScalixNova now offers PostgreSQL 16, 17, and 18. Here is what that means once compute and storage are separated, and what we have not solved.

Picking a version

You choose the major at creation, and only at creation:

curl -X POST https://api.scalix.world/v1/databases \
  -H "Authorization: Bearer $SCALIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "prod", "pg_version": "18" }'

Omit pg_version and you get 16, the default. Ask for something unavailable and you get a 400 whose message lists the set that is available. The failure mode we refused to ship was the silent downgrade: you request 18, the platform hands you whatever binaries the host happens to have, and you find out during a migration that needs a feature your server does not have.

The supported set comes from one shared definition read at two edges: the gateway validates your request before a database exists, and the compute plane uses the same list to select server binaries. There is no gap where the API accepts a version the compute layer cannot start. For operators running Scalix on their own hardware that list is configuration rather than a rebuild, so a host without a given major fails closed instead of guessing.

The version is part of the data's identity

A ScalixNova database has no long lived server process to attach a version to. Compute is acquired when you connect and released when you are done. What persists is the data directory, the base backups, and the archived write ahead log. We walk through what each of those layers actually guarantees in how durability works in ScalixNova. So the question "what version is this database" cannot be answered by asking a running process. It has to be answered by the storage.

Postgres already solved this and we use its answer. initdb stamps the major into PG_VERSION in the data directory, and every path that starts a server against existing data reads that file to choose binaries. Cold start, branch, restore from a base backup, replay to an LSN: all of them resolve the major from the data, not from the request that triggered them.

The practical rule that falls out is: the backup's major wins. If a base backup came off a 17 server, it is replayed by 17 binaries, even if the environment around it has a different opinion. That is the only version of this that is safe, because Postgres itself will refuse to start otherwise, and the alternative is a restore that fails at the worst possible moment.

The same logic runs one layer up. pg_basebackup is version matched per worker to the server it backs up, because a 16 client cannot take a base backup of a 17 or 18 server. On a single version fleet you never notice this. With three majors live at once it is a correctness requirement, and getting it wrong is quiet: it produces a database with no base backup, and therefore no restore point.

One smaller detail in the same spirit: initdb --data-checksums is explicit on every major we run. Postgres 18 turns data checksums on by default and 16 and 17 do not, so leaving it implicit would give you a fleet where checksum behaviour depends on the year a database was created.

What stays boring

None of this should reach your application, and it does not.

ScalixNova is a purpose-built storage engine that speaks the PostgreSQL wire protocol. It is not a managed wrapper around upstream Postgres, and it is not a fork. We wrote the engine deliberately, for reasons we go into in built, not assembled. From your side of the socket the contract is the one you already know:

postgresql://t_a1b2c3d4e5f6:YOUR_API_KEY@db.scalix.world:6432/db_a1b2c3d4e5f6?sslmode=require

A standard DSN. psql connects. node-postgres, psycopg, SQLAlchemy, Prisma, Drizzle, and your migration tool connect. TLS is required, not optional, and connections without it are rejected. Your database role is a per database NOSUPERUSER role, assigned automatically.

The extension set is the same on every supported major. pgvector, pg_trgm, uuid-ossp, and the contrib set are available whether you picked 16 or 18, so the version choice does not quietly become an extension choice.

Everything version related is a control plane operation. Creating databases, branching, and restores go through the API, the CLI, or the SDK. Running SQL goes through your driver, unchanged. Keeping that boundary clean is why the client half of this post is so short.

Branches, restores, and why the major is fixed

The rule is: the major is fixed for the life of the database, and everything derived from that database inherits it.

Branch databases are isolated, carry their own scoped token and a TTL so scratch environments expire instead of accumulating, and run the same major as the parent. Point in time restores are the same story: base backups plus archived WAL, on a five minute bound while the database is active, with the open segment shipped when it suspends. A restore targeting a moment after the last archived point returns a 409 rather than silently handing you older data and calling it success.

Now consider what a mutable major would do to that. You have a database created on 16 and upgraded to 18 last month, and you restore to a timestamp from six weeks ago. Which binaries replay that WAL? There is no good answer. Physical WAL is not portable across majors, so a mutable major silently truncates your restore window at the upgrade boundary, and the truncation is invisible until you need it.

Pinning the major keeps the recovery window honest. Every point inside your retention is reachable with the binaries that wrote it.

A paused database also does not bill compute, which is a consequence of acquiring compute per connection rather than a Postgres feature. It is what makes "run 18 alongside your 16 for a while" a practical suggestion instead of a theoretical one.

What we have not solved

Fixing the major has a cost, and it is ours to state.

There are no in place major upgrades. To move from 16 to 18 you create a database on 18 and migrate with pg_dump and pg_restore, or with logical replication for a smaller cutover window. A managed blue and green cutover built on branching is roadmap, and roadmap is not product.

The dedicated tier runs 16 only. Multi version is generally available on the shared tier. The dedicated microVM tier is still on 16 and fails closed on other majors rather than starting something it cannot support.

The default deliberately trails the newest. New databases get 16, not 18. New majors arrive within roughly 90 days of community GA once the extension set is validated on them, each is supported to its community end of life, and default changes are announced ahead and never touch existing databases. If you want 18, ask for 18. We will not move you there while you are not looking.

Try it

If you run Postgres for a living, the question about any serverless engine is whether the boring guarantees hold. Which binaries replay your WAL. What happens when you ask for a version that is not there. Whether a restore can quietly return the wrong thing.

You can create a database on 16, 17, or 18 and check those yourself at Scalix Nova, without a card, on a one time trial credit. If you find a case where the version guarantee does not hold, we want to hear about it. Find us on Discord or X, and you will be talking to the two people who wrote the engine.

How durability works in a storage engine we wrote ourselves

Thu, 30 Jul 2026 00:00:00 GMT

Durability is the most overloaded word on a database landing page. Sometimes it means "we take nightly backups." Sometimes it means "we replicate." Occasionally it means "we have not lost anything yet."

None of those are the same guarantee, and the difference between them is what you need to know before putting state on someone else's infrastructure.

We wrote the storage engine, so we can be precise. ScalixNova speaks the PostgreSQL wire protocol, but underneath it is our own write ahead log rather than a managed wrapper around an upstream distribution. This post walks the write path and says what "durable" means at each boundary it crosses.

A write moves through four states. The engineering that matters lives in the transitions.

Accepted by the log's current term holder
Flushed and fsync'd into a WAL segment on local disk
Archived as a closed segment in object storage
Restorable to a point in time

1. Accepted: term fencing on a single writer

The log has exactly one writer at a time. That writer holds a term, a monotonically increasing number. Every append carries the proposer's term, and the acceptor compares it against the term it currently honours:

Proposer term lower than current: reject with a stale proposer error. Nothing touches the disk.
Proposer term higher: adopt the new term, then accept.
Equal: accept.

The obvious objection is that a single writer cannot split-brain by definition. It can, and that is the failure fencing exists for. The problem is not two writers running concurrently by design. It is one writer that has already been replaced, does not know it, and comes back holding a stale view of the log. A long garbage collection pause, a partitioned network, a slow restart after an operator action: any of those produce a process that still believes it is the writer.

Without fencing, that process appends after its successor already did, and you get one log with two divergent futures at the same LSN. Nothing in the byte stream tells you which branch is real. With fencing, its very first append is rejected on the term comparison, before a single byte is written.

Term is not just an in-memory counter. It is persisted alongside flush LSN, commit LSN and remote consistent LSN in the timeline metadata, written through a crash safe path: write a temp file, fsync it, rename over the target, then fsync the parent directory. After a crash the acceptor comes back knowing which term it last honoured. A stale proposer cannot win simply by outliving a restart.

2. Flushed: fsync, then acknowledge

An append computes the segment number and offset from the LSN, opens the segment file, seeks, writes, and calls sync_all() before returning. The flush LSN advances only after that fsync returns. If a record spans a segment boundary, each segment is fsync'd in turn.

There is a second rule in the append path that does more work than it looks like. Appends must be contiguous. If the incoming start LSN is not exactly the current flush LSN, the append is rejected with a gap error rather than written at the requested offset. A WAL with a hole in it is not a WAL. Refusing the gap at the append boundary means the recovery path never has to reason about what might be missing in the middle.

This is the layer where "durable" means what an SRE means by it. The bytes are on the device, and the acknowledgement is emitted after the fsync rather than before it.

3. Archived: local disk is one machine's opinion

An fsync'd segment survives a process crash. It does not survive the machine. Durability against machine loss means the log has to leave the machine, so two things go to object storage: base backups, and WAL segments as they close.

Which makes the interesting question not "do you archive" but "how far behind is the archive allowed to fall." Three bounds answer that:

While the database is active, the log is forced to switch segments on a five minute interval. A segment closes and ships whether or not write volume happened to fill it. Low traffic databases do not get a worse recovery point than busy ones.
When a database suspends, the open segment ships as part of the suspend path. Scale to zero is normal operation here, so the tail of the log cannot sit stranded on a machine waiting for a database that is not going to wake up on its own.
When the compute layer shuts down, it takes a base backup of every active worker before exiting, under a bounded deadline. A deploy is a planned event, and a planned event should not cost you a recovery point.

Together those put the most recent restorable point within roughly five minutes of your latest write while the database is active.

Alongside the segments we write a recovery catalog: points carrying LSN, timestamp and the segments needed to reach them, plus the earliest and latest recoverable LSN and time. Recovery has to know which segments it needs before it starts pulling them.

4. Restorable: what recovery actually offers

Two operations, kept deliberately distinct because they answer different questions:

Restore to a timestamp. POST /api/v1/tenants/{tenant_id}/pitr/restore restores by wall clock time, or to the latest recoverable point.
Branch at an LSN. POST /api/v1/tenants/{tenant_id}/timelines/{timeline_id}/branch with a branch_lsn creates an independent timeline at a specific position in the log.

Both run the same machinery: pull the base backup, replay archived WAL forward to the target, bring up a fresh compute worker pointed at the result. A branch is a point in time restore you keep, addressed by LSN instead of by clock. It gets its own worker and its own backup cycle, and writes on it never reach the parent. Deleting one purges its base backups and archived WAL and reports the object count reclaimed.

The failure mode we thought hardest about is asking to restore to a moment after the last archived point. Quietly handing back older data is the worst available answer, because the restore reports success and the gap only surfaces later, in your data. That request returns a 409 with guidance instead.

Retention defaults to seven days and is configurable per tenant. Separately from the continuous path, nightly encrypted backups are replicated off site to EU located storage. Routine restore drills for that off site path are still being operationalized, and we would rather say so than imply a rehearsed process we do not have yet.

What we do not have yet

Precision cuts both ways, so here is the other half.

Multi-node quorum is not wired. Term fencing, shard placement and the quorum commit LSN calculation are written and tested. The commit function sorts acceptor flush LSNs and returns the highest LSN acknowledged by at least a quorum. It is not running across nodes, and the reason is worth stating plainly: the gRPC accept path returns unimplemented on purpose. The protobuf message for WAL data carries no term field, so accepting there would mean inventing a term, and an invented term either wrongly rejects a legitimate proposer after recovery or silently overwrites a higher one. That is the exact failure mode fencing prevents, so refusing beats faking success. Single node writes go over the binary protocol, which carries a real term. When quorum lands, it lands on fencing that is already there.

One region. One EU region today. Losing it is a restore from off-site backup, not a failover. We would rather say that than imply a topology we do not run.

Restorability introspection is incomplete. The endpoint that would tell you how far back you can currently restore returns a 501 saying it needs the WAL archive catalog. It could return a plausible looking window instead. A recovery bound you cannot verify is worse than no answer, because someone will plan against it.

Durability is scoped to the project timeline. Backups, branches and point in time recovery operate on the project's timeline, which is how the console labels them. Per database granularity within a project is roadmap.

Support is the two of us. We are two engineers running our own European infrastructure. The people who wrote the WAL path are the people who answer when you ask about it.

Every one of those is a real limit, and every one is easier to close than a durability model that was assumed rather than designed. That is the trade we made when we built the platform instead of assembling it.

The recovery semantics above are documented at docs.scalix.world/database/backups. To run a restore yourself, you can start without a card on a one time trial credit at scalix.world. If you would rather argue with the design first, we are on Discord, and that is a conversation we want.

Built, not assembled

Tue, 28 Jul 2026 00:00:00 GMT

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 query 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. When something breaks, you talk to the engineers who built it. Those engineers are us.

The deal we are offering is not "trust the brochure." 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.

One key, one bill: the economics of an integrated cloud

Thu, 23 Jul 2026 00:00:00 GMT

Before we built Scalix World, Akhil and I ran the same stack every early-stage team runs. Managed database from one vendor. AI inference endpoint from another. Serverless compute from a third. Auth from a fourth. Each individually reasonable. Together, death by a thousand idle minimums.

The moment it clicked: we were paying roughly $45/month in base fees for a project with maybe fifty users. Not fifty thousand. Fifty. Most of those services sat idle most of the time, but each one had a floor -- a minimum tier ticking away whether we shipped anything that month or not.

The money was not the worst part. The worst part was four dashboards, four sets of API docs, four credentials to rotate, and absolutely no way to answer "what did last Tuesday cost?" without cross-referencing four invoices.

The fragmentation tax

Every managed service has a floor. A database provider's smallest tier runs $15/month even when your app handles twelve requests a day. An AI inference endpoint charges a base fee whether anyone calls it. A compute platform's always-on container has a minimum cost. These floors exist because those platforms keep resources warm for you -- regardless of whether you use them.

Then there is duplicate egress. Your function calls your database. The response flows to your AI endpoint. The AI response comes back through your function to the user. Three providers, three egress charges on the same data. The bytes do not know they are crossing billing boundaries. Your invoice does.

And the cognitive overhead of managing four of everything -- four billing cycles, four support channels, four auth systems to understand when something breaks at 2 AM -- is itself a cost nobody tallies.

What it actually costs

Here is a typical month for an indie hacker or early-stage founder running a low-traffic, bursty product across separate services. These are illustrative, rounded numbers -- not prices from any specific vendor, but representative of what entry tiers look like:

Line item	Illustrative monthly cost
Managed database (minimum tier, mostly idle)	~$15
AI inference API (low volume, base fee + tokens)	~$10
Serverless compute (a few functions, light traffic)	~$7
Auth service (small user base, near free-tier limit)	~$5
Object storage + CDN (a few GB)	~$5
Cross-provider egress	~$3
Total	~$45/mo

Forty-five dollars a month before you have revenue to justify it. Before you count the hours wiring four SDKs together or debugging auth token propagation between services.

On Scalix World, the same workload starts on a free tier -- no credit card, no time limit. When you go to production, the Starter plan is $19/month. That covers a Postgres-compatible database, AI inference, serverless functions, object storage, auth, and DNS. One API key. One dashboard. One invoice.

But the price difference is not the real story. The architecture is.

Zero actually means zero

When we say scale to zero, we mean the compute meter stops. A paused ScalixNova database does not tick at $15/month waiting for your next query. Compute billing stops the moment it suspends, and you keep paying only for the data you store, at $0.115 per GB per month. A function that has not been invoked today costs nothing in compute. An AI endpoint with no traffic costs nothing.

This is not a free tier with invisible limits. It is how the platform works at every level. Every service meters at the resource level -- compute time, storage bytes, tokens processed. When compute sits idle, the compute charge is zero; storage bills for the bytes you keep, nothing more. No minimum instance. No keep-warm fee. No "base infrastructure cost" line item hiding in your bill.

For bursty, agent-driven workloads, this changes the economics completely. An AI agent that runs ten minutes per hour and sleeps the rest pays for ten minutes. Not sixty.

One bill that tells a story

Unified metering matters beyond cost savings. It is about being able to read your own bill.

Every service on Scalix World -- database, AI, functions, storage -- meters through the same system, under the same API key, into the same ledger. When costs spike, you trace the cause to a specific service, a specific project, even a specific time window. No cross-referencing vendor dashboards.

And because the metering API is part of the platform, your tools can read it too. An agent operating on Scalix World checks its own usage, queries remaining credits, and makes cost-aware decisions -- programmatically, through the same key it uses for everything else.

The honest tradeoff

We are not claiming "we are cheaper" in every scenario. At high, sustained utilization, a fixed-price provider might cost less for that specific service. We are transparent about that.

The argument is narrower: for the workloads that define early-stage products and AI-native applications -- bursty, idle-heavy, unpredictable -- an integrated platform that genuinely scales to zero eliminates the floor that makes fragmented stacks expensive before you have revenue.

One key across every service. One bill that makes sense. Idle compute costs nothing. The free tier is live at scalix.world, no card required. We publish our uptime openly at status.scalix.world. If you want to be part of the founding design-partner cohort -- early access, grandfathered pricing, direct line to the two people building this -- DM me on X or come find us on Discord.

Remote vs Local MCP Servers, Explained

Thu, 23 Jul 2026 00:00:00 GMT

A local MCP server runs on your own machine. A remote MCP server runs somewhere always-on, at a URL, so anything you give permission to can reach it. That is the whole distinction, and almost every other difference between the two follows from it.

If you already know what an MCP server is, the local versus remote question is really a question about where the server lives and who gets to talk to it. Local is perfect for personal development. Remote is how you share a server with a team or put it in production. This post walks through the practical differences: transports, auth, access, and how to move from one to the other.

The one difference that matters

An MCP server is a program that exposes tools and data to an AI agent over the Model Context Protocol. It has to run somewhere, and that somewhere is the whole story.

A local MCP server runs as a process on your laptop. The AI client you use, an editor like Cursor or a chat app like Claude, launches it directly and talks to it on the same machine. Nothing leaves your computer. When you close the laptop, the server stops.

A remote MCP server, sometimes called a hosted MCP server, runs on a machine that stays on, at a stable network address. It does not care whether your laptop is awake. Any client you authorize, yours, a teammate's, or a production agent, can connect to the same URL and use the same tools.

Transports: stdio vs streamable HTTP

The clearest way to tell local and remote apart is the transport, the channel the client and server use to exchange messages. The Model Context Protocol defines two standard MCP server transports, and they map almost exactly onto local versus remote.

stdio is the local transport. The client starts the server as a subprocess and speaks to it over standard input and output, the same pipes a normal command-line program uses. There is no network involved. It is fast, simple, and only reachable from the one machine the process runs on. This is the default for local MCP servers.

Streamable HTTP is the remote transport. The server listens at an HTTP endpoint, and clients connect to it over the network like any other web service. It can stream responses back as they are produced, which is where the name comes from, and it is what lets a server at a URL serve many clients at once. When people talk about streamable HTTP MCP, this is the transport they mean.

So stdio vs HTTP MCP is not a style choice. stdio is for a server on your machine. Streamable HTTP is for a server other machines need to reach. Choosing the transport is choosing local or remote.

When a local MCP server is the right call

Local is the correct default more often than people expect. Reach for a local MCP server when:

You are building or prototyping a server and want a tight edit-and-test loop.
The tools touch things that only exist on your machine, like local files or a dev database.
The data is sensitive and you would rather it never leave your computer.
You are the only person, and the only agent, that needs it.

For a personal tool you use from your own editor, hosting it would add cost and moving parts for no benefit. Local wins.

When you want a remote (hosted) MCP server

You move to a remote MCP server the moment more than your own laptop needs to reach the tools. Common triggers:

A teammate wants to use the same server from their own agent.
A production agent, running on a server rather than your desk, depends on it.
You want the tools available on a schedule or around the clock, not only when you are at your machine.
Several clients or agents call it at once, and a single local process is no longer enough.

A hosted MCP server gives you one address that every authorized client shares, and uptime that does not depend on anyone's laptop. That is the difference between a tool you use and a tool your organization runs.

Authentication changes when you go remote

Auth is where local and remote genuinely diverge, and it is worth being deliberate about.

A local server over stdio needs no network authentication. The trust boundary is your machine. If someone can start the process, they are already on your computer. Secrets like API keys are usually passed in through environment variables or the client's config, and they stay local.

A remote server is reachable over the network, so it has to prove who is calling before it runs anything. Otherwise your tools are open to whoever finds the URL. The Model Context Protocol defines an authorization model for HTTP transports based on OAuth 2.1, and in practice remote servers are protected with OAuth or with bearer tokens and API keys. The rule of thumb: the instant a server leaves your machine, it needs real auth in front of it.

The migration path: local to remote

Going from local to remote is less work than it sounds, because the server logic, the tools it exposes, does not change. What changes is how it is reached.

Switch the transport from stdio to streamable HTTP, so the server listens on a port instead of talking over stdin and stdout. Most MCP server frameworks support both, so this is often a config change rather than a rewrite.
Add authentication, since the server is now exposed to the network.
Run it somewhere always-on, at a stable URL, and point your clients at that address instead of launching a local process.

The third step, the actual hosting, is its own topic. We wrote a full walkthrough in how to host an MCP server, from the four things hosting requires to a deploy you can copy.

Local and remote are not competitors. They are two stages of the same server. You build and test locally over stdio, and when the tool needs to be shared or run in production, you swap to streamable HTTP, add auth, and host it. If you get to that step and want somewhere to put it, Scalix Run hosts long-running services like remote MCP servers at a stable URL any authorized agent can reach. But start local. The move to remote is easy once you need it.

How to Host an MCP Server

Wed, 22 Jul 2026 00:00:00 GMT

You wrote an MCP server. It exposes a few tools, an agent on your machine calls them, and it works. Then you try to use it from somewhere else, or from a teammate's agent, or from a production workflow, and it does not work, because it only exists on your laptop and your laptop is not a server.

That is the whole problem. An MCP server is only useful when it is running somewhere an agent can actually reach, at a URL that does not change, without you keeping a terminal open. Hosting it is how you get there.

What hosting an MCP server actually requires

People overcomplicate this. An MCP server is a normal long-running program that speaks the Model Context Protocol over HTTP. Hosting it well comes down to four things.

A stable public URL, so an agent can find it tomorrow at the same address it found it today. Always-on uptime, so it answers whether or not your machine is awake. Authentication, so only your agents call your tools and not the whole internet. And room to scale, because the day two agents call it at once is the day a single process becomes a bottleneck.

Get those four right and you have a real MCP server. Everything else is detail.

Your options

You can host it yourself on a plain virtual machine. Rent a box, install your runtime, run the server behind a reverse proxy, add TLS, set up a process manager so it restarts on crash, and handle auth yourself. Total control, and total maintenance. You now own an operating system.

You can reach for serverless functions, but most MCP servers hold a connection open and keep some state across calls, which fights the request-and-forget model that functions are built for. It can work for the simplest tools and gets awkward past that.

Or you deploy it as a managed container service, which is the natural shape for a long-running server. You hand over an image, you get back a URL that stays up and scales, and you skip the operating system entirely. That is the path below.

Deploying on Scalix Run

Scalix Run runs long-running container services with a URL, autoscaling, revisions, and rollback. An MCP server is exactly that shape, so the deploy is short.

Build your server into a container image and push it to the registry, then deploy it:

scalix-cloud run deploy --name mcp-server \
  --image registry.scalix.world/my-org/mcp-server:v1 \
  --port 8080 \
  --min-instances 1

If you would rather deploy from source than build the image yourself, push your code to a Git repository and let the build service detect the runtime from your package.json, requirements.txt, go.mod, Cargo.toml, or Dockerfile, then produce the image for you.

That gives you the stable URL and the uptime. For authentication, put your server behind an API key so only your agents can call it, the same way every other request to the platform is authorized:

curl https://mcp-server.run.scalix.world/ \
  -H "Authorization: Bearer $SCALIX_API_KEY"

Scaling is a setting, not a project. Give it a floor and a ceiling and a target, and it adds instances when agents show up and removes them when they leave:

scalix-cloud run deploy --name mcp-server \
  --image registry.scalix.world/my-org/mcp-server:v1 \
  --port 8080 \
  --min-instances 1 --max-instances 10

Every deploy is a revision, so if a change misbehaves you roll back to the last good one in one command:

scalix-cloud run rollback <service-id>

The part most guides skip

Once your MCP server is hosted, it is a service like any other, which means it needs the same things your app needs. A database for the state your tools read and write. Object storage for files. Maybe a scheduled job to refresh something on an interval. On most stacks that is three more vendors, three more bills, and three more sets of credentials for your agent to juggle.

On Scalix it is one platform and one key. Your MCP server, its database, its storage, and its functions live behind a single API key, and that same key is what an agent uses to operate all of it. You host the server your agent calls, on the cloud your agent can also run. That is the point of building it as one system instead of gluing five together.

Start on the free tier, deploy your server, and point your agent at the URL. If you want to see a hosted MCP server's client configs before writing your own, ours are public at scalixworld/scalix-cloud-mcp.

What Is an MCP Server?

Wed, 22 Jul 2026 00:00:00 GMT

An MCP server is a small program that gives an AI agent a standard way to use tools and reach data outside its own model. That is the whole idea. If you have asked "what is an MCP server" and gotten a wall of jargon back, here is the plain version: it is the thing that lets an assistant read a file, query a database, or call an API, instead of only writing text about them.

MCP stands for the Model Context Protocol, an open standard for connecting AI agents and the apps they run in to the outside world. A server is one end of that connection. The agent is on the other end. When people say "an MCP server," they mean a program that speaks this protocol and offers up a set of capabilities any MCP-capable agent can use.

Why agents needed a standard in the first place

A language model on its own is sealed off. It can reason about your calendar, but it cannot open it. It can describe a SQL query, but it cannot run one. To do real work, an agent has to reach systems that live outside the model: your files, your database, a payments API, a search index.

Before MCP, every one of those connections was a custom job. If you had five AI apps and ten tools you wanted them to use, you were potentially building fifty separate integrations, each with its own glue code, its own auth, and its own quirks. Ten tools, five apps, fifty bespoke bridges that all break in different ways.

The Model Context Protocol collapses that. Build a tool once as an MCP server, and any MCP-capable client can use it. Build a client once, and it can talk to any MCP server. The problem goes from multiplying to adding. This is the same move USB did for hardware: one standard port instead of a drawer full of proprietary cables. The official docs describe MCP as a USB-C port for AI, and the analogy holds.

How MCP works: clients and servers

MCP has two roles, a client and a server, and understanding the split is most of understanding the protocol.

The server exposes capabilities. It is a program you (or someone else) writes that says "here are the things I can do" and then waits for requests. A server might wrap your company database, a GitHub account, a weather API, or a folder of documents.

The client lives inside the AI application and consumes those capabilities. The application itself is usually called the host. Think of a chat app like Claude, or the Cursor editor, or a custom agent you built. The host runs a client for each server it connects to, and that client is what opens the connection, asks the server what it offers, and relays the agent's requests back and forth.

So the difference between an MCP client and server is direction. The client asks; the server answers. One AI app can run many clients at once, each wired to a different server, which is how a single agent ends up with a database tool, a file tool, and a search tool all available in the same session.

Under the hood they exchange structured JSON messages, so any client and any server can understand each other regardless of what language either was written in. You do not need to know the wire format to use MCP, but it is why the whole thing composes so cleanly.

What an MCP server actually exposes

When an agent connects to an MCP server, the server advertises what it offers. Most of that falls into three kinds of capability.

Tools are actions the agent can take. Each tool has a name, a description, and a defined set of inputs, so the model knows when and how to call it. A search_orders tool might take a customer ID and return recent orders. A create_issue tool might take a title and a body and open a ticket. Tools are the part people mean most often when they talk about MCP, because they are what turn a chat assistant into something that acts.

Resources are data the server makes available for context: the contents of a file, a database record, a document. The agent reads them to inform an answer, without the server performing an action.

Prompts are reusable templates the server can offer. They are prewritten instructions for common tasks, so a user or an agent can trigger a known-good workflow instead of writing it from scratch.

Here is a concrete example. Say you run a support team and you build an MCP server for your helpdesk. It might expose a find_ticket tool, a reply_to_ticket tool, a resource for your canned-response library, and a prompt that walks the agent through triaging a new ticket. Connect that server to an assistant, and the assistant can now work your helpdesk directly, in plain language, with no custom app wrapped around it.

Local vs hosted: where the server runs

An MCP server has to run somewhere. On your own machine it runs as a local process, and the client talks to it directly. That is perfect for personal tools and for development. It only exists while your machine is on, and only your local agent can reach it.

The moment you want a teammate's agent to use the same server, or you want it available when your laptop is closed, or you want a production agent to depend on it, the server needs to be hosted: running always-on at a stable URL that any authorized client can reach. That is a separate topic with its own tradeoffs, and we cover it in detail in how to host an MCP server.

Do you need to build or host one?

Most people meet MCP as users before they ever build a server. You can install existing MCP servers today and connect them to an agent you already use. You only reach for building your own when you have a tool or a data source that no existing server covers, which, for anyone with an internal system, tends to happen fairly quickly.

If you do build one and want it reachable by more than the agent on your laptop, you will need somewhere to run it. That is where a platform helps: Scalix Run hosts long-running services like MCP servers with a stable URL and always-on uptime, so your agent can reach your tools from anywhere. But that is the next step.

For now, here is an MCP server explained without the jargon: it is how an AI agent reaches the real world, through one open standard instead of a hundred custom integrations. Learn what it is, and the rest of the ecosystem starts to make sense.

Sovereignty Is Now Law, Not Sentiment

Mon, 20 Jul 2026 00:00:00 GMT

Data sovereignty used to be a preference. Something privacy-conscious teams cared about, something most startups ignored because the defaults worked and the compliance pressure stayed abstract.

That is over. Not gradually -- legislatively.

The law moved

The EU Data Act is in force. It does not suggest that cloud customers should be able to switch providers and control their data. It requires it. Contracts must guarantee portability. Vendors must eliminate barriers to switching. International data transfer safeguards are mandatory.

The proposed Cybersecurity Act for Digital Autonomy -- CADA -- goes further. It introduces assurance levels for cloud services, effectively a certification system that grades providers on data residency, operational control, and immunity from extraterritorial jurisdiction. The highest assurance level demands that processing and storage occur within the EU, operated by EU-headquartered entities, with no legal exposure to third-country government access. This is not a guideline. It is a procurement filter. Public sector and critical infrastructure buyers will be required to meet it.

India's Digital Personal Data Protection Act gives the government power to restrict cross-border data transfers for specific categories of personal data. The implementing rules are being finalized. When they land, companies processing certain data categories will need infrastructure that keeps data within Indian borders. Provably resident, not "primarily in India with some processing elsewhere."

Over 40 countries now have some form of data localization requirement on the books. The EU and India matter most to us because that is where we operate and where our early users are.

The structural problem

The dominant cloud platforms are operated by US-headquartered companies. I am not making a political statement. This is a legal fact with specific consequences.

US-headquartered cloud providers are subject to the CLOUD Act, which allows US law enforcement to compel disclosure of data stored abroad. That is exactly the kind of extraterritorial legal exposure CADA's highest assurance levels are designed to exclude. A Postgres database hosted in Frankfurt by a US company is geographically in the EU but legally accessible from outside it.

For most startups today, this does not matter. They are not in regulated sectors, not selling to public sector buyers, and their data is not sensitive enough for jurisdiction to be a concern. But the direction is clear. The EU is building a procurement framework that will require sovereign infrastructure. India is building a data protection regime that will restrict outbound transfers of specific data categories.

If you are a developer in Bangalore building a health-tech product, or a founder in Berlin targeting public sector procurement, the cloud you choose today determines whether you need a migration tomorrow.

"EU region" is not sovereignty

This distinction gets blurred in marketing constantly, so I will be blunt about it.

Running a workload in a European data centre owned by a US company does not make it sovereign. The data is geographically local but legally exposed to foreign jurisdiction. The operational control -- who accesses the systems, who responds to law enforcement requests, which legal entity holds the customer relationship -- remains with a US parent company.

Sovereignty means three things and most "EU region" offerings deliver only the first. The data physically stays in the jurisdiction -- that is table stakes. The infrastructure is operated by an entity headquartered there, with no obligation to disclose data to foreign governments -- that is where most offerings fall short. And the customer can leave, with data exports in standard formats and no lock-in through proprietary APIs that make switching prohibitively expensive. The EU Data Act makes that last part an explicit legal requirement.

What we built

We did not start with sovereignty as positioning. We started with a practical constraint: we needed to operate our own infrastructure without depending on any hyperscaler control plane.

The result is a platform running on dedicated European infrastructure we operate ourselves. Not resold capacity from a US provider. Not a "region" inside someone else's cloud. Infrastructure we control, operated by our own entities.

Scalix World Pvt Ltd is incorporated in India. Energy FW Ltd is incorporated in the UK. Independent companies -- not subsidiaries of a US parent. When we say your data stays in the EU, we mean it stays on infrastructure operated by entities with no US legal exposure.

For developers, this means a modern cloud platform -- Postgres-compatible database with scale-to-zero, AI inference, serverless functions, container deployments, object storage, auth -- without giving up data residency. You do not have to choose between sovereignty and developer experience.

India is next. When the DPDP implementing rules define restricted data categories, we will have infrastructure in-country, operated by the Indian entity. Not a rushed response to regulation, but a planned expansion of the same architecture.

The honest version

We are not arguing every developer needs a sovereign cloud. Most consumer apps with no regulatory exposure can use whatever works.

But if you are building something that will sell to regulated buyers in the EU, or process restricted data in India within the next two years, choosing sovereign infrastructure now avoids a forced migration later. The developers who need it should not have to sacrifice modern tooling to get it.

We are early. One EU region. Two founders, on call, building in the open. We publish our uptime at status.scalix.world because transparency is not optional when you are asking people to trust you with their infrastructure. Try the platform free at scalix.world, find us on Discord, or DM me on X if you want to be part of the founding design-partner cohort and help shape how sovereign cloud gets built.

Where does your agent's API key actually go?

Sat, 18 Jul 2026 00:00:00 GMT

You gave your AI agent an API key. That key is a password with real power: it can read your data, deploy your code, and spend your money. Do you know how many companies' servers see it?

If you connected through an MCP directory, the honest answer might be: one more than you think.

Two ways to connect an agent

When your agent connects to a remote MCP server, there are two architectures, and they look identical from the chat window. In plain terms, either you have a direct phone line to the company you're doing business with, or someone else's switchboard sits in the middle of every call. The switchboard hears everything, including the password.

Direct-connect. Your client talks straight to the vendor's endpoint:

your agent ──────────────► api.vendor.com

Your API key goes to the company you gave it to. Your tool calls travel between you and them: the SQL you run, the files you upload, the results that come back. Two parties.

Gateway-mediated. Your client talks to the directory's gateway, which forwards to the vendor:

your agent ──► directory gateway ──► api.vendor.com

Same chat window. Same tools. One difference: every request now passes through a third company's infrastructure. Your bearer token, your query arguments, the vendor's responses, all of it.

This isn't a secret or a scandal. Gateway operators describe it openly, and several advertise full call logging, usage analytics, and managed credentials as features. For some use cases those are genuinely useful. The problem isn't that gateways exist. The problem is that most people connecting an agent don't realize which architecture they just chose.

Why this matters more for infrastructure

For a weather-lookup tool, a middleman seeing your calls is a shrug.

For infrastructure it's a different conversation. When your agent operates your cloud, the tool calls are your data. A db_query argument is your SQL and your schema. A storage_upload is your file. The response to a usage tool is your billing profile. If those pass through a gateway, then that operator's security posture, retention policy, and subpoena surface just became part of your stack. And you probably never read their terms, because you never chose them on purpose.

Then there's the key itself. Agents authenticate with long-lived bearer tokens, passwords that stay valid for months. Every extra company that handles one is another place it can leak from. Scoped keys and rotation reduce the damage. They don't change the architecture.

The 30-second check

You don't need anyone's permission to find out which architecture you're using:

Look at the URL your client actually connects to. Open your MCP config. If the url is the vendor's own domain, you're direct. If it's the directory's domain, there's a middleman.
Read the directory's publish page. If the pitch to server developers shows a connection diagram with the directory in the middle, or sells "call logging" and "managed credentials", mediation is the product.
Check the vendor's docs. A vendor that wants you connecting directly will publish the raw endpoint and the exact config. If you can only reach a server through a directory, ask why.

Run that check on every MCP server that touches anything you'd mind a third party reading.

Where we stand

Scalix Cloud is an agent-native platform, 50 tools behind one MCP endpoint, so we had to take a position on this early. Holding it cost us something.

Our position: we list our server only where users connect directly to our endpoint. We're on the official MCP Registry and the community directories that publish our raw URL. We declined listings, including on some of the largest directories, where the default path would route our customers' keys and payloads through someone else's gateway. Fewer badges, cleaner architecture.

That's not because gateways are evil. It's because we sell infrastructure to people who care where their data travels, and "your agent talks to your cloud, and nobody else is on the line" is not a claim we're willing to asterisk. We build on the same principle all the way down the stack. It's the reason the platform runs on sovereign infrastructure in the first place. Sovereignty that stops at the agent channel isn't sovereignty.

One key. One endpoint. Two parties.

And don't leak the key on your own side either

While we're being honest about key paths: the most common leak isn't a gateway. It's your own config. Two mistakes we see constantly.

Baking the key into the saved config. If you run --header "Authorization: Bearer $SCALIX_API_KEY" in double quotes, your shell fills in the real key before the client saves it. The raw key ends up written to disk in the config file, and in your shell history. It's the digital equivalent of writing your PIN on the back of the card. Config files get synced between machines, published in dotfile repos, and read by every tool that touches them.

One god-key for every agent. If every tool shares one full-power key, any single leak is a full compromise, and your audit log can't tell your agents apart. It's one master key to the whole building, copied for every contractor.

Here's the config we actually recommend. The real key stays in your environment or your OS keychain, and the file holds only a reference:

{
  "mcpServers": {
    "scalix": {
      "type": "http",
      "url": "https://api.scalix.world/v1/mcp",
      "headers": { "Authorization": "Bearer ${SCALIX_API_KEY}" }
    }
  }
}

Claude Code fills in ${SCALIX_API_KEY} from the environment when it reads .mcp.json, so the file never contains the secret and is safe to commit. Most modern clients support some form of environment reference. Where one doesn't, keep the key in a secret manager and inject it at launch.

And mint the key to fit the agent, not the account. Scalix keys are scoped, so a key without services:deploy cannot deploy, through MCP or anywhere else. Read-only keys are refused every mutating tool: they can look but not touch, like giving a guest the Wi-Fi password instead of the safe combination. One key per agent keeps the blast radius small and makes the audit trail name the actual culprit.

Setup for every client is at docs.scalix.world/mcp. The handshake is open: point any MCP client at the endpoint and tools/list works without a key. You can inspect exactly what your agent would get before you trust us with anything. And if you want to see what a directly-connected agent can actually do with those tools, start free at scalix.world and point your client at the endpoint.

How an AI Agent Operates a Cloud

Fri, 17 Jul 2026 00:00:00 GMT

The agent wrote a clean Flask backend. Routes, models, tests, even the Dockerfile. Then it stopped and asked us to provision the database.

That is the gap. An agent understands every line of the code it just produced, but the moment you need a Postgres instance created, a container deployed, environment variables set, or DNS configured, the agent hands the work back to you. You alt-tab into three different consoles. Copy a connection string. Push a container image. Debug a health check. The agent sits idle, waiting.

This is not a limitation of the agent. It is a limitation of the infrastructure. Most cloud platforms were built for humans navigating dashboards. Their APIs are afterthoughts -- programmatic alternatives to GUIs, not surfaces designed for autonomous software to operate. Auth is fragmented across services. Billing lives somewhere else entirely. Observability requires yet another vendor.

We built Scalix World around a different assumption: the next generation of cloud infrastructure must treat agent-operability as a first-class concern.

One key, one gateway

Every Scalix World service -- ScalixNova (database), AI inference, Run (compute), serverless functions, object storage, auth, billing -- sits behind a single authenticated gateway. One API key grants access to the entire platform. One bill covers all usage.

This is an architectural requirement for agents, not a design preference. An agent holding one key can query a database, deploy a container, configure auth, read logs, and check its own spend through the same control plane. Hand an agent keys to five services with five auth models, five rate limits, and five billing systems, and you have a fragile pipeline that breaks at every boundary.

What the agent actually does

Here is the task: "deploy the payments service with a dedicated database."

The agent creates a ScalixNova instance. No instance size to choose -- ScalixNova scales to zero when idle.

POST /v1/databases
{
  "name": "payments-db",
  "engine": "postgres",
  "region": "eu-central"
}

Connection string comes back. The agent feeds it straight into the next call, deploying the payments service on Scalix Run inside its own hardware-isolated microVM:

POST /v1/services
{
  "name": "payments-api",
  "image": "registry.scalix.world/acme/payments:v1.2.0",
  "env": { "DATABASE_URL": "postgres://..." },
  "resources": { "cpu": "0.5", "memory": "512Mi" }
}

Then auth -- an API client with scoped permissions for the service's public endpoints:

POST /v1/auth/clients
{
  "name": "payments-public",
  "scopes": ["payments:read", "payments:write"],
  "redirect_uris": ["https://app.acme.com/callback"]
}

Then the agent checks its own work. Reads logs, queries database metrics, pulls billing usage. Same key, same session. Four calls to go from nothing to a deployed, authenticated, observable service. No human needed for any of it.

MCP as the agent-native surface

The REST API works for any HTTP client. But agents using the Model Context Protocol get something purpose-built. We expose MCP tools across databases, deployments, storage, AI inference, auth, billing, and logs. Each tool is declared with its schema and constraints. The agent does not read API documentation. It discovers what it can do from the tool definitions directly.

A concrete example: the agent needs a branch of a production database, restored to a point in time to test a migration. In a traditional workflow, a human navigates a console, finds the branching feature, names the branch, waits, runs the migration, remembers to clean up. With MCP, one call:

tool: scalix_db_branch_create
args: { "database_id": "payments-db", "branch_name": "test-migration-v2" }

Full fork. Zero storage overhead until data diverges. The agent runs its migration, verifies the schema, promotes or drops the branch, and moves on. One step in a larger workflow, not a side quest.

How guardrails work

Giving an agent cloud access raises the obvious question. We answer it with layers, not blanket restrictions.

Routine operations -- creating dev resources, reading logs, querying metrics, checking billing -- run without interruption. Blocking on human approval for every API call defeats the purpose. But deleting a database, deploying to production, changing billing plans, modifying auth on live services -- those pause for human review. The agent prepares the action, presents context, and waits.

Projects have budget limits. If the agent's actions would push usage past a configured threshold, the operation holds. The agent can always check its spend. It cannot silently exceed a cap. And API keys can be scoped to specific services, projects, and actions -- a CI/CD agent might deploy and read logs but never touch databases or auth. Least privilege by default, explicit grants for each capability.

This is how well-run engineering teams already work. Automate the routine, gate the consequential, scope tightly. We made it a platform feature instead of something you bolt on with wrapper scripts.

Why one surface matters

Every service boundary an agent crosses -- different auth, different error formats, different rate-limit headers -- is a failure mode. A unified platform eliminates those boundaries. One credential replaces secret sprawl. One error model replaces four. One billing surface lets the agent answer "how much did this workflow cost?" without aggregating invoices from multiple vendors.

We are not claiming this is the only way to build agent-operable infrastructure. But the unbundled approach -- agents stitching together databases from one provider, compute from another, storage from a third -- is a complexity tax developers should not pay and that agents handle poorly.

Where we are

We are honest about stage. Scalix World runs on dedicated European infrastructure we operate. One EU region today, India next. The founders are on call. The platform is live: sign up, provision a database, deploy a service, point an agent at it.

We are building a founding design-partner cohort for teams whose agents need infrastructure they can actually operate -- early access, grandfathered pricing, a direct line to us. Start free at scalix.world. We publish our uptime at status.scalix.world because we think you should be able to verify before you trust. Come talk to us on Discord, or DM me on X if you want in on the cohort.

Meet Scalix World — The AI-Native Neocloud

Wed, 15 Jul 2026 00:00:00 GMT

Yesterday, we took Scalix World public, quietly, the way we like it.

The question that started this

AI agents can write an entire application in minutes. Then they hit a wall. The cloud underneath still expects a human: clicking through dashboards, juggling vendor accounts, wiring credentials between services that don't know about each other.

The tools for writing software became agent-native. The infrastructure for running it didn't.

What we built

Scalix World is the AI-native neocloud: a fully managed cloud platform engineered from the ground up as one system.

Database: Postgres-compatible, with scale-to-zero, so idle costs nothing
AI: one API for AI workloads, with routing, metering, and spend controls built in
Compute & Functions: isolated microVMs and serverless functions
Storage, Auth, Email, Billing: production primitives that work together out of the box

One API key covers all of it. One bill. And every primitive is operable two ways: by humans through a console, and by AI agents through the same control plane. An agent holding one key can query a database, deploy a service, read the logs, and check its own bill. Guardrails hold the consequential actions: spend, deletes, and production changes wait for human approval.

Agents do the routine. You keep the judgement.

Sovereign by design

Sovereignty is now law, not sentiment. European rules increasingly require data residency, and India is moving the same way. Most modern developer clouds can't offer it. We made it a foundation. Scalix World runs on dedicated European infrastructure we operate ourselves, with India next: data residency without giving up modern developer experience.

Where we are, honestly

We're early, and we'd rather say so than pretend otherwise. One region today. There's a public status page at status.scalix.world and two founders on call when something breaks. That honesty is also the offer. The founding design-partner cohort opens this month: direct founder support, grandfathered early pricing, and a real say in the roadmap.

Try it

Start free at scalix.world, no card required
Watch the platform status we hold ourselves to: status.scalix.world
Join the community: discord.gg/Ktq9qvpzBM
Building agent-native software? DM Kiran on LinkedIn or X about the founding cohort

The agent era needs its own cloud. We built it.

— Kiran & Akhil