linode/apl-core: a self-service Kubernetes app platform for LKE

What App Platform assembles, and for whom

The README frames App Platform around two audiences. Developers get self-service: build OCI images from source, deploy workloads the GitOps way, expose applications publicly, read logs, metrics and traces, and create secrets. Platform administrators get a pre-configured multi-tenant setup: user management, security policies, zero-trust networking, and configuration-as-code for the platform's desired state. That split is the whole pitch. Instead of a bare Kubernetes cluster plus a wiki page, you get a stack where the identity provider, the deployment controller, the service mesh, the certificate manager and the CI engine are already wired to each other.

The integration list is the substance here. Core applications include Istio, Argo CD, Keycloak, cert-manager, ExternalDNS, Tekton Pipeline, Tekton Triggers, Tekton Dashboard, Gitea, Cloudnative-pg and Sealed Secrets. Optional applications, described as one-click activation, include Knative, Prometheus, Alertmanager, Grafana, Grafana Loki, Harbor, Kyverno, Trivy Operator and OpenTelemetry. A team that would otherwise spend weeks stitching those together gets a starting point. A team that already runs its own Argo CD and Keycloak gets a second copy of both.

The repository description on GitHub says "App Platform for Linode Kubernetes Engine", and package.json still carries the older name: "Otomi Core is an opinionated stack of Kubernetes apps and configurations." That history matters when you search for documentation, because some internal paths and environment variables still use the otomi prefix.

How the stack is wired: Helmfile, values and GitOps

The repository layout is the clearest description of the mechanism. Top-level entries include helmfile.d/, helmfile.tpl/, chart/, charts/, values/, .values/, values-schema.yaml, values-changes.yaml, apps.yaml and core.yaml. The pattern is a Helmfile-driven deployment where a small number of YAML files describe the desired state of the whole platform, and a schema validates what you write.

values-schema.yaml is the contract. The repository also ships schemas/ and a values-changes.yaml file, which suggests the project tracks migrations between value formats across releases. That is a real convenience if you upgrade often and a real constraint if you hand-edit generated files.

The operator side is TypeScript, not Go, despite the repository being labelled Go Template. The Dockerfile builds an image whose entrypoint is node dist/src/operator/main.js, and package.json depends on @kubernetes/client-node, simple-git, ajv and @apidevtools/json-schema-ref-parser. So the runtime reads Kubernetes objects, talks to Git, and validates YAML against JSON schemas. The GitOps loop is therefore: you change values in a Git repository, the operator reconciles the cluster toward that state, and Argo CD handles the application-level sync.

There is also a local development path. docker-compose.yml defines three services: api (linode/apl-api), web (linode/apl-console) and proxy (nginx), with the proxy published on port 3000 and the API on 8080. The API mounts core.yaml at /etc/otomi/core.yaml and expects Git connection details through GIT_REPO_URL, GIT_BRANCH, GIT_USER, GIT_EMAIL and GIT_PASSWORD. That compose file is for working on the platform itself, not for running a production cluster.

Installing App Platform on LKE or another cluster

The README does not give inline install commands. It points to three documented paths: automatic installation when creating a new LKE cluster on Akamai Cloud, manual installation on LKE, and custom installation on other conformant Kubernetes clusters. Follow the linked guide for your case; the commands below are the repository's own local-development entry points, not the production installer.

If you want to run the API and console locally against a values repository, the compose file is the starting point. Copy the sample environment file first, since docker-compose.yml reads variables such as GIT_REPO_URL, GIT_BRANCH and CLUSTER_ID from the environment.

cp .env.sample .env
# then edit .env and set GIT_USER, GIT_EMAIL and GIT_PASSWORD
docker compose up

The proxy service publishes port 3000, so the console is reachable at http://localhost:3000 once the api and web containers are up. The api container listens on 8080 and mounts your core.yaml read-only at /etc/otomi/core.yaml.

The sample environment file also documents a mode that skips cluster contact entirely, which is useful when you only want to render or validate values. According to .env.sample, setting DISABLE_SYNC=1 disables contacting the cluster found in the kube context, and VERBOSITY controls log detail.

DISABLE_SYNC=1 VERBOSITY=2 npm run compile

After a real installation, the README directs you to the post-installation steps guide, noting there may be additional setup such as locating your username and password. The hands-on labs are the recommended first real use: they walk through creating container images, code repositories and workloads, then monitoring them and running basic security checks.

Where App Platform gets in the way

The core application list is not optional in the way the optional list is. If you install App Platform, you are accepting Istio, Argo CD, Keycloak, cert-manager, ExternalDNS, Tekton, Gitea, Cloudnative-pg and Sealed Secrets as part of the platform. A team that has standardised on a different identity provider, or that deliberately avoids a service mesh, has to either replace components or not adopt the platform. The README does not document a supported path for swapping out a core application.

Multi-tenancy and zero-trust networking are listed as administrator capabilities, but the README does not describe the tenancy model itself: whether tenants are namespaces, whether they share the mesh, or how Keycloak realms map to teams. That detail lives in the linked documentation, and you should read it before promising isolation to anyone.

Upgrades carry the usual platform risk. The presence of values-changes.yaml and a versioned values-schema.yaml implies that value formats move between releases, so an upgrade is not only a container image bump. The repository has a Release.md for maintainers, which tells you releases are a deliberate process rather than a rolling tag. If your team cannot absorb a coordinated upgrade window, a smaller stack will cost you less.

Finally, the naming is confusing in practice. The GitHub repository is linode/apl-core, package.json still calls the project Otomi Core, and the compose file references otomi paths and a default GIT_REPO_URL pointing at a redkubes repository. Searches for "apl core" also surface unrelated results, so use the Akamai Techdocs home page rather than a general search when you need the current guide.

App Platform compared with assembling the components yourself

The obvious alternative is not another product; it is doing the integration work yourself. Install Argo CD, Keycloak, cert-manager and ExternalDNS from their own Helm charts, write your own tenant onboarding, and keep your own golden-path templates. You end up with the same building blocks, chosen at versions you control, with no opinionated defaults and no shared values schema.

The difference is where the effort sits. Self-assembly front-loads integration work: you decide how Keycloak groups map to namespaces, how Argo CD projects isolate teams, and how certificates get issued. App Platform front-loads configuration work instead: you learn its values schema, its app catalogue and its upgrade process. Neither is cheaper in total; they fail in different places. Self-assembly fails when nobody owns the glue. App Platform fails when you disagree with a default that is baked into the core set.

A second alternative is a hosted platform-as-a-service. That removes the operator entirely but reintroduces the lock-in the README explicitly claims to prevent, since the stated goal includes preventing cloud provider lock-in and supporting multi- and hybrid-cloud PaaS. If portability is your reason for looking at App Platform, a hosted PaaS is the wrong trade.

Maintenance, licensing and what to check first

The repository is not archived and the last push was on 2026-09-10, so the codebase is moving. Recent releases include v6.2.1 on 2026-08-21, preceded by v6.2.1-rc.2 and a parallel apl-v6.2.1-rc.2 tag on 2026-08-20. The dual tagging pattern is worth noting if you script release checks: filter on the tag format you actually deploy.

Licensing is Apache-2.0, stated in the README and in the LICENSE file. That permits commercial use and modification, and it carries the usual patent grant and notice obligations. It does not tell you anything about the licence terms of the bundled applications, which are separate projects with their own licences. In particular, some observability and registry components in the optional list have licences that differ from Apache-2.0, and you should check each one you enable rather than assuming the platform's licence covers the stack. This is not legal advice; review the bundled licences with whoever handles compliance for you.

Upgrade cost is the real maintenance question. Because the platform is configuration-as-code with a versioned schema, your upgrade work is mostly reconciling values files, not rewriting manifests. Budget for reading values-changes.yaml at each minor version and for testing that your tenant configuration still validates. The Dockerfile shows the build runs the project's own test suite unless SKIP_TESTS is set, which gives you a signal on repository health but says nothing about whether your configuration survives an upgrade.

Editorial conclusion

Adopt App Platform if you run Linode Kubernetes Engine and want a pre-integrated developer self-service layer rather than assembling Argo CD, Keycloak, Istio and Tekton yourself. Skip it if you only need one of those components, or if you want a cloud-agnostic distribution with no opinionated defaults. Before committing, read the custom installation page for non-LKE clusters, check whether your cluster can carry the full core app set, and confirm which optional apps you actually need, since each one adds its own upgrade surface. The repository is Apache-2.0 and the last push was on 2026-09-10.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. linode/apl-core on GitHub
3. Project website
4. README
5. Releases