Private registry Managed worker fleet Remote runs

Turn scattered Python into a private execution network.

splime packages trusted functions and pipelines as versioned SPL objects, syncs them through a central registry, and runs them on private machines without exposing worker agents to the internet.

Join private beta See how runs flow
Versioned YAML bundles Scoped machine tokens Results, logs, artifacts
SPL control console ready now
Home ready
daemon paired machine-y / online / scoped tokens
live
risk_report pipeline / v5 / typed inputs
ready
Next action Launch run Input {"seed": 42}
Runs succeeded

queued

assigned

running

artifacts

machine-x online
machine-y online 
client.call(
    "demo_pipeline",
    kwargs={"seed": 42},
    output="report",
    target_machine="machine-y",
)
Result 10.5 sec
r2 0.7629
rmse 4.619
report.html stderr.txt stdout.txt

The shift

Your best Python should not be trapped in old repos and notebooks.

splime makes internal code discoverable and executable without forcing teams into a heavy scheduler, cloud lock-in, or another copy-paste library.

01

Publish real functions

Serialize Python functions or SPL pipelines into immutable versions with inputs, outputs, dependency manifests, and YAML bundles.

02

Run where the data lives

Daemon agents connect outbound to the server, claim jobs, build isolated environments, and execute code on machines you control.

03

Operate from one console

See machines, object versions, run status, timelines, logs, results, and artifacts in one place instead of digging through notebooks.

04

Keep governance close

Use scoped tokens, delegated machine access, immutable versions, and private infrastructure as first-class product primitives.

Distributed execution

Send the right step to the right machine. Continue where you started.

A notebook, service, or daemon agent can hand a concrete SPL object to a private worker, wait for the remote result, then keep the surrounding computation moving on the origin machine.

Origin keeps context Inputs, follow-up code, and the final workflow stay with the caller.
Worker owns execution The target daemon builds the environment, runs the object, and captures artifacts.
Server coordinates only Jobs, leases, run events, result payloads, and artifact metadata move through splime.
Distributed SPL execution map A pipeline sends one SPL run through the splime server to a private worker, then receives the result and continues the workflow. Origin machine Notebook / client 01 Load inputs customer_id, files, context 02 Prepare payload kwargs + output selector 03 Remote SPL run target: secure-worker-01 06 Continue workflow merge result, render report PAYLOAD RESULT + FILES splime server registry, queue, leases run events, artifacts queued assigned Worker fleet Private machines secure-worker-01 CLAIMED 04 Build isolated env 05 Execute object gpu-lab-02 available ci-runner-03 available

Architecture

A central server coordinates. Your workers do the execution.

The global server stores users, tokens, machines, objects, remote runs, events, and artifacts. Daemon agents stay private: they heartbeat, sync, claim jobs, and report results.

1 Framework

Serialize a function or pipeline into SPL/YAML.

2 Daemon agent

Stores versions, builds venvs, and syncs outbound.

3 Server

Coordinates registry, machines, jobs, results.

4 Worker machine

Claims the remote run and sends artifacts back.

Pilot quickstart

Launch a private execution pilot with one registered worker.

Connect to the hosted control plane, register a worker machine, publish one versioned object, then launch a remote run from the console.

01 Create a workspace 
Open console
Choose team and access policy
02 Register a worker 
Issue scoped credentials
Pair daemon machine
03 Launch a run 
Publish object version
Target an online machine
Expected first result Home shows readiness, Daemons shows the registered machine, Runs shows result and artifacts.

Developer experience

It starts from the Python your team already trusts.

The user API stays small: authenticate, publish an object, then call it on the target worker machine.

notebook.py 
from spl.client import SPLClient

client = SPLClient(
    user_token="spl-...",
    machine_token="spl-...",
    machine_id="secure-worker-01",
    display_name="Secure worker 01",
)

client.register_env("spl_core")
client.publish(my_pipeline, name="risk_report", env="spl_core")

result = client.call(
    "risk_report",
    kwargs={"customer_id": 42},
    output="report",
    target_machine="secure-worker-01",
)

print(result.value)

Who feels it first

Built for teams whose useful Python already exists.

Data and ML teams

Turn preprocessing, scoring, validation, reports, and model utilities into reusable execution nodes with reproducible environments.

Platform teams

Give developers self-service access to trusted internal Python capabilities without rebuilding orchestration for every project.

Automation teams

Reuse document processing, scraping, analytics, and operational scripts across clients, repos, and workers safely.

Security model

Not random code execution. A private control plane for trusted code.

splime is designed around explicit ownership, scoped access, private worker boundaries, and auditable run history. The server orchestrates; your workers execute.

Outbound-only daemon agents No need to expose worker machines to the public internet.
Scoped tokens and delegated access User, machine, and sub-token scopes map to real backend permissions.
Immutable object versions Every run is tied to a concrete SPL object version and environment.
Results and artifacts returned Keep outputs, logs, HTML reports, and binary files attached to the run.

Private beta

Bring one painful internal function. Make it portable.

The fastest way to understand splime is to publish a real function from an old project, run it on a different machine, and get a clean result back without copying code.

Request access Talk architecture