AI App Store recognizes three actors:
- App Developer: creates and publishes apps
- App User: browses and runs apps, can be either user with "full access" or visitor
- Admin: manages the platform
over five resource types:
- App: runnable Wave app package
- App instance: running instance of an app
- App tag: label for categorizing apps withing the platform
- App secret: sensitive information needed to run apps within the platform or dynamically injected configuration
- App alias: a custom URL for a particular app instance
App is a runnable Wave app package with metadata, such as (grouped into categories):
- a unique name and version identifier
- a title and description
- icon and screenshots
- long description
- owner (i.e., the person who imported it into AI App Store)
- visibility (
- Instance lifecycle (
- RAM/disk requirements
- other runtime settings (e.g., pointers to dependencies and secrets to be injected at startup time)
Users can start/run multiple instances of each app - subject to Authorization.
Every authorized user can start their own instance.
Apps are mostly immutable, meaning once uploaded, they cannot be changed, except for their App Store configuration options (see Configuration Options). To "update" an app, one has to upload a new version. This is to simplify the app lifecycle and remove the need for developers to address app upgrade/downgrade.
See the CLI documentation for instructions on how to manage apps.
Internally, AI App Store treats every app name/version combination as a separate entity. The UI then uses the app name to link several versions together; however each can have different title, description, owner, instances, etc.
App instance is a running instance of an app with the following metadata:
- pointer to the corresponding app
- owner (the person who started it)
- visibility (
The AI App Store fully manages the app instance lifecycle on behalf of its users.
Instances can be stateless or stateful (depending on the app configuration) and can use external dependencies (e.g., AWS S3, Driverless AI).
Under the hood, each instance consists of several k8s resources, specifically, each instance is running in its
pod, under its own k8s
service, accessible via a AI App Store subdomain (e.g.,
It can optionally include other resources, such as PVCs, Configmaps, etc.
See the CLI documentation for instructions on how to manage app instances.
Tags are means of annotating apps in the platform (similar to GitHub issue labels). Beyond visually categorizing apps, tags also act as a mechanism by which apps are exposed to "visitors" (i.e., users without "full access"); see Authorization for Visitors for details.
Tags are standalone resources with the following metadata (grouped into categories):
- Display/search properties
- name, title, color, description
- admin roles (i.e., the users that can manage the tag)
- visitor roles (i.e., the visitors that can view apps with this tag)
Tags are assigned to apps individually. Each tag can be assigned to multiple apps, and each app can have multiple tags assigned to it.
See the CLI documentation for instructions on how to manage tags.
Secrets are backed by Kubernetes secrets and a meant for storing sensitive information that can be mounted as an environment variable or file. Secrets are standalone resources with the following metadata:
- visibility (
- parent (the parent scope of the secret; name + visibility + parent uniquely identify a secret)
- owner (the person who created it)
See the CLI documentation for instructions on how to manage secrets.
Aliases are essentially assignable custom URLs for app instances.
By default, running instances of apps have URLs like
Via an alias, we can expose the same instance under
Aliases are standalone resources with lifecycles that are separate from app instances. They include the following metadata:
- instance ID
- whether it is a primary alias or not
Having a separate lifecycle, an alias can be dynamically assigned to an instance or moved from
one instance to another.
If an instance corresponding to an alias is terminated, the alias will keep on existing but will become inactive,
404 response for all attempts to visit it, until it is assigned to another instance.
One instance can have multiple aliases assigned, but each alias can only be assigned to one instance.
The alias marked as
primary will serve as the actual URL for accessing the instance.
Accessing the instance via other aliases or via its UUID URL will result in a HTTP
302 redirect to the primary alias.
If an instance has no primary alias, then the UUID URL is considered to be the primary alias.
There can be, at most, one primary alias assigned to an instance.
See the CLI documentation for instructions on how to manage aliases.
Visibility is a generic concept for governing some basic authorization rules for resources that do have this attribute, such as app, app instance, and app secret. For concrete rules and more information, see Authorization.