splootprivate beta soon
Join the waitlist

A cloud for small software

Upload anything.
It just runs.

Claude just built you a tool, maybe a tracker, maybe the dashboard shaped exactly like your job. Sploot is where it goes next. Hand over the code and get back a live link your team can open, with your company's sign-in already on the door.

No IT ticket. No config files.

One email when the doors open. No drip campaign, no “growth hacking.”

  • free while nobody’s using it
  • sealed in its own sandbox
  • share like a Google Doc
~/sprint-tracker.zip
  1. sploot up ./sprint-tracker.zip
  2. unpacking 41 files
  3. languagepython 3.12(found pyproject.toml)
  4. frameworkfastapi + uvicorn
  5. system depslibpq5, poppler-utils
  6. servicespostgres 16(detected via DATABASE_URL)
  7. entrypointuvicorn app:api --port $PORT
  8. mcp servergenerated· 6 tools from 6 routes
  9. authgoogle workspace· your-team.com
  10. livehttps://sprint-tracker.sploot-app.com

The problem

Building it took an afternoon.Shipping it took three weeks.

Anyone with Claude can now build small software. A commission calculator that matches your actual comp plan. A tracker shaped like how your team really runs deals. One user, maybe five, working before lunch.

Then you try to put it somewhere, and every option is wrong. It can stay in the chat where it was born and vanish, or sit on your laptop where nobody else can open it. IT would host it, but a four-person tool waits in line behind the roadmap, because every real cloud was built for Big Software, the kind with a million users and a team paid to keep it alive. That tax is reasonable for a product. It’s absurd for a tool.

So it doesn’t get shipped. It gets a folder on one laptop and a slow death byI’ll get to it this weekend.

Small software should be as easy to share with your colleagues as a Google Doc.
Pete KoomenY Combinator · Request for Startups

Shipping it today

  1. email IT
  2. file a ticket
  3. security review
  4. the roadmap
  5. “next quarter”
  6. back to the spreadsheet

Shipping it on Sploot

Sploot is the cloud that assumes your software has four users and deserves to exist anyway.

Agents can drive it

Claude can use your tool. Not just build it.

Ask Claude to file the ticket or close out the sprint. Every app on Sploot comes with a connector agents can plug into. The tool your agent built in the morning is a tool it can drive by the afternoon.

Under the hood it’s a real MCP (Model Context Protocol) endpoint. If your app already ships one, Sploot mounts it. If it doesn’t (most don’t), Sploot reads the app’s routes and commands and generates one. Any MCP client can connect; nothing proprietary.

It sits behind the same sign-in as the app, so an agent can only do what the person running it can do. No more.

  • Claude Code
  • Claude Desktop
  • your own agent
sprint_tracker/app.pywhat you wrote
@app.get("/sprints")
def list_sprints(project: str) -> list[Sprint]:
    """Every sprint on the board, newest first."""
    return db.sprints(project)

@app.post("/tickets")
def create_ticket(title: str, assignee: User) -> Ticket:
    """File a ticket and assign it to someone."""
    return db.insert(title, assignee)
reconciled
/mcp4 tools, generated
  • list_sprintsGET /sprints

    Every sprint on the board, newest first.

    • project: string
  • create_ticketPOST /tickets

    File a ticket and assign it to someone.

    • title: string
    • assignee: user
  • burndownGET /burndown

    Points remaining per day for one sprint.

    • sprint_id: int
  • close_sprintcli: close-sprint

    Close a sprint and carry unfinished work forward.

    • sprint_id: int
    • carry: bool
$ claude mcp add sprint-tracker https://sprint-tracker.sploot-app.com/mcp

The boring parts, handled

Small software, grown-up infrastructure.

Sign-in, safety, storage, schedules, undo: the three weeks of plumbing between “it works for me” and “my team uses it every day”, already built and switched on.

  • Your company login, already on the door

    Google Workspace, Okta, or a magic link, working before the app first boots. Only your team gets in, and nobody builds a login page.

  • Permissions per person

    Share the link with one colleague or the whole company. Taking access back is one click, not an IT ticket.

  • Safe to run things nobody reviewed

    Every app runs sealed in its own box. It can't see your network or anything you didn't explicitly hand it. That's the answer for when IT asks. (For IT: an isolated microVM, no ambient credentials.)

  • Keys stay secret

    API keys and passwords stay encrypted and out of the logs. Swap one without touching the app.

  • Free while nobody's using it

    An app with no visitors winds down to nothing and wakes on the next click. A tool for four people should cost what four people cost.

  • A disk that remembers

    Your data is still there tomorrow: a real database, set up for you, nothing to install or back up. (Postgres provisioned; SQLite works too, we won't judge.)

  • Runs on a schedule

    every weekday at 9amWritten in plain words. It retries when something hiccups and keeps a log you can actually read.

  • Undo, for software

    See exactly what happened, and go back to the version that worked with one click. No update is ever lost.

  • Engineers: bring your own everything

    Pin a base image, add apt packages, mount an internal CA, point at your VPC. The reconciler's guesses are defaults, not decisions.

Under the hood

Point it at code. Any code.

Nobody fills in a form about what they built. Sploot reads the source the way a competent engineer would on their first day, then keeps going until the thing boots. No Dockerfile, no YAML. (Unless you have one, in which case it's used.)

  1. You hand it something

    A zip. A git URL. A folder your agent finished writing nine seconds ago. A single main.py. Nothing to author, nothing to declare up front.

  2. Sploot reconciles

    It reads the tree and resolves everything it takes to run it:

    • Language, and the version it actually wants
    • Framework, entrypoint, and how the thing starts
    • Package dependencies, and the system libraries under them
    • Services the code expects: a Postgres behind DATABASE_URL, a Redis behind a client import
    • A lockfile, pinned, if there wasn’t one
    • An isolated image, built and booted

    If a build fails, it reads the error and tries again, the way you would.

  3. You get a URL

    Plus auth, secrets, logs, and a disk that survives a restart. If the app didn’t ship an MCP server, Sploot generates one, so your agents can drive it too. Share it like a link.

What it reads

A partial list. Detection is the first thing that happens, and it takes about a second.

pyproject.toml
python 3.12 · uv
go.mod
go 1.23
Gemfile.lock
ruby 3.3 · puma
package.json#engines
node 22 · pnpm
Cargo.toml
rust 1.83
mix.exs
elixir 1.17 · phoenix
import psycopg
postgres 16
deno.json
deno 2.1
*.php + composer.json
php 8.3 · frankenphp
Dockerfile
we’ll just use yours

That's the short version. Every phase, the sandbox, the generated MCP server, and all the escape hatches are written up athow Sploot works.

Scope

Not a big cloud. On purpose.

Every capability a platform adds is a concept somebody has to learn before they can ship. Sploot is the set of things a five-user app actually needs, and nothing else.

How the experience compares between an incumbent cloud and Sploot, across seven common tasks.
What you are doingIncumbent cloudSploot
Time to first URLAn afternoon, if you’ve done it before40 seconds
Config you authorDockerfile, CI workflow, IAM policy, ingress ruleThe zip file
AuthAn identity provider integration projectOn before the app boots
Sharing it with a colleagueAdd them to the org, then the project, then the roleSend them the link
Cost at zero trafficThe load balancer bills anywayZero. It sleeps.
Scaling to ten million usersYes, along with every concept that makes it possible, up frontNo. Go use a big cloud.That’s the trade. It’s why the rest of this column is short.
Concepts to learn firstAbout fortyOne: sploot up

Sploot runs your code, gives it a URL, puts auth in front of it and hands your agents an MCP endpoint. If what you need next is VPC peering, we’re the wrong tool, and we’d rather say so here than in your third week.

Questions

Reasonable objections.

The things people ask in their first five minutes, answered without a roadmap slide. Including the ones from IT.

Something missing? hello@sploot.sh

I'm not an engineer. Is this for me?

Especially you. If Claude built you something that works, Sploot is the difference between a thing trapped in a chat window and a link your team uses every day. You never see a server or a config file. Drop in what was built and send the link.

Claude built me something in a chat. How do I get it here?

Save what it wrote as a zip or a folder, and hand it to Sploot. That's the whole workflow. Or skip the middle step: your agent can run the deploy itself, so “put this on Sploot” works as an instruction.

Do we need IT's approval?

That depends on your company, but Sploot is built so the answer can be yes. Every app is sealed in its own sandbox with no access to anything you didn't grant, and only the people you share with can open the link. Sign-in is your company's own (Google Workspace or Okta). If IT has questions, the answers on this page were written for them.

What languages does it support?

Whatever you've got. Python, Node, Go, Ruby, Rust, PHP, Java, Elixir, Deno, Bun, and the shell script you're not proud of. The reconciler detects the stack instead of asking you to declare it. When it can't, it tells you exactly what it couldn't figure out instead of failing with a stack trace.

What if the reconciler gets it wrong?

Override anything it inferred: runtime version, build command, entrypoint, packages, base image. Its guesses are defaults, not decisions. And if you already have a Dockerfile, it just uses yours.

Is it safe to let a nontechnical colleague run code they didn't write?

That's the hard part of the problem, and it's why every app gets its own sandboxed microVM, with no ambient credentials and no egress you didn't allow. A shared app can only reach what you granted it.

What about the MCP server?

If your app ships one, Sploot mounts it. If it does not, Sploot generates one from your routes and entrypoints, behind the same auth as the app. Your agent gets the same permissions as the person running it, and no more.

Can I use my own domain, VPC, or base image?

Yes, yes, and yes. Small software still has to live inside a real company.

Is this a big cloud?

No, and it isn't trying to become one. If your app needs ten regions and a million users, you've outgrown us, and we'll help you export a real container image and go.

What does it cost?

Not finalized. The shape: free for personal apps, cheap per-app for teams. A sleeping app costs nothing. We'll publish real numbers before we ask anyone for a card.

When can I use it?

Private beta, soon. Leave your email and you'll be in the first group we let in.

private beta · coming soon

Be there when the doors open.

We're letting people in a handful at a time, so we can watch what actually breaks. Tell us what you're building, or what Claude already built you, and we'll make sure it runs on day one.

One email when it's live. Nothing else, ever.

  • first round of invites
  • your use case prioritized
  • no card, no demo call