App SDK
Build apps that factories will let in
An app on Kustlyne runs inside a plant, on that plant’s own data, installed by an operator who has never met you. The SDK gives you the tools; the store’s review and signature give that operator a reason to say yes.
How it works
Four things that are true of every app
They hold whichever version of the toolchain you use.
An app is a container and a manifest
The container is yours — any language, any base image. The manifest is the part the platform reads: what your app needs to read from the name space, what it writes back, what it may reach on the network, and what the operator will be asked at install.
You declare reach up front, not at runtime
An app that has not declared a path cannot read it, and an app that has not declared a host cannot reach it. That is enforced on the machine rather than promised here, and it is the reason a plant engineer will allow a third-party app onto their network at all.
A person reads it before it is signed
Submissions arrive unsigned. Somebody reads the manifest, checks what it asks for against what it says it does, and only then does the store sign it. That is slower than a button, on purpose.
The machine checks the signature itself
Your published app is verified against a key placed on the IPC when the platform was installed. Not against this website and not against our certificate — which means a customer does not have to trust us to install your app safely.
The same four things, as one journey. You cannot apply the signature, and we cannot skip the person who reads the submission first — which is what a plant engineer relies on when they let your app onto their network.
The download
One signed file, and it is not up yet
Python 3.10 or newer is the only requirement. Everything you need to build, test and submit an app, in one file.
The kustlyne-app command line tool
Scaffold an app, validate its manifest against the same rules the store runs, and submit it from your terminal.
The libraries an app is built against
The same code the platform runs, so what passes on your machine is what the device will accept.
The documentation, offline
Markdown and a rendered site you can read with no connection at all — which matters, because the machine you are testing against usually has none.
Worked examples
Whole apps that build, install and run: a dashboard, a connector and a scheduled job, each with its manifest written out and explained.
Two decisions worth knowing
Why it is a file and not a package
Both are deliberate, and both matter on a plant network.
pip install kustlyne-app, say so; it is a decision, not an
oversight.app_key of an app the
platform ships built in. We refuse it at submission; from 1.6.3 the machine refuses it
too, whichever way it arrives, with 'hardware-health' is a
built-in app of this platform -- pick a different app_key. Choose a key that
names your company as well as the app.kustlyne-app submit, or paste the
manifest into the developer portal. Either way it arrives
unsigned and the store signs it after a person has read it. There is no path
that skips that, including for us — which is what the signature is worth to the
customer installing your app.Tell us what you want to build
Which machines, what the app would publish, and who would install it. That is enough for us to say whether the platform fits and to send you the toolchain.