Application Types

The sections below cover:

An application type records who runs the application and how the platform manages it. You choose the type when you register the application, and it does not change afterwards. The choice matters because it decides where the workload executes: on infrastructure you operate, or on infrastructure Axual operates for you.

The portal offers four types: Self Managed, Managed Connector, Managed KSML, and Managed Flink SQL. Earlier releases named the first three Custom, Connector, and KSML; the current names describe the management style rather than the technology, and the mapping between old and new names is recorded in the release notes.

A self-managed application is one you host and run yourself, connecting to the Kafka cluster with a Kafka client. Standalone Java, .NET, and Kafka Streams applications are all self-managed: the platform authorises them and tracks their topic access, but it never deploys or runs them. This type suits teams that already own a deployment pipeline and want the platform only for governance and access.

Kafka Streams applications are a special case of a self-managed application. They still run on your own infrastructure, but they rely on internal topics that the client creates at runtime to hold processing state. The platform attaches prefixed Kafka ACLs to the application when its authentication is configured, so that these internal topics are authorised without you declaring each one. That step happens in the background and is transparent, but it constrains how you choose the application ID. The reasoning, and the collision check that protects it, are covered in Kafka Streams prefixed ACLs.

A managed Connector application moves data between Kafka and an external system, such as a database, using a connector plugin that Axual runs on a Connect cluster. A connector is generic code with a fixed job (read from a source, or write to a sink); you supply only configuration, so integrating a new system is a matter of choosing a plugin and filling in its settings rather than writing an application.

The direction of flow depends on the plugin: a source connector reads from the external system into Kafka, and a sink connector writes from Kafka to the external system. The workload runs on Axual infrastructure, which is why a connector is configured rather than deployed. See Managing Connector applications for the lifecycle.

A managed KSML application is a stream-processing application that Axual runs for you from a YAML definition, with no Java to write or deploy. KSML is a wrapper around Kafka Streams that expresses a processing pipeline (filters, joins, aggregations) declaratively, so a developer describes what the pipeline does and the platform provisions and runs it on Kubernetes.

Because KSML builds on Kafka Streams, a managed KSML application carries the same internal-topic and prefixed-ACL behaviour as a self-managed Kafka Streams application. As with managed Connector applications, the difference is ownership of the runtime: with KSML, Axual provisions and supervises the pods, so choosing KSML trades the flexibility of custom code for not having to operate it. See Managing KSML applications for what running one involves.

A managed Flink SQL application is a Kafka-to-Kafka streaming transformation, written in Flink SQL, that Axual runs on a registered Flink Platform cluster. You declare the source and sink topics as tables and write the transformation as INSERT INTO …​ SELECT; there is no Java to write and no Flink infrastructure to operate yourself.

Unlike managed Connector and managed KSML applications, which run on infrastructure Axual provisions per application, a managed Flink SQL application runs on a shared Flink Cluster that a Tenant Admin registers once for an Instance Cluster. Choosing a deployment size for the application still applies, but it sizes your application’s slice of that shared cluster rather than a dedicated pod. See Managing Flink applications for the lifecycle, and Flink applications for what it supports.

Visibility controls who can see an application in the Applications page, independently of who owns it. It has two values, and the choice is about exposure, not access rights.

Visibility never grants or removes the ability to use topics; that is governed by authentication and topic access. It only decides whether the application is listed for others, so making an application private hides it from the overview without changing what it can do.