Under the hood

How Sploot works

The front page says “upload anything, it just runs.” This page is the mechanism: what the reconciler reads, what it infers, how the sandbox is shaped, and where every escape hatch is. The aim is magically unmagical: everything feels automatic, nothing is unexplainable.

arbitrary code in · running app, sign-in, and MCP endpoint out

The reconciler

What happens when you upload?

Six phases, in order. Each one records what it inferred, and every inference is overridable after the fact.

  1. Intake

    You hand Sploot a snapshot of whatever exists. No manifest, no declarations.

    • Accepted inputs: a zip, a git URL, a local folder, or a single file like main.py.
    • A folder an agent just finished writing is a first-class input, messy trees, missing lockfiles and all.
    • Nothing is required up front: no Dockerfile, no config format to learn.
  2. Detection

    The tree is read for signals the way an engineer skims a repo on day one.

    • Language, runtime version, framework, and entrypoint are inferred from files, lockfiles, engines fields, and imports.
    • Detection is the first pass and takes about a second.
    • When something is genuinely ambiguous, Sploot reports exactly what it could not determine, not a stack trace.
  3. Resolution

    Dependencies are resolved two layers deep: packages, and the system libraries under them.

    • Package dependencies come from your manifest and lockfile; if there is no lockfile, one is generated and pinned.
    • Native requirements are mapped from the packages that imply them: psycopg pulls in libpq, PDF tooling pulls in poppler.
    • Every inference is recorded and overridable: runtime version, build command, entrypoint, packages, base image.
  4. Service inference

    Backing services are provisioned from the evidence in the code.

    • A DATABASE_URL read implies Postgres; a Redis client import implies Redis. Sploot provisions the managed service either way.
    • Connection strings are injected as secrets at boot, never written into the source.
    • SQLite on a persistent volume is equally supported for apps that want zero moving parts.
  5. Build and boot

    An isolated image is built and booted, and failures are read, not surfaced.

    • Each app builds into its own image and boots in its own sandboxed microVM.
    • On a failed build or boot, the reconciler reads the error and retries, the same loop a human would run.
    • It converges on a running app or stops with a precise account of the gap it could not close.
    • Every deploy is immutable and addressable, which is what makes one-click rollback possible.
  6. Wiring

    The running app gets a URL, a login, and an agent endpoint before anyone visits it.

    • Apps are served over TLS on a subdomain of sploot-app.com; custom domains are supported.
    • Auth is wired in front of the app: Google Workspace, Okta, or a magic link. Sploot verifies identity and passes it to your code as a header.
    • An MCP endpoint is mounted at /mcp on the same host: yours if the app ships one, generated if it does not.

Signals

What does detection actually read?

A partial list of signal-to-verdict pairs. The general rule: if a competent engineer could work it out from the tree, the reconciler should too.

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

Agents

How is the MCP server generated?

Every app on Sploot exposes a Model Context Protocol endpoint at /mcp on its own host, so agents can drive the app the way people use the UI.

  • If the app ships its own MCP server, Sploot mounts it behind the app’s auth and does nothing clever.
  • If it does not, the reconciler reads routes, CLI entrypoints, and function signatures, and exposes them as typed, described MCP tools.
  • The endpoint is a real Model Context Protocol server. Any MCP client can connect; nothing proprietary.
  • Tool calls execute with the permissions of the authenticated user driving the agent, so an agent can never do more than its human.

Isolation

What is the security model?

The hard problem Sploot exists to solve: letting people run software nobody reviewed, safely. This is the section to forward to your security team.

  • Every app runs in its own sandboxed microVM, with no shared kernel surface between tenants’ apps.
  • No ambient credentials: an app starts with access to nothing, and reaches only the secrets and services explicitly granted to it.
  • Egress is explicit: an app cannot quietly call out to hosts it was never granted.
  • Sharing is per person: a link works for the colleague, team, or company you granted, and revocation is immediate.
  • Secrets are encrypted at rest, injected at boot, and redacted from logs; rotation never touches the code.
  • Agents inherit the permissions of their authenticated user, so the MCP endpoint adds no new access.

Day 2

What happens after the app is live?

Small software still has a lifecycle. It just shouldn’t need an operator.

  • Apps with no traffic sleep to zero. They cost nothing idle and cold-start on the next request.
  • Persistent volumes survive restarts and redeploys; managed Postgres comes provisioned, not assembled.
  • Cron is written in plain words like “every weekday at 9am”, with retries and a readable log.
  • Queues handle background work without standing up a broker.
  • Structured logs and request traces come built in; rollback to any previous deploy is one click.

Overrides

What if I need control?

The reconciler’s guesses are defaults, not decisions. Everything it infers, you can override; everything you bring, it respects.

  • Ship a Dockerfile and Sploot uses it as-is; the reconciler steps aside.
  • Pin a base image, add apt packages, or mount an internal CA when your environment demands it.
  • Point an app at your VPC, or serve it from your own custom domain.
  • Override any single inference (runtime version, build command, entrypoint) without taking over the rest.
  • Outgrow Sploot and it helps you leave: export a standard container image and go run it on a big cloud.

Scope

What does Sploot deliberately not do?

The honest half of the pitch. Knowing where a tool stops is how you trust where it starts.

  • Sploot is not a big cloud and is not trying to become one: no region matrix, no fleet autoscaling story.
  • An app that needs ten regions and a million users has outgrown Sploot; the export path exists for exactly that day.
  • The target is one concept to learn, sploot up, not forty.

Convinced enough to try it?

Private beta, soon. Tell us what you'd deploy first and we'll aim the reconciler at it.

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