DEV Community: Scalix World

Sovereignty Is Now Law, Not Sentiment

Scalix World — Mon, 20 Jul 2026 00:00:00 +0000

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. No SLA -- 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?

Scalix World — Sat, 18 Jul 2026 00:00:00 +0000

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.

How an AI Agent Operates a Cloud

Scalix World — Fri, 17 Jul 2026 00:00:00 +0000

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 provision 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 copy-on-write branch of a production database 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. No SLA -- 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

Scalix World — Wed, 15 Jul 2026 00:00:00 +0000

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 provision 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. No SLA yet. Instead 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