Appearance
The machine model
This page explains what a Dorky machine is, how its boundary works, and what you control at each access tier. The first two tiers are available today. Direct custody is planned.
What a machine is
A Dorky machine is an isolated server. It has its own filesystem, its own processes, and its own address on the open web. It holds state between calls, and it speaks the OpenAI responses format, so any tool that accepts a base URL can talk to it.
You describe a machine in a Dorkyfile and apply the file. dorky apply reconciles the running machine with that declaration. Undeclared services and routes are unavailable.
The door, and keys
Every machine sits behind exactly one public door. The door checks every request against a key, asks the machine's own auth service to allow or deny, and routes the request only if it is allowed.
Deny is the default. A fresh machine answers only its owner. Every other caller presents a key you issued.
A key is a signed token (a JWT), scoped to what it may reach: a route, an agent, a use count, an expiry. The machine verifies a key locally at the door. This is one auth model for every caller: your own backend presents a key, and so do your other machines, your users, and their agents.
Every turn is metered, and the machine records the resolved upstream in its usage ledger. Hosted billing is a separate service and remains in development.
Access and control by tier
Access and custody depend on how the machine was provisioned. The table distinguishes session access, an account-bound managed machine, and planned direct custody.
| Tier | What you control | Status |
|---|---|---|
| Session reach | A scoped key that reaches a machine's turn endpoints. You can talk to the machine; you do not hold its keys. | Built |
| A managed machine | The machine is bound to your account. You control it through its Dorkyfile, reach it, and issue keys for it. Dorky hosts it and holds the fleet-level custody. | Built |
| Ownership | You hold the machine's own keys, can export its declaration and durable data, re-point its address, remove Dorky's access, and keep operating independently. | Planned |
Session reach
The lightest tier. You hold a scoped, short-lived key that reaches only a machine's turn endpoints, often carried in a URL so a tool needs nothing but a base URL. It is safe to place in a URL exactly because the key is confined to those endpoints and nothing more. Session reach lets you talk to a machine. It does not make you the holder of that machine's keys.
A managed machine
When a machine is bound to your account, it is your managed machine. You control it through its Dorkyfile: edit the file, apply it, and the machine converges. You reach it at its address, and you issue keys for it. Dorky hosts the machine and holds the fleet-level custody, and your account is recorded as its beneficial owner.
This relationship is durable: the same machine stays bound to your account, and its declaration stays with you. It is not the strongest tier; this page does not present it as ownership.
Ownership
Planned, not yet built
Full ownership is planned and unavailable today. It means you hold the machine's own keys, can export its declaration and durable data, can re-point its address away from dorky.host, can remove Dorky's access, and can keep operating without Dorky's hosted network.
The current path binds a machine to your account under Dorky's fleet key rather than handing you the keys directly. Which flows will confer direct key custody, and what a recovery-assisted custody would mean, are open product decisions. Nothing on this site should be read as offering key custody before that work lands.
The Dorkyfile is the durable part
Across every tier, the Dorkyfile is the same object. It declares the services a machine runs, the routes it serves, and the upstreams its turns use. dorky rm removes a machine but never the file; a later dorky apply recreates the machine from it.
The declaration is a plain file you can read, edit, and apply. Combined with transferred keys and exported durable data, the Dorkyfile is a required part of the planned portable exit described above.