Skip to main content

Studio side panels, first reference

Complete builder guide covers the flow canvas itself - step types, connections, the Architecture view. This page covers the side panels around it: what each one is for, what its fields actually do, and what it writes into app.yaml. This is a first slice, not every panel Studio has - it starts with the ones people ask about most.

Package Files​

Ships real files (docs, sample data, images, a static web bundle) into the app's own install directory alongside app.yaml. Anything uploaded here travels with Install for Test and Publish, exactly like a file added by hand under the app's folder.

Six upload roots, one at a time in the panel: docs/, data/, assets/, web/, templates/, screenshots/. Pick one from the row of buttons at the top, then Upload files or Upload folder. A seventh tab, README.md, is separate - it ships at the package root and is what the Digitorn Hub's Overview tab renders for a published app; reference an uploaded screenshots/*.png from it by path.

Two different ways to let the agent reach an uploaded folder, and they are not the same thing:

  • Mount as workdir - sets runtime.workdir: bundle:<folder>, replacing the agent's entire working directory with this one folder (the Digitorn Docs pattern). Only one folder can be the workdir at a time; the button shows Mounted bundle:<folder> once active, and mounting a different root moves it there instead.
  • Readable by the agent (checkbox, only shown when this root isn't already the workdir) - adds tools.modules.filesystem.config.mounts, a second, always-read-only folder the agent can reach with mount:<root>/... or the mount param on glob/grep, alongside its normal workdir. Several roots can be readable at once this way.

Both require at least one file uploaded under that root first; the panel refuses (with a flash message) rather than mounting an empty folder.

Agent context (collapsible, under the upload buttons) edits the context.sections block the agent sees every turn while a folder is mounted as its workdir - title, priority, and the actual instruction text. Only meaningful for the "Mount as workdir" case; the read-only checkbox doesn't get its own bootstrap text.

Brain / Model​

Sets agents[].brain - provider, model, and how credentials are supplied. Three tabs:

  • Gateway - Digitorn-hosted models, no API key stored in the app.
  • Local - Ollama, LM Studio, or vLLM running on the machine the daemon itself is on. Hidden entirely on a cloud install (nothing there can reach localhost on a visitor's own machine) unless the app was already wired to Local before switching - an already-Local app keeps its tab so it stays editable, but a cloud app can't newly switch into it.
  • BYOK - a credential from the signed-in user's own vault (OpenAI, Anthropic, and the rest).

Changing tabs changes what agents[].brain.provider/backend/config actually contains, not just a label - this is a real change to the compiled app, same as editing the YAML directly.

Show YAML​

Read-only view of the exact app.yaml (and any split agent/hook/prompt files) the canvas currently compiles to, with a real folder tree on the left for every file in the bundle - app.yaml, prompts/, fragments/, package files, everything. Folders start collapsed; a colored dot on a folder means an error or warning exists somewhere underneath it, so a problem in a collapsed folder is never invisible. Whatever is selected in the canvas is highlighted here too, and vice versa - the same app, two views.

This is also the fastest way to confirm what an Ask AI edit actually produced: if a change doesn't show up here after a reload, the canvas doesn't have it either, regardless of what the chat transcript claims.

Background ops (Armed / Executions)​

Shown only for background-mode apps (hidden for conversation/one_shot), as a strip above or below the canvas. Two tabs:

  • Armed - which triggers (cron schedule, webhook, RSS, etc.) are actually live right now, and for a webhook trigger, the real, full URL to send requests to (the inbound_path set in the trigger's own form is only the end of it - the domain part only exists once the app is installed for test or published, and this tab is where it's shown). Meaningless before that: a trigger has nothing to arm until the app has actually been deployed at least once.
  • Executions - recent runs the trigger produced, each openable to watch or replay.

If a cron or webhook trigger doesn't seem to be firing, this tab - not the YAML - is the first place to check: it tells you whether the trigger is armed at all before anything about scheduling logic matters.

Templates​

Lets an app offer ready-made starting points instead of one blank canvas — useful for an app whose whole job is helping someone start a project (a site builder, a document generator). Each entry in templates.yaml is one gallery card: id, name, description, preview_path (the thumbnail), seed_dir (the files copied into a new workspace), a system_prompt, and an optional default. It is not a text-templating language (no Jinja/Handlebars placeholders) — each template is a real, complete starting file set, and the agent fills in specifics by following the system_prompt.

The panel is a file manager scoped to the selected template's folder: Meta (id, name, description, seed_dir, preview_path), Files (a full folder tree — create/rename/move/upload; files/ is the seed, click ⭐ to set any file as the preview), Prompt (the system_prompt), and Preview (the rendered card).

See Templates for the full field-by-field contract, how seeding and previews actually work, default: auto-seeding, and four complete worked examples (built web app, document render, HTML poster, blank).