Copy-paste drift
The same function is duplicated across repos and notebooks. Nobody knows which copy is current, and fixes never propagate.
Versioned Python nodes
Local or remote runs
Run history and artifacts
Stop rewriting the same Python in every project.
splime packages a trusted Python function once - versioned and portable - so you can reuse it across projects and run it locally or on another machine, without copying code or redeploying. Publish a function, call it by name, and get the result, logs, and artifacts back.
Publish to a local library
Run with venv or Docker
Inspect result and artifacts
Local library
versioned
clean_features
function / v7 / reusable node
live
risk_report
pipeline / v5 / functions + links
ready
Call
client.call("clean_features")
Input
{"customer_id": 42}
Runs
succeeded
queued
assigned
running
artifacts
laptop
local
gpu-box
online
result = client.call(
"risk_report",
kwargs={"seed": 42},
target_machine="gpu-box",
)
Result
10.5 sec
r2
0.7629
rmse
4.619
report.html
stderr.txt
stdout.txt
The problem
The same useful function lives in five repos - and none of them agree.
Your best Python already exists: the feature cleaner, the scoring function, the report builder, the one-off script that quietly became load-bearing. But it is trapped in a notebook or an old project, so the next team copy-pastes it, edits it, and the versions drift apart. Running it somewhere else means recreating the environment by hand.
Trapped where it was written
Useful code is stuck on one laptop or in one project. Reusing it elsewhere means rebuilding the environment and the imports from memory.
Wrong machine for the job
The function you need to run lives on your laptop, but the data or the GPU lives on a machine you would rather not expose to the internet.
No history, no proof
When it does run, the result, logs, and output files scatter. There is no shared record of what ran, with which inputs, and what it produced.
How it works
Package a function once. Reuse it everywhere - locally or on a private machine.
splime turns a Python function or pipeline into a versioned, portable node you publish to a local library first, then sync into a private server library when you are ready. Any project can call it by name, run it where the data or the hardware lives, and read back the result and artifacts. The central server only coordinates: your private workers execute the code.
Publish trusted Functions and Pipelines
Serialize a function or pipeline into a versioned SPL object - source, inputs, outputs, and dependencies - so it is reproducible and immutable, not a fragile pickle.
Call it from any project
Import it back by name in a notebook, script, or service. The same node is reusable across projects without re-pasting or rewriting code.
Run where it makes sense
Run locally during development, or hand a concrete version to a private worker that has the data, the GPU, or the credentials. The daemon builds an isolated venv or Docker-runtime environment first.
Get a clean result back
Inspect run timelines, results, and artifacts from one console instead of digging through notebooks - with a shared record of every run.
Local or remote
Send the run to the right machine. Continue where you started.
A notebook, service, or console user hands one concrete node version to an allowed private worker, waits for the result, then keeps the surrounding work moving on the origin machine. You never have to open that worker to the public internet.
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 node, and captures artifacts.
Server coordinates only
Jobs, leases, run events, results, and artifact metadata move through splime.
Where this is going
Today: reuse one function. Where we're going: your team's whole trusted codebase.
Your team's trusted code becomes a private, versioned fabric - call any node by name, run it on the machine that has the data or the GPU, with ownership and audit built in. splime is deliberately one thing done well: not an orchestrator, a compute cluster, or a marketplace. Here is where it fits.
| splime | Shared package copy-paste / internal pip |
Orchestrator Airflow, Prefect, Dagster |
Distributed compute Ray, Dask |
Serverless / FaaS Lambda, Modal |
|
|---|---|---|---|---|---|
| Primary job | Reuse a function across projects; run local or on a private worker | Share code as an importable library | Schedule & orchestrate multi-step DAGs | Run Python in parallel across machines | Run a function on demand in vendor cloud |
| Unit of reuse | Versioned node (function/pipeline) + artifacts | Whole package / module | DAG task | Task / actor | Function deployment |
| Call by name from another project - no copy, no redeploy | Yes - new version propagates | Re-pin & reinstall to update | No (DAG-local) | Inside the cluster app | No (per-deploy endpoint) |
| Versioned, portable artifact of the function | Yes (SPL/YAML node, pinned) | Package version (whole package) | No | No | Deploy version (whole function) |
| Local-first: same call runs local or remote | Yes | n/a (local import) | Scheduler / cluster | Cluster-based | Cloud-only |
| Runs on your own private workers (data/GPU/creds stay put) | Yes | n/a | Self-host possible | Self-host possible | Vendor cloud |
| Per-object ownership & scoped access | Yes - per node/library | Repo/registry perms (coarse) | Limited | Limited | IAM on endpoint |
| Scheduling / DAGs | No - pair with an orchestrator | No | Yes (core) | Partial | Event triggers |
| Distributed-scale compute | No - not its job | No | Partial | Yes (core) | Autoscale |
| Infra to operate | One local daemon (+ optional server) | None (pip) | Scheduler + workers + DB | A cluster | Managed (vendor) |
| Language scope | Python-first | Python | Mostly Python | Python | Multi-language |
From splime's point of view. Need scheduled orchestration, massive parallelism, or non-Python? An orchestrator, Ray, or FaaS is the right tool - splime is narrow by design.
The splime bet
The smallest unit worth versioning isn't a service or a DAG - it's a function. We're building the registry and runtime for exactly that.
First run
From a function to a reusable node in three steps.
Start with one trusted Python function. splime makes the path obvious: register an environment, publish the node into the local daemon library, then call it - locally first, and on a private worker when you need a different machine.
client.register_env()
client.publish(clean_features,
name="clean_features",
library="local-sandbox",
local_only=True)result = client.call(
"clean_features",
kwargs={"customer_id": 42})client.call("clean_features",
target_machine="gpu-box")
# inspect Runs for logs/artifacts
What you get back
The return value, stdout, stderr, and any output files - plus a versioned record in the library and a row in Runs you can re-open later.
Developer experience
It starts from the Python your team already trusts.
The user API stays small: register an environment, publish the function you already wrote into the local daemon registry, then call it by name. Add a target machine only when you want the run to happen somewhere else.
from spl.client import SPLClient
client = SPLClient()
# Publish a function you already trust as a versioned node
client.register_env()
client.publish(
clean_features,
name="clean_features",
library="local-sandbox",
create=True,
library_display_name="Local Sandbox",
local_only=True,
)
# Reuse it from any project - run locally...
result = client.call("clean_features", kwargs={"customer_id": 42})
client.objects(scope="local", compact=True)
# ...or send the run to a private machine that has the data
result = client.call(
"clean_features",
kwargs={"customer_id": 42},
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 - shared, not copy-pasted.
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.
splime for Teams - private preview
Shared libraries, scoped access, and a team console for your organisation. Request early access →
Security model
Not random code execution. A private registry for trusted code.
splime runs code you publish on purpose, on machines you control. It is built around explicit ownership, scoped access, private worker boundaries, and an auditable run history. The server coordinates; your private workers execute the code.
Private daemon agents
Workers connect outbound to the control plane and keep code execution on your machines.
Safe default Docker daemon
The container service runs non-root and does not mount docker.sock unless you opt into Docker-runtime nodes.
Scoped tokens and grants
Team grants, delegated machine access, and external execution tokens map to backend permissions.
Narrow run write boundaries
Only the requester can cancel or retry a run; only the requester or target machine can upload artifacts.
Audited operations
Token, grant, settings, run, and artifact-upload events are recorded.
What's next
Where splime is heading.
Direction, not deadlines - shaped by the architecture already in place. We build in the open: on PyPI, Apache-2.0 licensed, shipping steadily from 0.1.0 to 0.1.2 and forward.
Planned
More execution backends & isolation
Beyond venv and Docker workers - more runtimes and stronger isolation.
Planned
Shareable adapters
Author an adapter once, then reuse and share it across pipelines and your team.
Planned
Richer library governance
Finer references, grants, and provenance for sharing across teams.
In progress
Team console & observability
Deeper run history, activity, and machine views in the console.
Planned
Broader environments
Wider OS and Python coverage with reproducible builds.
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. splime is an early private beta - see exactly what works today on the status page.