Why App Studio

Beta: an App Studio app against a custom web application on its own server, compared on what each one costs you to run, secure and keep alive.

Compares

Hosting, sign-in, permissions, audit, data, upgrades, people, finding apps

Also says

What App Studio is not for

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.

A plant that wants a screen for line 3 (station states, a shift book, an interlock release) has two ways to get it. It can write a web application and run it on a server of its own, or it can build an App Studio app inside MaestroHub. Writing the screen itself is a small part of either, and an AI client can help with both. The difference is everything around the screen: where it runs, who may open it, what it may touch, who answers for it in a year, and what happens when the person who wrote it moves on.

This page compares the two on those points. It also says plainly where App Studio is the wrong choice.

What a custom app has to bring with it

A web application that shows plant data and writes to a PLC gateway is not finished when the screen works. Before it can go on the line, someone has to decide and build:

• A place to run. A server or container, its operating system, patches, backups, monitoring, and a person who is called when it stops.
• An address and a certificate. A DNS name, a TLS certificate and its renewal, and a firewall rule from the operator screens to it.
• Sign-in. A login page, or a connection to the plant's single sign-on (OIDC or SAML) with its own client registration, secrets and sign-out.
• Permissions. Who may open it, who may press which button, and how that follows people when they change jobs. Usually a second copy of rules that already exist in MaestroHub.
• Access to the data. A service account or API token for MaestroHub, stored somewhere, usually holding more rights than any single user of the app.
• Audit. A record of who released which interlock, when, and what exactly was sent.
• Releases. Who may put a new version in front of operators, how to go back to the old one, and how to stop the app at once when it misbehaves.
• Upgrades. Keeping its libraries current, and keeping it working when MaestroHub's API changes.
• People leaving. The source, the server login, the certificate's renewal and the knowledge of how it all fits, usually held by one person.

None of this is hard on its own. Together it is a small product that the plant now owns, and most of it is the same work for every screen.

The two side by side

	A custom app on its own server	An App Studio app
Hosting	A server or container you run, patch, back up and monitor.	Runs inside MaestroHub. Nothing new to run, patch or monitor.
Address and certificate	A DNS name and a certificate of its own, renewed on time; a firewall rule from the screens.	MaestroHub's own address, under /_apps/. No DNS record, certificate or setting. Works on a bare IP, plain HTTP on the plant network, behind a proxy and under a sub-path; Safari and iPad need an address a security policy can name (not IPv6 literals or names with _).
Sign-in and single sign-on	Built into the app, or a second client registration with your identity provider.	MaestroHub's sign-in, with the single sign-on you already set up. The app does not handle sign-in: it receives a short-lived app token, never the person's password or session.
Permissions	Rules written into the app, kept in step with MaestroHub's by hand.	MaestroHub's roles and sharing. The app gets only what both its manifest and the viewer's permissions allow, renewed every few minutes, so a permission taken away reaches the app at the next renewal.
Access to data	A service account or token with fixed, usually broad rights.	No standing credential. The app acts as the person looking at it. An action that must act as the app itself needs a person who holds that right to approve the release.
Writes that matter	A confirm dialog the app draws itself, if anyone wrote one.	MaestroHub draws the confirm dialog, shows exactly what it will send, and accepts the confirmation once, for that request, within 60 seconds.
Audit	Whatever the app logs.	Every write in MaestroHub's audit log with the app, the version and the person (repeated plain writes as one row per person, app and action per minute, with a count); confirmed writes with who confirmed and what the dialog showed; every release with who approved it and how.
Releases and stopping it	Your deployment process. Rolling back and switching off are scripts or server access.	Publish is a review a person approves. Rollback is Activate on the earlier version. Switch off stops it for everyone at once, with a reason they all see.
Isolation	The app runs with the rights of its service account, on its own origin.	Each app runs in a frame the browser treats as an anonymous origin: it cannot read the MaestroHub sign-in, the MaestroHub page or other apps' data, and the browser lets it load and call only MaestroHub, within the limits in What isolation does not cover.
Upgrades	You keep its libraries and its calls to the MaestroHub API current.	Each published version is pinned to the runtime it was built against; a MaestroHub upgrade does not rebuild or break it. Each runtime has a support date 18 months after its release, and a compatibility scan shows which apps a newer runtime would break.
People leaving	The source, the server and the knowledge often leave with one person.	The code, every version and every checkpoint stay in MaestroHub. Ownership moves to the workspace's designated owner or an administrator; live apps keep running.
Finding apps	A bookmark or a link someone sends.	Apps in MaestroHub, with stars on each person's sidebar, a fixed address per app, and wall screens paired to an app.
Wall screens	A browser logged in as someone, or a shared account.	Paired displays with their own read-only identity, revoked in one click; Kiosk pages for stations where a signed-in operator acts.
Backup	Part of the server's backup, if someone added it.	One archive per workspace, database and git together; restored apps come back switched off.

What you give up

The right-hand column comes from limits that are there on purpose. Before choosing App Studio, check that your app can live with them:

• Only a fixed set of libraries. An app can import React, the MaestroHub SDK and UI kit, the 3D scene kit and three.js with three of its add-ons, and its own files. No npm packages and nothing from the internet.
• No server code of its own. An app runs in the browser. Work that must happen on a server, on a schedule or without anyone looking belongs in a MaestroHub pipeline, which the app can start and wait for.
• Only MaestroHub as a network peer. The app may call MaestroHub and nothing else (the browser enforces it, within the limits in What isolation does not cover). To reach another system, go through a MaestroHub connection and its functions, which the app calls by name.
• No browser storage. localStorage keeps values in memory only and cookies and IndexedDB are unavailable. Keep values with the SDK's own storage: per person or shared, up to 256 KB per document and 1 GiB shared per app.
• Small by intent. An app is one screen or a few, for a job on the line. It is not a portal with dozens of pages.
• A per-app call budget. Calls an app makes are rate limited per app (50 per second with bursts of 100 by default, shared by everyone viewing it), so a polling loop cannot load the platform. Live values come by subscription instead.
• Everyone who opens it is a MaestroHub user (or a paired display). There is no anonymous or public access.
• Beta. Names and steps may still change in release 3.0.

What App Studio is not for

• Controlling the machine. An app can ask a PLC gateway to do something through a connection function, with a person confirming. It is not an HMI or SCADA replacement, and it is not where interlocks, safety functions or control loops belong. Those stay in the PLC and its HMI.
• Customer-facing or public websites. Every viewer signs in to MaestroHub or is a paired display inside the plant.
• Large business applications with their own data model, many users editing the same records at once, or reports over years of history. Build those as applications of their own and connect them to MaestroHub through its API, or use the tools MaestroHub already has for that kind of work (dashboards, pipelines, the historian).
• Apps that must work with no connection to MaestroHub. An app keeps showing the last values when the connection drops and queues records to send later, but it starts from MaestroHub and needs it to act.
• Apps that need a library outside the fixed set, or a direct connection to another service from the browser.

A rule of thumb

If the screen is for people who already use MaestroHub, shows MaestroHub data, and writes through MaestroHub's connections, an App Studio app avoids building and running a second sign-in, permission model, audit trail and release process for it. If it must run without MaestroHub, serve people outside it, or needs code and libraries that App Studio does not allow, build a separate application and give it its own API client in MaestroHub.

See App Studio, start to finish for one app's whole life, A live 3D view of your plant for a use case, and the FAQ for the questions IT administrators ask first.