Serialize functions and pipelines
The framework turns a Python function or pipeline into a versioned SPL object - source, inputs, outputs, and dependencies - as readable YAML, not an opaque pickle.
Project status
An honest snapshot of splime: an early private beta you can read end to end.
splime is a private Python control plane for reusing trusted functions as versioned, portable nodes. This page exists so you can judge it for yourself: what genuinely works today, what is still rough, and what is planned next. We do not claim users, traction, or benchmarks we cannot show.
Stage
Beta
controlled pilot
Packages
0.1.0
framework + daemon
Python
3.13+
supported runtime
Scope
Python
Python-first, single language
What works today
The core loop runs: publish a node, run it, get the result back.
These are the capabilities that exist in the current workspace and pass their local checks. They are enough to prove one private run end to end.
Local daemon publish and run
A local daemon stores objects and version history, builds and caches isolated venv environments, and runs functions in a separate process with captured logs and artifacts.
Remote runs through the server
Connect the daemon to the backend server to queue a run on an allowed private worker, lease it, stream status, and pull back results and artifacts.
Operator console
The frontend console covers Home, Library, Runs, Access, Tokens, Activity, and admin settings, with onboarding, empty states, and a redacted support bundle export.
Access, teams, and tokens
Users, teams, libraries, machines, grants, machine subtokens, and external execution tokens exist as first-class primitives with audited events.
Install path and docs
Versioned install scripts for macOS, Linux, and Windows, a cold-start notebook, API contracts, and developer documentation are in place.
The stack
One integrated MVP stack across framework, daemon, server, and console.
Framework, daemon, backend server, frontend console, landing page, and documentation describe the same control-plane model.
spl-core
Python entities, SPLClient, owner/library call shapes, external-token facade, and Pipeline graph rules.
spl-daemon
Private worker agent, object registry, environment cache, local runs, diagnostics, and outbound sync.
spl-server
Users, teams, libraries, machines, tokens, grants, settings, run queues, events, and artifacts.
spl-frontend
Modular console with onboarding, Activity, route filters, forms, and support bundle export.
spl-landing
Static product page, status page, deployment routes, and architecture-language guardrails.
docs
Architecture maps, security notes, API contracts, examples, and the release checklist.
Known limitations
What is still rough - so you are not surprised later.
These are real constraints in the current build. None of them block the core loop, but they shape what splime can and cannot do today.
Top-level functions first
Serialization currently captures functions defined at the top level of your notebook or script. Packaging functions imported straight from installed modules is not automatic yet - it is the next big framework step.
Single output per node
A node returns one output today. Multi-output pipelines need an explicit selector, and full multi-output support is on the roadmap.
Remote node round-trip
Remote node signatures resolve live through the daemon. Round-tripping remote node ports through exported YAML is not complete, so re-importing a remote reference can lose its port definitions.
Console polish and mobile
The console is a dependency-free MVP. The navigation is dense, the mobile layout is a responsive fallback rather than a designed mobile view, and development login accounts are still visible and should move behind an environment flag before public launch.
Trust boundary is explicit
splime runs code you publish on purpose. Importing an SPL object reconstructs and executes its source, so objects must come from a trusted source - this is a deliberate design choice, not arbitrary code execution.
Not yet production-deployed
Final public launch still depends on production sanity checks for deployed /app/, /app/config.js, and /api/health, plus operational settings hardening.
Verification
What we can actually show: local tests and checks.
These are automated test counts from the latest local run, plus the console and landing check suites. They are evidence of internal discipline, not a guarantee of production readiness.
Framework
27
spl-core tests
Daemon
27
spl-daemon tests
Server
53
spl-server tests
Console
10
check suites
Also checked
API contracts, render smoke and responsive-visual checks for the frontend console, static landing link/asset/language guardrails, support bundle redaction, and nginx deployment assumptions for /, /app/, and /api/.
Roadmap
What comes next, in priority order.
Direction, not dated promises. The theme is the same as the product: make reuse and one clean remote run feel obvious before adding surface area.
Sharpen the reuse story
Make the first run obvious and guided: publish a function, reuse it in a second project, then run it remotely - as one path in the console, not scattered steps.
Reuse beyond the notebook
Package functions that live in installed modules and packages, not only top-level notebook or script definitions - the biggest unlock for real codebases.
Multi-output and remote round-trip
First-class multi-output nodes and complete remote node port round-tripping through exported SPL/YAML.
Console and mobile polish
Simplify navigation around the first successful run, design the mobile view properly, and move development login accounts behind an environment flag.
Production hardening
Close production sanity checks, harden operational settings, and finish the deployment story for /app/ and /api/.
Public launch
Soft launch to trusted developers first, then a Show HN, then Python and data engineering communities, and Product Hunt only after real proof.
Private beta
Want to shape what comes next?
The most useful feedback comes from publishing one real function from an old project and telling us where it hurts. That is what moves this roadmap.