Integrated MVP stack Function and Pipeline registry Private worker daemons

SPLime: a private Python control plane for trusted code.

SPLime now connects the full project surface for trusted Functions and Pipelines: a Python framework, local daemon agents, a backend control plane, an operator console, public landing page, architecture docs, API contracts, and launch verification around private remote execution.

Join private beta See project state
Versioned object signatures Scoped tokens, grants, and settings Console, contracts, and production sanity gates
SPL control console ready now
Home ready
daemon paired machine-y / online / scoped tokens
live
risk_report pipeline / v5 / functions + links
ready
Next action Launch run Input {"seed": 42}
Runs succeeded

queued

assigned

running

artifacts

machine-x online
machine-y online 
client.call(
    "risk_report",
    owner="alice",
    library="risk",
    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

Current project state

One integrated MVP stack, verified across code, console, contracts, and deployment paths.

The current SPL v2 workspace is no longer only a prototype sketch. Framework, daemon, backend server, frontend console, landing page, and architecture docs now describe the same control-plane model and pass their local launch checks.

Core 19 framework tests
Daemon 18 agent tests
Server 43 API tests
Console 31 UI checks
Framework

spl-core

Python entities, SPLClient, owner/library call shapes, external-token facade, and Pipeline graph rules.

Local execution

spl-daemon

Private worker agent, object registry, environment cache, local runs, diagnostics, and outbound sync.

Control plane

spl-server

Users, teams, libraries, machines, tokens, grants, settings, run queues, events, and artifacts.

Operator UX

spl-frontend

Modular console with onboarding, Activity, route filters, forms, mobile polish, and support bundle export.

Public surface

spl-landing

Static product page, deployment routes, nginx assumptions, and architecture-language guardrails.

Source of truth

spl-docs

Architecture maps, security review, API contracts, OpenAPI files, examples, and final release checklist.

What ships today

Your best Python can move from old repos and notebooks into an operated private network.

SPLime makes internal code discoverable, callable, governed, observable, and supportable without turning the central server into a public code execution runtime.

01

Publish Functions and Pipelines

Persist stable object kinds, signatures, Pipeline nodes, Function steps, and Links as versioned SPL objects.

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 teams, libraries, machines, object decomposition, run timelines, results, and artifacts in one place instead of digging through notebooks.

04

Keep governance close

Use team grants, delegated machine access, external execution tokens, immutable versions, and admin settings as first-class product primitives.

Distributed execution

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

A notebook, service, external token, or console user can hand a concrete SPL object version to an allowed private worker, wait for the 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 / SDK / console 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 server stores users, teams, grants, tokens, machines, libraries, object versions, remote runs, events, artifacts, and operational settings. Daemon agents stay private; the console and docs make the same contracts visible to operators.

1 Framework

Serialize a Function or Pipeline into SPL/YAML.

2 Daemon agent

Mirrors local objects, builds environments, and syncs outbound.

3 Server

Coordinates registry, grants, tokens, jobs, events, and artifacts.

4 Worker machine

Claims the remote run and sends artifacts back.

5 Console and docs

Expose Activity, access, tokens, health, support bundles, and API contracts.

Pilot quickstart

Launch a private execution pilot with one registered worker.

Connect to the control plane, register a worker machine, publish one versioned object, then launch a remote run from the console or SDK. The MVP path is explicit: pair daemon, publish object, launch run, inspect result.

01 Open the console 
Open console
Check workspace status
02 Pair a daemon 
Issue scoped credentials
Pair daemon machine
03 Publish and run 
Publish Function/Pipeline
Target an allowed machine
Expected first result Home shows readiness, Libraries show object structure, Runs show timeline, 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 by owner, library, and target 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",
    owner="alice",
    library="risk",
    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 Functions and Pipelines with reproducible environments.

Platform teams

Give developers self-service access to trusted libraries and launch-only machines without rebuilding orchestration for every project.

Automation teams

Reuse document processing, analytics, and operational scripts across clients, repos, and workers with narrow external execution tokens when a service needs access.

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 trusted code.

Private daemon agents Workers connect to the control plane and keep code execution on your machines.
Scoped tokens and grants User, machine, machine-subtoken, and external-token scopes map to backend permissions.
Narrow run write boundaries Only the requester can cancel or retry; only the requester or target machine can upload artifacts.
Audited operations Token, grant, settings, run, artifact upload, and cleanup events are recorded.

Private beta

Bring one painful internal Function or Pipeline. Make it portable.

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

Request access Talk architecture