Skip to main content

Application hosting and lifecycle

DIAL applications expose business logic through the platform. Hosting responsibility depends on the application type. This page helps architects choose that boundary; read the component map first.

Choose who runs the application​

Registering an application in Core gives clients a governed way to invoke it. Hosting determines where its business logic executes, who supplies its dependencies, and who responds when it fails. Those are separate choices: a Custom App can use gateway access while its team retains the complete runtime.

ApproachRuntime modelYour team owns
Quick AppsConfigured agents served by the Quick Apps runtimeInstructions, models, tools, access, and quality; the platform team operates the runtime
Code AppsPython code built and hosted on DIAL infrastructureCode, dependencies, permissions, and workload requirements
Custom AppsA service you deploy and register in CoreCode, hosting, scaling, state, networking, and operations
note

Schema-based application types describe configuration and editors. They do not imply that every type has the same execution or isolation model. See DIAL Apps for the builders and Code Apps for the Python runtime.

Separate authoring, execution, and release​

The stages below apply across the application approaches, but each uses a different artifact: Quick Apps configuration, Code Apps source, or a Custom App service. The runtime makes that artifact callable; sharing or publication makes it available to its intended audience.

The colors distinguish green authoring/publication interfaces, a gray runtime, and purple evaluation/operating activities. The arrows show lifecycle progression, not network calls or an automatic deployment pipeline. DIAL Eval evaluates applications, agents, models, and MCP tools against your datasets and metrics. DIAL Grid compares models on individual tasks. Use them to validate changes, including a different model or fallback target, before moving production traffic.

warning

Sharing grants selected users access. Publication goes through administrator review. These resource permissions are separate from the runtime's infrastructure permissions. Editing or publishing an application changes who can use its resource; it does not by itself define its service account, permitted network destinations, or database access.

Keep runtime permissions explicit​

For Code Apps, App Controller coordinates image builds and Knative deployments. App Builder Python prepares and validates their sources. Quick Apps' Python calculation tool uses a separate Code Interpreter session managed through Core and the controller.

Applications call models and tools through Core using delegated context; see Request flow. An application's own credentials, network access, and data stores also determine what it can do.

For executable code, establish resource limits, filesystem/session boundaries, permitted outbound connections, and secret access.

Operate the complete solution​

For example, a Custom App can keep its own database while invoking models through Core. Model access and delegated calls use DIAL's controls, while the application team still backs up the database and manages credentials for any direct external connections. Platform integration does not transfer those duties automatically.

Core provides governed access. The application team remains responsible for business behavior, external side effects, and answer quality. The platform team operates the selected runtimes, dependencies, backups, and upgrades. See State and data lifecycle for application data and indexes.

Further reading​