Applications

The application list is Trustant’s home screen. Everything you build lives here, and every action that operates on a whole application — open it, edit its environment, sync it with GitHub, publish it, remove it — starts from this page.

List application

The page has four bands.

The header carries the Trustant logo, the product name, and a compact release tag — V0.4.0 · MAIN above — giving the version and the build stream it came from. Hovering it reveals the exact source branch and build label, which is how you tell a local build from a development or release image. At the far right sit the global buttons, TERMINAL, SHARED VARIABLES, CONFIGURE and ADD APP.

The summary row counts four things at a glance:

• APPLICATIONS — how many you have in total.
• PRODUCTION — how many are configured for production, i.e. have a cluster to publish to.
• DEVELOPMENT — how many exist only locally so far.
• REPOSITORIES — how many have a Git repository behind them.

The Applications card — labelled WORKBENCH INVENTORY — is the list itself, with its search box, sort selector, view switch and filters. The count under the heading (“1 application”) always reflects what the current search and filter actually show.

The footer reports the build identifier and the expiry date of this Trustant version, plus a short hash identifying the ops task set in use. Trustant builds carry an expiry; past it, the app asks you to update.

Terminal

TERMINAL opens a shell in a dialog, in the Trustant workbench folder, without leaving the page. CLOSE closes it.

Shared Variables

SHARED VARIABLES opens the workspace-wide values applications may use, one set per environment (Development or Production). A value here fills in a variable an application already declares and left empty; it never adds variables an application does not ask for.

ADD VARIABLE adds a row and IMPORT FROM FILE loads them from a file; changes are saved as you make them. Rows marked with an application name come from that application’s .env.shared: they are resolved again on every launch, so they are read-only here and edited with the application’s SHARE button. See Variables.

Configure button

Opens the Configuration page — provider, models, license, Git identity and shared environment values. It is workbench-wide settings, not per-application ones; those live behind each row’s ENV button.

Add applications

ADD APP opens the Add Application dialog. There are two ways to get a new application, presented as tabs: start from a Starter — an empty but correctly wired skeleton you then describe to the AI — or pick a ready-made application from the catalog and adapt it.

Starter

The STARTER tab is the default. It offers a short radio list of starters — minimal, convention-compatible repositories maintained for Trustant — each with its name as a link to its GitHub page and a one-line description:

• truchat — AI chat UI with RAG.
• trureact — a generic React starter.
• My Application Starter — always the last row, for using a repository of your own rather than a published starter.

Below the list:

• Application Name — the name of the new application, and the identity it keeps everywhere: its repository, its workspace, its URL. It must be 6–20 alphanumeric characters starting with a letter, as the hint says, and it must not collide with an application you already have.
• GitHub Repository — in org/repo form. It is prefilled from the starter you selected and is where the code comes from. Choosing My Application Starter is what makes this field yours to fill in; it is also the case where a private repository may need a connected GitHub account, so the dialog offers to connect one there.

CREATE creates the application: Trustant clones the starter into a durable repository of its own for this app, registers it, and returns you to the list. If the starter declares environment variables with no value, Trustant asks you to fill them in before going further.

Starters are discovered from a published index rather than by querying GitHub, so the list is identical on every installation. If it cannot be loaded, the dialog says so and leaves My Application Starter available, so you are never stuck.

Chat

The remaining tabs — CHAT, DEMO, EXAMPLES, UTILITIES — browse the catalog of complete, working applications. Each tab is one group, shown as a carousel: one application at a time, with its title at the top linking to its GitHub repository, a screenshot in the middle, and its description underneath.

The ‹ and › arrows step through the group and wrap around at both ends; the arrow keys do the same. The “1 of 3” counter tells you how far along you are. A group holding a single application shows neither arrows nor counter.

The Chat group collects conversational applications — here AI Database Manager, an interface that turns plain-language questions into live PostgreSQL work.

Clicking anywhere on the card except the title link opens a small name panel: it names the application and the repository it will be created from, prefills an Application Name, and offers Cancel and Confirm. The prefilled name is only a starting point — you can edit it freely, and if the obvious name is taken Trustant appends the smallest free number (tetris, tetris1, tetris2). Cancel returns to the carousel rather than closing the dialog, because you are choosing, not aborting.

Demo

DEMO holds showcase applications demonstrating what Trustant can build — here AI CRM, a contact-and-ticket dashboard.

Examples

EXAMPLES holds worked examples you can learn from or build on — here API Status Monitor, which polls endpoints and records uptime, response times and check history.

Utilities

UTILITIES holds practical tools — here Document Ingest, which uploads PDFs and runs them through an ingestion pipeline so an AI application can search them.

An application can be listed under more than one group. Whichever tab you create it from, it is created from that entry’s own repository, so two entries in the same group give you two genuinely different applications.

Switching tabs never loses what you typed elsewhere: the Starter tab keeps its selection and name. Reopening the dialog always resets to Starter.

Application

The APPLICATION column identifies each application: a colour-coded initials badge, the application name, and — when it is running — a DEVELOPMENT link that opens the live local application in a new tab. That link is how you look at what you are building outside the editor.

Filters

Three segmented filters restrict what the list shows. They combine with the search box, and the “N applications” count follows both.

All

ALL — the default. Every application, whatever its state.

Production

PRODUCTION — only applications configured for production, meaning they have a cluster host, user and credentials recorded and can be published.

Development only

DEVELOPMENT ONLY — the complement: applications that exist only locally and have never been given a production target. Useful for spotting work that is ready to ship but not yet configured.

Search

The controls above the filters:

• Search apps or repositories — filters as you type, entirely in the browser with no round trip to the server. It matches the application name, the repository, and the production host and user, so you can find an application by where it is deployed as well as by what it is called.
• Name — the sort selector; sort by application name or by repository.
• GRID / LIST — the view switch. LIST is the default dense table.

Grid

GRID shows each application as a card instead of a table row. The card carries the same information laid out vertically: the initials badge and name, the repository link, state chips (Development, REPO), then two wide buttons for the environments — DEVELOPMENT, which opens the running local application, and NO PRODUCTION, which is inert here and simply reports that this application has no published deployment yet. The actions sit at the bottom of the card.

Grid is the better view when applications have screenshots or you are scanning a handful of them; List is better once you have many.

Repository

The REPOSITORY column shows the GitHub repository backing the application, as org/repo, linked to its GitHub page. This is the code’s public home — the target of Git Pull and Git Push — as distinct from the durable local copy Trustant keeps for itself.

Status

The STATUS column reports which of the two states the application is in: DEVELOPMENT when it exists only locally, PRODUCTION once it has been published to a cluster and is serving real users.

Action

The ACTIONS column carries every per-application operation. They are described one by one below, in the order they appear.

Edit

EDIT is the main one — it opens the application in the workbench editor, where you talk to the AI assistant and watch your application update live. See Editing.

Clicking it launches the application, which is real work: Trustant checks the code out into a working area, regenerates its configuration files, logs in to the cluster, installs dependencies and starts the development server. A progress bar tracks the actual lifecycle stages rather than a timer, so it reflects genuine progress; if a stage fails, the bar stops where it got to and the error is shown.

Clicking Edit again — from this tab or another — is safe. Trustant reuses a runtime that is already healthy instead of starting a second one.

Env

ENV opens the environment editor for this application: a table with a VARIABLE column and separate Development and Production values, so one application can point at a test database locally and the real one in production.

Four rows are fixed and cannot be removed:

• OPS_APIHOST — the cluster the application publishes to.
• OPS_USER and OPS_PASSWORD — its credentials on that cluster.
• OPS_REPO — its production repository, initialized from the Git origin.

For these, the development value is managed by Trustant and read-only; the production value is yours to set. Below them you add and remove your own variables freely.

Import .env and Import .env.production fill a column from a local file, parsed in the browser. Neither import writes anything until you press Save, which writes both files; Close warns you if changes are pending.

Values you keep in Predefined Environment Variables are offered here through a Use predefined values button when a required variable has no value. Nothing is copied in without you confirming it.

Share

SHARE sets which variables this application exchanges with the others, in two tabs:

• IMPORT — the variables this application needs from the shared ones. Give the name of the variable, and how to find it: leave the pattern empty to match a shared variable with exactly the same name, or use * to match a shape — *__POSTGRESDB matches whichever application exports it. A variable with no match is marked no match.
• EXPORT — the variables this application offers to the others.

SAVE writes them to the application’s .env.dist and commits it. See Variables for a worked example.

Git Pull

GIT PULL brings changes from GitHub into Trustant — work done elsewhere, by a teammate or by you on another machine.

It pulls from the configured production repository when there is one, and from the application’s original origin otherwise, then updates both Trustant’s durable copy and, if the application is checked out, the working copy.

The pull is deliberately conservative: it never merges, rebases, hard-resets or overwrites uncommitted work. If you have local changes or the histories have diverged, it stops and tells you, leaving your work untouched — commit or set your changes aside first, then pull again.

When the pull did change the checked-out copy, Trustant asks whether you want to deploy as well, since fresh code usually needs redeploying to take effect. Declining changes nothing.

Git Push

GIT PUSH sends your committed work to GitHub — the reverse of Git Pull.

The first push for an application needs a target, so Trustant asks for the production repository in org/repo form. The same dialog offers to connect your GitHub account, which is the recommended path: Trustant then pushes over HTTPS using the connection, with no key to manage. If you would rather not connect an account, a collapsed “Use an SSH deploy key instead” option reveals a key you can add to the repository’s deploy keys with write access.

Once configured, the repository is remembered and later pushes go straight through. Trustant pushes the repository’s own default branch rather than assuming main.

Git Push requires a valid license. Without one, Trustant offers to install a license rather than failing silently. See Configuration.

Publish

PUBLISH deploys the application to your OpenServerless cluster and moves it into the Production state, reachable at its own URL by real users.

The first publish asks for the cluster details — OPS_APIHOST, OPS_USER and OPS_PASSWORD — since Trustant cannot guess where you want it to run. The dialog notes that you need an OpenServerless environment, and points at info@nuvolaris.io or the OpenServerless project if you do not have one.

With the target known, Trustant prepares a clean checkout, generates the production environment files, logs in to the cluster in production mode, and deploys. Later publishes skip straight to the deployment.

Publish requires a valid license, and the license must cover the specific cluster host you are publishing to — a valid license for one cluster does not authorize another. Local development clusters are exempt from the host check but still need a valid license.

Undeploy

UNDEPLOY is the counterpart of Publish: it removes the application’s deployed actions and packages from the cluster, taking it out of production.

It is deliberately narrow. Your code, your local repository, your configuration and the application’s entry in this list are all untouched — only the running deployment goes away, and you can publish again at any time. Because of that narrowness it needs no license.

A confirmation modal asks “Undeploy <name>? This removes its deployed actions and packages.” before anything happens, and the command output is shown when it finishes.

Undeploy runs inside the application’s checked-out copy using cluster credentials, so an application that has never been opened has nothing to undeploy from: Trustant replies “workbench not found — launch the app first.”

Delete

DELETE removes the application from Trustant — its entry, its local repository and its checkout. It is styled in red because it is the only genuinely destructive action on this page and, unlike Undeploy, it does not leave the source behind.

Anything you have pushed to GitHub survives, since Delete acts on Trustant’s copy rather than on the remote repository. Anything you have not pushed is gone. If the work matters, Git Push before you delete.

Next

• Editing — what the EDIT button opens.
• Configuration — what CONFIGURE opens.