App Studio FAQ

Beta: the questions plant teams and IT administrators ask before and after they put App Studio apps on the line, each with a full answer.

Setup questions

DNS, proxies, Safari, Enterprise

Safety questions

What an app can reach, who publishes

Life questions

Upgrades, people leaving, partners

Beta

App Studio is in release 3.0 as Beta: a paid add-on that no edition includes by default. A licence or a trial licence that includes the app_studio feature switches it on. The module is on by default, so the licence decides. Names and steps may change while it is in Beta.

For a walk through the whole life of one app, read App Studio, start to finish first. The answers below link to the Operator guide and the Builder guide for the detail.

Setting it up

Do I need a DNS record, a second host name or a certificate?

No. Apps are served from the same address people already use for MaestroHub, under the path /_apps/. There is no second host name, no DNS record, no extra certificate and no App Studio setting for the address. If MaestroHub runs on HTTPS, apps run on HTTPS with the same certificate; if it runs on plain HTTP on the plant network, so do the apps.

The settings sandboxDomain and sandboxOrigin do nothing: MaestroHub logs one line for each one a configuration file or environment variable sets, telling you to delete it, and the Helm charts refuse values that set them, with the fix. See Removed settings.

Does it work on a bare IP address, over plain HTTP, behind a reverse proxy or under a sub-path?

Yes to all four, with two limits for Safari.

• Bare IP and plain HTTP: apps run on http://192.0.2.10:8080 the same as on https://maestrohub.plant.example. People can even mix the two; each browser uses the address it opened.
• Behind a reverse proxy (nginx, Apache, Traefik, Caddy, IIS ARR, a Kubernetes Ingress): a proxy that forwards MaestroHub as a whole needs no App Studio rule. It must pass /_apps/ and /appstudio-runtime/ like any other path, pass the WebSocket upgrade on /api/v1/ws/connect, leave the Content-Security-Policy header on /_apps/ as MaestroHub sent it, and not strip the Referer header. A single sign-on proxy in front of MaestroHub must let the app paths through, because app requests carry the app's own token, not a cookie. The checklist is in Behind a reverse proxy.
• Under a sub-path, such as /maestrohub/ on a Siemens Industrial Edge device: apps are served under /maestrohub/_apps/, from http.basePath.
• Safari and iPad start an app only when the page's security policy can name the address in use. That rules out an IPv6 literal address, a host name with an underscore (plant_hmi01) and a host name ending in a dot. On such an address Chrome, Edge and Firefox run apps normally; Safari shows that the app did not answer. Safari also needs the proxy to pass Referer. See Address limits for Safari and iPad.

MaestroHub checks this for you: the platform page runs a small self-test once per page load and reports what it finds (for example, a proxy that removed the security header) on the App Studio Operations view and in GET /health.

Does it run on Kubernetes (Enterprise)?

Yes. On the Enterprise Helm chart App Studio is its own pod, on by default, served under /_apps on the same ingress.host as the platform. It runs as a single replica because each app's git store is one volume, so an upgrade of that pod has a few seconds without app serving. Back up its database and its volume together. See Enterprise.

Safety

Can an app harm MaestroHub, or read data it should not?

An app can do only what both of these allow, at the same time:

1. Its manifest, which declares the scopes it needs and every action that writes. A person who may publish the app sees that list in the release review before it goes live.
2. The permissions of the person looking at it. The app works with a short-lived token (5 minutes, renewed while it runs) that is the intersection of the manifest and the viewer's own permissions. If Olga may not read a topic, an app Olga opens cannot read it either. A permission taken away from her reaches the app at the next renewal.

On top of that, the token opens only the API routes the App Studio SDK uses; anything else answers 403 APP_ENDPOINT_NOT_ALLOWED whatever the manifest says.

The app also cannot reach into MaestroHub in the browser. Each app runs in an isolated frame that the browser treats as an anonymous origin, enforced twice (an attribute on the frame and a header on every app page; either alone is enough). It cannot read the MaestroHub sign-in, cannot touch the MaestroHub page and has no browser storage of its own, so it cannot read another app's data. Before any app code runs, MaestroHub's start-up code checks that the app is framed by MaestroHub and isolated, and refuses to start it otherwise. Every failure means "the app does not start", never "the app runs with MaestroHub's rights".

The exception is deliberate and visible: an action marked to act as the app itself can do something the viewer could not, for example let an operator change a line speed through a button. Such an action needs Advanced Access Control, can only do what the person who approved the release holds, is listed in the release review and on the App Identities page, and every write it makes is audited with the app as the actor and the person it acted for. See What apps can and cannot do.

Can an app send our data to the internet?

Not quietly. An app page may load scripts, call APIs, open the live-data socket and fetch images only from MaestroHub's own address; the browser blocks everything else. Apps are built from a fixed set of libraries inside MaestroHub, with nothing downloaded.

What the browser cannot stop, and MaestroHub documents rather than hides:

• An app can navigate its own frame to an outside address with data in the URL. That ends the app's session; MaestroHub restarts it with a growing pause, counts each departure, and flags the app on its Operations page from the third one, so its owner and administrators can read its code.
• An app can open a WebRTC connection, which browsers do not police with the page's security policy.

If your network lets operator screens reach the internet, review apps that MaestroHub flags or that use WebRTC. The full list is in What isolation does not cover.

Who can publish an app? Does it need a second approver?

Publishing is a request that a person signed in to MaestroHub approves. Anyone who holds app:publish on the app may approve: its owner, a holder of the Apps.Editor or Apps.Admin role, the Persona.DataEngineer role, or a workspace administrator. The person who asked may approve their own request; there is no second-approver rule. Before approving, the review shows who asked and how, the permissions viewers would start or stop granting, and the files that changed against the live version.

What is not allowed: a token, an AI client or Maestro approving. They can ask for a release, which then waits for a person. The same rule covers every way a version becomes live (a release, activating a version, a rollback, a showcase app, switching an app back on): one check, one audit row app.published that names which way it went.

If your process needs a second pair of eyes, give app:publish only to the people who review, and give builders a custom role with app:update but not app:publish, so that they can ask but not approve (custom roles need Advanced Access Control).

Can Maestro or our own AI client change a live app?

No. An AI client works on the draft, through MaestroHub's MCP tools, with the permissions of the person whose token it uses. It can validate, preview and ask for a release. It cannot approve a release, activate a version or switch an app back on. It can switch an app off, because stopping is always allowed.

Running apps on the line

How do I switch an app off fast?

Open the app's Operations page, press Switch off and type the reason. Anyone who may edit the app can do it. The app stops for everyone at once: viewers see who switched it off, when and why; no new app token is issued; tokens already issued are refused on their next request on every MaestroHub server; open live-data connections end at the next revocation sweep (about every 60 seconds by default). Nothing is unpublished, and everyone who can switch it back on is notified.

Switching it on again needs a person who may publish the app, because it puts a version back in front of people. Rolling back to an earlier version is the other fast way out: History → Activate on the version before.

Can a wall screen press an app's buttons?

No. A paired display (a screen with nobody signed in, paired under Identity & Access → Devices) is read-only by design: its identity never holds a write permission, and every button that writes shows "This screen is read-only: a person must be signed in to press this. Use the app's Kiosk page on a signed-in station." The pairing dialog says so before you approve.

A station where an operator presses buttons is the app's Kiosk page (/<workspace>/apps/<app>/kiosk) opened by that operator, signed in. The buttons then work within that person's permissions, and confirmations name them.

What happens to kiosks and wall screens when MaestroHub is updated?

Kiosk pages and paired displays reload themselves after MaestroHub is updated or rolled back, and restart an app that left its page or stopped answering, so nobody has to walk to the screen. One exception is an upgrade step, not a rule: an installation that ran an earlier 3.0 build with App Studio reloads each kiosk and paired display once by hand after the upgrade (see Changes in 3.0).

People and ownership

What happens when the person who built the app leaves?

The app keeps running. Nothing a person did is undone because they left:

• Ownership moves the way it does for pipelines and dashboards: to the workspace's designated owner if one is set, otherwise to a workspace administrator (and, failing that, a platform administrator). A workspace administrator can also transfer an app at any time (Operations → Owner → Transfer ownership).
• The live version stays live. If the app has actions that act as the app itself and the person who approved it leaves or is deactivated, the people who can publish the app are told once that the next release must be approved by someone who holds what those actions do.
• The code stays. It lives in MaestroHub, in the app's own git repository with every checkpoint and version, not on anyone's laptop.
• People's own data in an app (their personal documents and favourites) is erased when their account is deleted permanently; shared documents stay, and the audit log records who wrote them.

Who can see and open our apps?

People who hold app:read and app:run: the Apps Viewer, Plant Operator and Analyst roles (Apps.Viewer, Persona.PlantOperator, Persona.Analyst), the builder roles, paired displays (through Workspace.Display), workspace administrators, and anyone an app is shared with. Sharing one app needs the Advanced Access Control licence feature; without it, give people a role that opens apps. What an app shows each person is still limited by that person's own permissions.

What if Maestro isn't available?

Maestro can be unavailable for four reasons: it is not in the licence, it is switched off on the server, no AI provider is connected yet, or a provider is connected but no model that uses it is turned on. In every case:

• The builder opens on its Build with your AI client panel, with the steps to connect your client, the prompt to give it, and the live preview, and says why the built-in chat is not available.
• On the New App page, Build with your AI client is the default and Build here is shown disabled with its reason.
• Everything else in App Studio works the same: templates and showcase apps, the preview, versions and checkpoints, the release review and publishing, sharing, Kiosk pages and paired displays, the Git mirror, backup and the Operations page. Viewing and running apps never involves Maestro.

What an administrator does about it depends on the reason. No provider or no turned-on model: connect a provider or turn on a model under Second Brain → Providers. Not in the licence: Maestro is a separate Beta, given on request. Switched off: a server administrator turns it on in the server configuration (Provider configuration for the builder).

Licence, upgrades and the future

What licence does App Studio need?

App Studio is in release 3.0 as Beta, a paid add-on that no edition includes by default. A licence that includes the app_studio feature switches it on, and so does a trial licence that MaestroHub issues with it; the free trial a fresh install starts on its own does not include it. Without the feature, App Studio is not in the rail and its API refuses calls with 403 APP_STUDIO_DISABLED. A licence can also cap how many apps are published on the instance (max_published_apps).

Sharing one app with a person needs the Advanced Access Control feature, and so do actions that act as the app itself. The builder chat inside MaestroHub needs Maestro, a separate Beta; nothing else does (next question).

What does building with my own AI client need?

MaestroHub's MCP server, switched on. It is on by default. On the single binary, a server administrator controls it with mcp.enabled in the server configuration; on Enterprise (Helm), it is the mcpgateway pod, switched with mcpgateway.enabled. When it is off, Connect an AI client says "The MCP server is switched off on this installation" instead of giving settings. Your AI client then works with the permissions of the token you create on that page.

Does App Studio need Maestro?

No. Maestro is MaestroHub's own assistant, in release 3.0 as Beta, given on request. Without it the builder opens on its Build with your AI client panel, and your own MCP client (Claude Desktop, Claude Code, Cursor and others) builds the app through MaestroHub's MCP server while you watch the preview. Templates, showcase apps, the preview, versions, release review, publishing, sharing, Kiosk pages and displays, the Git mirror, backup and the Operations page all work without Maestro. Viewing and running apps never involves it.

What happens to our apps when MaestroHub is upgraded?

Nothing you have to do. Every published version is pinned to the runtime it was built against (React, the SDK, the UI kit, three.js), and an upgrade does not rebuild your apps. Each runtime has a published support date, 18 months after it was released, and is retired only by a later MaestroHub release that says so. At any time, someone who may publish apps can open App Studio → Compatibility, which rebuilds every published app against the current runtime and tells you which are compatible, deprecated or broken. An app on a retired runtime shows a page that says to republish it; its source and versions are untouched. App data is stored with the rest of MaestroHub's data and is kept across upgrades.

How do partners and other plants get our apps?

Inside one installation, by sharing and roles: people open the apps of their own workspace that their roles or shares allow, and a builder can clone a published app into a new one of their own.

Moving an app to another installation (a partner's, or another plant's) is not a product feature yet. What exists today:

• Bindings by name (in this release): an app's code names what it uses, and only manifest.json says which topic or function each name points at. A copy of the app can be pointed at another plant's resources without changing code.
• The Git mirror: push the live version's source to your own Git repository (needs app:publish). On the other installation, a builder creates an app and writes those files into it (by hand or with their AI client), points the bindings at their own resources, and publishes it through their own review.

App packages (export a published version, install it elsewhere, bind each name to that place's own resources, receive offered updates) are designed but not built. A workspace backup cannot move apps to another workspace: restore accepts only an archive of the same workspace.

Why not build a normal web app instead?

Sometimes you should. Why App Studio compares the two, line by line: hosting, sign-in and single sign-on, permissions, audit, data access, upgrades, people leaving, finding apps, and what App Studio is not for.