Available from PyPI Versioned Python nodes Public Objects, no account required Local or remote runs

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. Or start with a verified Object from the Public Hub right now - no account and no publishing setup required.

Explore Public Hub Install SPLime Open the Console

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

Public Hub · No account required

Run useful Python before you create an account.

The SPLime Public Hub is an open catalog of verified, versioned Python Objects. See exactly what an Object accepts and returns, who published it, which runtime it needs, and the immutable release you are about to use. Then call it directly from the SPLime framework.

Browse

Search public Functions, Pipelines, and Library Adapters by purpose, owner, or runtime.

Review

Inspect the verified contract, publisher, exact version, runtime, reputation, and usage signals.

Run

Copy the ready-made example and execute the signed release with your installed SPLime framework.

Explore Public Hub Run this example

Browse, inspect, download, and run public Objects without signing in. Create an account only when you want to publish, manage, or rate an Object.

SPLime Public Hub Ready to use

Verified · v1

@ky / public-examples

compound_growth_projection

Function

Projects a starting value after a fixed annual compound growth rate and a whole number of years.

Inputs: principal · annual_rate · years
Output: projected value
Runtime: venv · Python 3.13

Use the exact public release No login

from spl import SPLClient

result = SPLClient.embedded().call(
    "splime://@ky/public-examples/compound_growth_projection@1",
    kwargs={
        "principal": 1000.0,
        "annual_rate": 0.05,
        "years": 10,
    },
    trust=True,
)

Exact version Signed bundle Verified contract

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.

Copy-paste drift

The same function is duplicated across repos and notebooks. Nobody knows which copy is current, and fixes never propagate.

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.

01 Publish a function

client.register_env()
client.publish(clean_features,
  name="clean_features",
  library="local-sandbox",
  local_only=True)

02 Reuse it anywhere

result = client.call(
  "clean_features",
  kwargs={"customer_id": 42})

03 Send it to a machine

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.

notebook.py

from spl 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 Shared libraries, scoped access, and a team console for your organisation. Record Team interest →

Coming Soon pricing

Start free. Reserve a planned team plan without paying today.

These are the accepted monthly price versions for SPLime's managed control plane. The open framework and local daemon remain useful without a paid account.

Coming Soon

Cloud Free

Free

No payment method

3 billable editors
2 enabled Workers
7 days metadata retention
0 managed AI credits

Open the Console

Team

$79/month

Accepted monthly price version

5 billable editors
5 enabled Workers
30 days metadata retention
25 managed AI credits

Reserve Early Access

Scale

$149/month

Accepted monthly price version

10 billable editors
20 enabled Workers
90 days metadata retention
100 managed AI credits

Reserve Early Access

Founding Team

Founding Team is planned at $49/month for the first 12 monthly billing periods, then $79/month for the accepted Team price version. Limited eligibility; reservation does not guarantee service availability before launch.

Launch notification

Reserve your selected plan

Select the price first, then provide the minimum contact needed for a launch notice.

Selected planned price Team — $79/month Scale — $149/month

Email for this launch notification Record this selected interest and notify me if this offer becomes available. Send occasional SPLime product updates.

Contact use is purpose-limited and revocable. Read the privacy notice.

No payment today. This records qualified interest only. It is not a subscription, activation, or Early Access grant. If delivery is unavailable, the request remains pending verification and no email is sent.

Interest collection is unavailable on this deployment. Pricing remains visible; retry after the live catalog is restored.

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 since 0.1.0.

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.

Available now

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

Want proof before publishing anything? Open the Public Hub and run a verified Object without an account. Then install SPLime from PyPI and make one painful callable from an old project portable - without copying its code into another project.

Explore Public Hub Install SPLime Open the Console