Build Pro Apps

Pro apps include a managed backend that is hosted by Operator. Over time this backend will provide persistent storage, secrets, server procedures, an HTTP proxy, structured logging, public access, and custom domains.

What makes an app Pro

A Pro app is an app whose owner has upgraded it from the Free tier. Pro apps consume AI credits — starting at 1 credit per day and increasing with usage.

To upgrade an app:

  1. Open the app in the App Builder.
  2. Switch to the Properties tab.
  3. In the Pro App card, click Upgrade to Pro.

Downgrading returns the app to the Free tier. Managed backend features stop being available, and the app stops consuming backend credits.

Backend tab

Once an app is Pro, a Backend tab appears in the App Builder. The tab contains sub-sections for the different backend services. Today Files, Tables, Web Requests, and Pages are active; the other sections are released progressively.

Files

The Files section lets you store files that the app can read — and, if you allow it, write — while it runs. Useful for configuration, templates, reference data, or generated reports.

Any file can be marked read-only, so the app can read it but never overwrite or delete it. By default an app can only read and overwrite files that already exist; you can also allow it to create new files while it runs.

Files are private to each app. See File Storage for the full details.

Tables

The Tables section gives the app its own records — orders, settings, drafts, favourites. Rows are found by a row key, can be grouped for listing and reporting, and are kept separately for each ERP.net instance (or shared, for global tables).

Just tell the App Builder what the app should remember — "keep a list of the daily requests", "remember my last selection" — and it creates the tables and wires them into the app.

See Table Storage for the data model and how the app uses it.

Secrets

The Secrets section stores credentials — API keys, client ids and secrets — that the app can use but never see. Values are write-only: they can be set and replaced, never read back.

Each secret can hold one global value for the app plus a separate value for a specific ERP.net instance, which takes precedence when the app runs there.

See Secrets.

Web Requests

The Web Requests section defines outbound calls to external services. The app calls a request by name and passes parameters; the address, headers, body and credentials stay on the backend. Bearer, basic and OAuth2 client-credentials authentication are supported, with tokens fetched and renewed automatically.

See Web Requests.

Pages

The Pages section defines additional URL paths for the app beyond the home page. Each page has its own source folder and access mode — public, signed-in Operator user, or signed-in ERP.net internal user.

Use pages for separate screens, public landing pages, and shareable forms. Each page lives in its own folder under pages/; sub-pages are nested sub-folders.

See Pages.

Who the app sees as the current user

An app can ask Operator who is using it. It always gets your Operator account, and — when available — the ERP.net user of the instance the app runs on.

The ERP.net user is reported only when the signed-in session belongs to that same instance. If you switched instances, or the loaded session comes from another connection (including a client-mode one), the app gets no ERP.net user rather than a name from a different instance. Apps then fall back to your Operator name.

This keeps authorship stamped on saved records consistent with the instance the record is stored in.

Coming soon

The managed backend will expand to include: