Running and Turning On

There are two things you can do with a machine that works, and they are not the same thing at two different sizes. Running exercises the machine. Turning it on changes how it exists.

The rest of this page is that sentence, unpacked.

Running

A run is one execution. You start it, the steps execute in order, the machine produces its output, and then the run is over. It leaves a receipt in the behavioral ledger: which steps ran, what each one produced, which governance decisions were made, what it cost. Nothing stays standing afterwards, so there is nothing to turn off and nothing to clean up.

mashin run greeting --input '{"name": "Ada"}'

What runs is the machine as it reads right now, drafts included. That is exactly what you want while you are still working on it: edit, run, read the receipt, edit again.

Turning a machine on

A machine that is On stands ready at a place until you turn it off. Turning it on runs nothing by itself. Zero runs happen because you turned it on.

What it does give you is three things.

It lives somewhere. The version you promoted is pinned to a named computer and stays there after you close the app. It is the same document you were running a minute ago, now with an address. Nothing gets rewritten on the way to production, because there is no separate production build.

It can be reached. The surfaces the machine declared in expresses come on: its REST path, its webhook, its WebSocket connection, its page. Schedules declared in behaves start firing. Authorized callers, including other machines, can invoke it by name.

It is still governed by you. A machine that is On does its work when you are not watching, which is precisely when what it is allowed to do matters most. The ensures section is your presence while you are away. Permissions are enforced, budgets are counted, approval gates route to you, and every run it serves writes its own receipt.

Side by side

	Run it	Turn it on
What executes	One execution	Nothing, by itself
Which version	The machine as it reads now	The version you promoted, pinned
Who starts runs	You	Schedules, callers, incoming requests
When it ends	When the run ends	When you turn it off
What comes back	One receipt	A receipt for every run it serves

The real difference is not location, and it is not whether you are watching. You can watch a run happen on a computer in another country, and you can turn a machine on right here on your laptop and forget about it. The difference is between an event and a state.

Place belongs to both verbs

Where something happens is a separate question from which verb you used. Both verbs take a place, and for both the default is here: the computer you are currently pointed at.

Running on another computer is still running. It is one execution, under that computer’s governance and identity, with the receipt coming back to you. Today you choose the place by pointing at the computer first:

mashin computer connect production
mashin run greeting --input '{"name": "Ada"}'

Or per command, without switching:

MASHIN_COMPUTER_ID=production mashin run greeting --input '{"name": "Ada"}'

Wanting a machine to run somewhere other than your laptop is not, on its own, a reason to turn it on.

When turning it on is not what you want

Turning a machine on is the right move when something other than you will start the runs. If nothing will, the machine is On with nothing to be on for. It is resident, reachable and governed, and it runs zero times, forever.

This corner is worth naming because it looks like success. Everything reports fine. The machine shows up as On. It simply never does anything, and nothing tells you so.

Before you turn a machine on, ask what will start a run:

• A schedule. Something in behaves > schedules that fires on a cron or an interval.
• A surface someone will call. A path in expresses that a person, a browser, or an external service actually hits.
• A caller. Another machine that asks this one by name, or a client invoking it as a tool.

Every machine is reachable over MCP without declaring anything, so a machine that is On can always be asked. The question is not whether it can be asked. It is whether anyone will ask.

If the answer to all three is nothing, and what you actually wanted was for this machine to execute once somewhere that is not your laptop, then run it there. That is the verb for that job. A schedule set to fire a single time is a standing thing wearing a one-shot costume, and it leaves something behind that you have to remember to take down.

What makes a machine worth leaving on

Two declarations turn a machine from something you run into something worth leaving in place. A schedule gives it its own clock:

behaves
  schedules
    schedule check_feeds
      cron: "*/30 * * * *"

A surface gives the outside world a way in:

expresses
  api
    path: "/api/triage"
    method: "POST"
    auth: oauth
    scopes: "machines:run"

A machine with either one has a reason to exist at an address. Turn it on, and the reason starts working. Everything it does from then on is recorded exactly as your attended runs were, because the runs of a machine that is On are ordinary runs. What changed is who starts them and who is in the room.

The same idea in the CLI

The command line calls this deploying, and the platform reference uses that word too:

mashin deploy greeting.mashin

Same act, developer vocabulary. See Deployment for targets, credentials, and the promotion flow.

Next steps

• Surfaces - Declaring how a machine is reachable
• Governance - What holds while you are away
• Deployment - Targets, the deployment flow, and production credentials
• Computers - The thing a machine takes up residence in