Skip to content
Talk to our solutions team

Infrastructure library

Atoms for the machine itself. Bound by kis flow, on top of the common library, and reachable from any script.

These are the atoms that make an automated runbook possible: the difference between a flow that describes restarting a service and one that restarts it.

OperationFlow taskScript functions
Service lifecycleservice:
Processesprocess:
Portsport:port.check, .find, .list, .kill
Scheduled jobscron:cron.add, .once, .remove, .list, .show, .exec, .run, .logs, .history, .sync

port.find returns a free port, which is what you want when standing up something that must not collide with a running instance. port.check asks about one you already have in mind.

cron is the fullest of these on the script side. Beyond adding and removing entries it can run one now (exec), read its output (logs), and reconcile a declared set against what is installed (sync) — which is what makes cron entries something a flow can own rather than something someone edits by hand.

OperationFlow taskScript functions
OS usersuser:osuser.check, .create, .delete, .modify, .passwd
Credentialscredential-provider:
OperationFlow taskScript functions
API gatewaykong:
DNS servercoredns:
DNS recordsdns: (common)dns.list, .set, .append, .delete, .lookup
OperationFlow taskScript functions
Scaffoldingscaffold:
Infrastructureinfra:
Product deploymentdeployproduct:

These act on a whole deployment rather than on one resource, so they take more configuration than anything above and are worth reading in full before use. See the atom reference.

Only three of these atoms have a script surface: port, cron and osuser. That is deliberate rather than incomplete.

Infrastructure changes are the ones you most want a record of — which host, which node, what completed, what did not. A flow gives that for free, because position is durable. A script gives you a stack trace.

Where a script genuinely is the right tool for a host operation, shell.execute is available and honest about what it is doing.