Start
Start
Build, test and continue a native Cloudflare Worker with your existing agent.
For agents: Read the complete native guide, call
context.get, recover existing app state, then useapps.apply,apps.runandoperations.get. Respect the current capability and Account gates. Ordinary authorized work needs no extra Userland Publish click.
Describe what the app should do, who can use it and what it should remember. Your agent builds the Worker, tests the important actions and repairs failures. You can continue from another conversation because Userland retains the source, deployment and operation state.
Connect your agent
Use a compatible MCP connection or the source CLI. The shipping configuration keeps native hosting off; explicitly enabled internal Accounts have a bounded test profile. Managed paid hosting requires separately approved policies and verified payment, and is not activated by installing a client or connecting an assistant. Check current capabilities before assuming hosted builds, browsers or a binding are available. Existing named-assistant connection history is not evidence that every client has passed the native workflow.
With a terminal, sign in through the browser/device flow and inspect context:
userland login
userland context --json
For a chat connection, read userland://guide/native/index through MCP resources, then call context_get. Never paste API keys, app sessions or external credentials into chat.
Build and verify
Use normal Cloudflare Worker files: wrangler.jsonc, an entry module, assets and any migrations. The app owns its authentication and data model. There is no required Userland runtime SDK.
userland apps apply ./my-app --account "$ACCOUNT_ID" --name "My app" \
--environment preview --mode preview --audience private \
--idempotency-key first-preview --json
userland operations get "$OPERATION_ID" --account "$ACCOUNT_ID" --json
Read the returned operation to distinguish queued, waiting, failed and completed work. Use its exact deployment and source identities for hosted tests. Verify the intended user action and saved data; an HTTP200, build or screenshot is not enough.
When public publication is authorized, apply the intended source or exact owned candidate to production and check its returned state. Production resolves its own data and secrets, so checks against different preview bindings do not prove production behavior.
Continue later
userland apps get "$APP_ID" --account "$ACCOUNT_ID" --environment production --json
userland apps get "$APP_ID" --account "$ACCOUNT_ID" --environment production --view source --json
Follow every returned source cursor and verify hashes. Make an atomic patch with current revision preconditions. Reuse a key for an identical retry; use a new key for changed intent.
The native guide, API reference, MCP reference and prompts describe protected inputs, lifecycle effects and recovery. Commercial availability and allowances remain subject to the current Account context; these instructions do not enable paid hosting.