Connectivity · Magic Cloudlets

One cloudlet. Every direction.

A cloudlet is the junction box of your stack. Agents call in over MCP, applications over plain HTTP. Your databases and SaaS estate hang off the back. And one role model decides who gets through — in every direction at once.

Four SQL engines Any MCP harness OpenAPI on every module SSO ready
The junction box
In — AI agents: every endpoint offered as a callable MCP tool
In — your apps: plain HTTP, with an OpenAPI spec per module
In — your visitors: embeddable chatbots on any page
↓ ↑
The cloudlet: one role model gating every direction
↓ ↑
Out — databases: SQLite · MySQL/MariaDB · PostgreSQL · SQL Server
Out — plugins: Shopify, HubSpot, NetSuite, OpenAI, Ollama…
Out — anything with a URL: on demand, or on a schedule
What calls in

Three front doors, one backend.

Everything you build or generate on a cloudlet is reachable three ways — by agents, by applications, and by the people on your website. Same endpoints, same role gates, three audiences.

Agents · MCP

Your backend, as a toolbox

With the MCP plugin installed, a cloudlet presents every endpoint you've built or generated as a callable tool to any MCP-capable harness — Claude, Cursor, Codex, or whatever your team runs. Generate a capability in the morning; your agent is invoking it by lunch.

Apps · HTTP

APIs any frontend can eat

Generated endpoints are ordinary HTTP with JSON in and out, and every module publishes its own OpenAPI specification. Web frontends, mobile apps, integration platforms — if it speaks HTTP, it's already compatible, with zero bespoke glue.

Visitors · Chat

A chatbot grounded in your content

Point the cloudlet at your website and it turns what it finds into training material for an embeddable chatbot — dropped onto any page with a single snippet, answering from your material rather than the open internet.

What it connects to · Databases

Four engines. Zero migrations.

SQLite ships inside every cloudlet. MySQL and MariaDB, PostgreSQL, and Microsoft SQL Server connect from outside — and once connected, the platform stops caring which is which. Querying, visual schema design, and endpoint generation all treat an external database exactly like a local one.

The engine that matters most in the mid-market is the last one. SQL Server estates hold decades of operational truth and aren't migrating anywhere — a cloudlet wraps that estate in generated, role-gated endpoints instead of asking you to move it first.

Your data stays put. The capabilities come to it.
The usual demand "Migrate to our database first — then the platform works"

Your existing estate becomes the onboarding project
Magic Cloudlet Point it at what you already run

SQLite · MySQL/MariaDB · PostgreSQL · SQL Server — treated as local once connected
What it connects to · Services

The catalog: one click, endpoints and all.

Plugins install into your cloudlet in a single click, arriving with their endpoints ready — no deployment ceremony. A sample of what's on the shelf:

Commerce

Shopify — orders, products, and customers reachable from generated logic, so agents and workflows can act on your store instead of just reporting on it.

CRM & ERP

HubSpot and NetSuite — the systems of record your revenue team lives in, exposed to the same workflows and agents as everything else on the cloudlet.

AI providers

OpenAI, Ollama, and HuggingFace — frontier models over the wire, or fully local ones when the data must never leave the building. The cloudlet doesn't care which.

Email

SMTP — transactional mail from workflows, passwordless sign-in links, and scheduled-task alerts, through whatever mail infrastructure you already trust.

Content & scraping

Crawl websites into chatbot training material or structured records — the same machinery behind the chatbot wizard, available to your own workflows.

And the rest

A couple dozen more in the catalog, growing — plus your own modules, installable from a ZIP when what you need is something only your team has built.

What it connects to · Everything else

No plugin? If it has an API, it's a sentence away.

Generated logic makes outbound HTTP calls like any backend — so a service without a ready-made plugin isn't a gap, it's an integration you describe in plain language and generate. The result is gated by roles like everything else on the cloudlet, because integrations don't get a side entrance.

Scheduled tasks put those calls on a clock: nightly syncs, hourly polls, weekly report runs — fired on an interval, at a fixed date, or on a pattern you define.

The connector you're missing is a description, not a roadmap item.
Integration platforms Wait for the vendor to ship the connector

Your integration backlog is their product roadmap
Magic Cloudlet Describe the call → generated, role-gated, schedulable

Reachable today, on your terms
Who gets through

Every connection walks through the same door.

Sign-in runs over OIDC — Google, or any provider you register — alongside passwordless email links and classic credentials. Machines authenticate with service tokens: JWTs scoped to exactly the roles you choose, expiring on a date you set, which is what CI pipelines and integrations present.

The point isn't the menu of methods. It's that every one of them resolves to the same role objects the runtime gates every endpoint with. There is no separate "integration auth" universe of loose API keys taped to the side of the system — the same enforcement described on our security page covers a human in a browser and a nightly job alike.

One access model. Humans, agents, and cron jobs all answer to it.
Scattered secrets One long-lived key per integration

Rotated rarely, scoped loosely, revoked never
One role model Tokens scoped to roles, with expiry you set

Enforced by the runtime on every call, every direction
The fine print, up front

What "connects" means. And what it doesn't.

Not everything is a toggle

A system without a plugin is an HTTP integration you generate — fast, but a build, not a switch-flip. External services keep their own rate limits, auth quirks, and outages, and no cloudlet changes that. And a connection is exactly as safe as the roles you gate it with: connecting a thing doesn't sanctify it. When a system needs deeper work than a described integration, that's a custom job — scoped and quoted.

What every connection inherits

Whether the caller is an agent over MCP, a frontend over HTTP, or a nightly job reaching out to a SaaS API, the traffic passes the same runtime gates — role checks at the endpoint, capability grants on the logic. Integrations don't bypass the model. They live inside it, which is the whole reason connecting things to a cloudlet doesn't multiply your attack surface the way connecting things usually does.

Talk to an engineer, not a sales deck

Bring your stack.

20 minutes. Name your databases, your SaaS, your agent harness — and we'll tell you plainly what's a plugin, what's generated, and what's a custom job.