Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions website/content/docs/cli.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -193,19 +193,19 @@ Node input/output schemas are shown when defined.

## light doctor

Check environment health.
Check the environment and light-run connectivity.

```bash
light doctor
```

**Checks:**
- Node.js version (>= 18)
- Docker installation
- Docker daemon status
- gVisor (runsc) availability
- GPU support (nvidia-smi)
- Docker GPU plugin
- Node.js version (prints `process.version`)
- `LIGHT_RUN_URL` - decides the mode:
- **unset (all-in-one):** confirms the `light-run` binary is installed, since `light serve`/`light run` will spawn it automatically. Fails if the binary is missing.
- **set (explicit runner):** pings the runner's `/health` and fails if it is unreachable.

Container-level concerns (Docker daemon, gVisor, GPU) live on the light-run host, not here - `doctor` only checks that light-process can reach a runner.

---

Expand Down
22 changes: 22 additions & 0 deletions website/content/docs/getting-started.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@
title: "Getting Started"
---

The mental model in one breath: a **node** is a Docker container that reads JSON on stdin and writes JSON out, a **link** is an arrow that passes one node's output to the next node's input, and a **workflow** is the graph (`workflow.json`) wiring them together. That is the whole model - everything below is just creating nodes, linking them, and running the graph. The full reference is in [Workflows](workflows).

## Requirements

- **Node.js** >= 20 ([download](https://nodejs.org))
Expand Down Expand Up @@ -99,6 +101,26 @@ light run example --input '{"name": "Alice"}'
-> {"hello":"world","input":{"name":"Alice"}}
```

## Run from code (`main.js`)

`light init` also dropped a `main.js`. It does exactly what `light run example` does, but from JavaScript via the SDK instead of the CLI - this is how you embed light-process inside a real app:

```js
import { LightRunClient, loadWorkflowFromFolder } from 'light-process';

const wf = loadWorkflowFromFolder('./example');
const result = await wf.execute({}, { runner: new LightRunClient() });

console.log(result.success ? 'Success' : 'Failed');
console.log(JSON.stringify(result.results, null, 2));
```

```bash
node main.js
```

The CLI is for iterating; the SDK is for integrating (build graphs in code, hook `onNodeStart`/`onLog` callbacks, expose workflows over HTTP). See the [SDK Guide](sdk) for the full surface.

## Validate a workflow

```bash
Expand Down
4 changes: 4 additions & 0 deletions website/content/docs/workflows.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -139,6 +139,10 @@ Without `maxIterations`, adding a cycle throws `LinkValidationError`.

## Run-scoped networks (`networkDefs`)

<Callout type="info">
Everything from here down (`networkDefs`, services/sidecars) is advanced. Skip it for your first workflows - nodes and links are enough to build real graphs. Come back when you need a node to reach a database, a proxy, or a provider behind a secret.
</Callout>

A bare name in `networks` must already exist on the light-run host, or the run fails. `networkDefs` lets a workflow declare networks it wants **created for the duration of a single run and destroyed afterwards**, so you never manage Docker networks by hand.

```json
Expand Down
Loading