What Waiso is
Waiso runs your code for you. You write a script in Python, TypeScript, JavaScript, C or C++ in the browser, or chain steps into a visual flow, and Waiso runs it when you press Run, on a schedule, when another system calls a URL or when something happens elsewhere. Every run is kept, with its inputs, output and logs. This track builds one small automation — a daily-report — from the first line of code to a schedule and an API.
- Name the four pieces: project, script or flow, trigger, run
- Know where your code actually runs, and what it can and cannot reach
- See what the next seven lessons build, step by step
Four pieces
Everything in Waiso fits in one sentence: a project holds scripts and flows; triggers start them; each start becomes a run that a worker executes and the project records.
| Piece | What it is | Where you see it |
|---|---|---|
| Project | A folder for code, connections, variables and history. Access is given per project. | Projects page |
| Script | One file with a main entry point, in one of five languages. | Code, then the editor |
| Flow | Steps on a canvas, run top to bottom, each step’s output feeding the next. | Code, then the canvas |
| Trigger | What starts a run: you, a schedule, an API call, an e-mail, a database change, an MQTT message. | The editor’s Triggers tab |
| Run | One execution: inputs, output, logs, duration and who or what started it. | Runs page and Run history |
Where your code runs
Your code never runs in the browser. Pressing Run queues a job; a worker — a server process that speaks all five languages — claims it, starts your main in a sandbox, and sends back what it returned and what it printed. The same worker runs SQL steps against your connections.
What the sandbox allows
- No network. A script cannot call the internet or your private hosts. It reaches data through what the platform hands it: its inputs, the project’s integrations (databases, S3) through the SDK, variables, and state.
- Packages are installed for you. Import a Python or npm package and the worker installs it before the run; later runs reuse it. See Dependencies.
- Calls to the outside are built-in steps. When a flow must call an API, the HTTP Request step does it from the platform, not from your code.
Look around first
- Open the projects page
After signing in you land on Projects. Open any project: its left column lists Runs, Code, AI Scraper, Schedules, Alerts, Variables, Integrations, API, Git and Workers.
- Picture a run
In the editor a run ends in the panel under the code: Output holds what
mainreturned, Logs what it printed. That is the loop you will repeat in every lesson. - Know who runs it
The Workers page shows the workers online, the languages they run and how busy they are. You need nothing there to begin on the cloud.
What else is in the box
This track uses scripts, a flow, a schedule and an API endpoint. The rest of the product is built on the same pieces:
- Five languages with typed inputs, an editor with completions and an AI assistant that proposes changes you review.
- Flows with conditions, loops, parallel branches, approvals, SQL, HTTP, AI and e-mail steps.
- Triggers: schedules, API endpoints and events (an e-mail arrives, a Postgres row changes, an MQTT message comes in), plus alerts when a run fails.
- The AI Scraper: describe a site in a sentence and get a robot that reads it with no AI at run time.
- Integrations (PostgreSQL, MySQL, S3, e-mail, AI providers), MCP so agents can build and run things for you, and self-hosting on your own servers.
What you will build
The next seven lessons follow one example. It needs no database, no API key and no package: a short list of scores, summarised.
- Projects — create the
daily-reportproject. - Quick start — write the
daily-reportscript and run it. - Output and logs — read what it returned and find the run again.
- Publish — freeze the tested version that triggers run.
- Your first flow, a schedule and an API endpoint.