Skip to content
SmolClouds

smolClouds — Your agents build it. SmolClouds runs it. Cloud infrastructure for agent-generated software.

01 / 04 · Ask

you

“Turn this CSV into a dashboard and share it with the team.”

claude code · thinking

A request in plain language.

Platform log

Apps waking, serving, and going back to sleep.

Every app on the platform spends most of its life stopped. The log is mostly the sound of things falling asleep again.

Illustrative — shows the shape of the event log, not live account data.

connecting…

The lifecycle

An app that costs nothing while nobody uses it.

Between requests the microVM is fully stopped. When a request arrives it is restored from a memory snapshot — already booted, already warm — serves the response, and goes back to sleep.

  1. 01

    Sleeping

    No request, no running VM, no compute being billed.

  2. 02

    Restoring

    A request arrives and the VM is restored from its memory snapshot.

  3. 03

    Running

    The app serves traffic with the state it already had in memory.

  4. 04

    Back to sleep

    Idle again — the VM stops and the snapshot stays on disk.

sales-report

Sleeping
snapshot

No active compute

Last request4 hours ago
Requests this month17
Active time6m 42s
Cost$0.04

The problem

Most software does nothing most of the day.

40 apps deployed.

1 running.

Why pay for 40 servers?

your account40 apps
  • invoice-reportsleeping
  • csv-dashboardsleeping
  • approval-toolsleeping
  • internal-apisleeping
  • customer-lookupsleeping
  • migration-helpersleeping
  • price-calculatorsleeping
  • onboarding-checklistsleeping
  • slack-digestsleeping
  • expense-parsersleeping
  • lead-scorersleeping
  • pdf-splittersleeping
  • inventory-syncsleeping
  • qa-checklistsleeping
  • release-notessleeping
  • webhook-relaysleeping
  • shift-plannersleeping
  • contract-diffsleeping
  • survey-viewersleeping
  • uptime-pingersleeping
  • budget-trackersleeping
  • sku-mappersleeping
  • email-parsersleeping
  • photo-resizersleeping
  • tax-tablesleeping
  • ticket-triagesleeping
  • meeting-notessleeping
  • vendor-listsleeping
  • churn-alertsleeping
  • log-greppersleeping
  • form-buildersleeping
  • asset-taggersleeping
  • payroll-checksleeping
  • seo-auditsleeping
  • crm-exportsleeping
  • note-searchsleeping
  • deploy-botsleeping
  • sitemap-gensleeping
  • sales-dashboardrunning
  • receipt-ocrsleeping

How it works

Three steps, no infrastructure decisions.

01 Build

  • Claude Code
  • Codex
  • Cursor
  • Your code

02 Deploy

  • $ smolclouds deploy

03 Done

  • your-app.smolclouds.com

SmolClouds handles builds, routing, isolation, HTTPS and scale-to-zero.

Built for agents

Built for agents, not dashboards.

Deployment is an API call, not a console session. An agent can ship an app end to end without a human clicking through a control panel.

  1. YOU
  2. CLAUDE / CODEX / CURSOR
  3. SMOLCLOUDSPOST /deploy
  4. LIVE APP

You: Turn this CSV into a dashboard and share it with the team.

Claude: Building…

Deploying to SmolClouds…

Done: sales-q3.smolclouds.com

Use cases

Perfect for the software nobody wants to host.

Internal Tools

Approval flows, admin tools, team utilities.

Dashboards

Reports, analytics, CSV visualizers.

AI Tools

LLM wrappers, assistants, workflow utilities.

APIs & Webhooks

Low-traffic APIs and event receivers.

Agent Apps

Claude Code, Codex and Cursor generated software.

Temporary Tools

Migrations, one-off utilities, prototypes.

Sleep / wake economics

Zero traffic. Nearly zero compute.

Idle apps are not throttled or scaled down — they are stopped. The cost of an app tracks the time it actually spends serving requests.

No requests

  1. Application

  2. Sleeping

  3. No active compute

Request

  1. Wake

  2. Application ready

  3. Response

Cold wake (p95)

Benchmark pending

Time from request arriving at the edge to the restored app responding.

Warm request

Benchmark pending

Response time while the microVM is already running.

Compute billed while idle

None

A sleeping app has no running VM, so there is no active compute to bill.

Architectural: the microVM is stopped between requests.

We publish a latency figure only once it comes from a benchmark we can reproduce and describe. Until then this space stays empty on purpose.

Architecture

Tiny apps deserve serious isolation.

Small does not mean shared. Each application gets a hardware-virtualised boundary — the same primitive that runs serverless workloads at large cloud providers.

SmolClouds Host

Shared Runtime Snapshot

microVM

App A

microVM

App B

microVM

App C

copy-on-write memory · isolated kernels · private network namespace

Firecracker microVM isolation

Every app runs in its own microVM with its own kernel — not a shared process or container namespace.

Shared warm runtimes

VMs derived from the same base image share memory copy-on-write, so identical runtime pages are stored once.

Sub-second wake architecture

Waking restores a memory snapshot of an already-booted app instead of running install, boot and warm-up.

Read how SmolClouds works →

Developer experience

One command, from repo to URL.

The CLI detects the runtime, builds the app and returns a live HTTPS URL. The same actions are available over the REST API, which is how agents deploy.

  • Runtime detection — no Dockerfile required
  • HTTPS and a smolclouds.com subdomain by default
  • Environment variables encrypted at rest
  • Every CLI action available over the REST API
smolclouds — cli

$

Comparison

Where SmolClouds is different.

Other platforms can host these apps — several of them well. The difference is what the platform is optimised for: hundreds of mostly-idle apps deployed by agents.

CapabilitySmolCloudsTraditional cloud
Agent-first deployVaries
Scale-to-zeroVaries
App-based UXUsually infra-based
microVM isolationVaries
Optimized for hundreds of tiny appsGeneral purpose
GitHub deploy

Pricing

Keep hundreds of small applications deployed.

Pay for the platform and the resources that actually run. Sleeping apps consume no active compute.

Builder

$9/month

For individual developers.

50 apps

Start building

Pro

Most popular

$29/month

For developers building with agents.

250 apps

Go Pro

Team

$79/month

For engineering teams.

1,000 apps

Start with Team

Free and Scale plans also available.

View all pricing →

Security

Security by isolation.

The isolation boundary is a virtual machine, not a process. That is the same boundary large clouds use for untrusted multi-tenant workloads.

Firecracker microVMs

Each application runs inside its own hardware-virtualised microVM with a separate guest kernel.

Tenant isolation

Applications belonging to different accounts never share a guest kernel or a filesystem.

Encrypted secrets

Environment variables are encrypted at rest and injected into the VM at start, never written into build artifacts.

TLS everywhere

Every smolclouds.com subdomain and every custom domain is served over HTTPS with certificates issued and renewed automatically.

Runtime isolation

Snapshot memory shared between VMs is copy-on-write and read-only from the guest's perspective.

Network isolation

Each microVM gets its own network namespace; inbound traffic reaches the app only through the platform router.

Read the full security overview →

Build as much small software as you want.

Deploy the first one in a couple of minutes. It sleeps when nobody is using it.