# apl-core: App Platform, Otomi Core, RedKubes and a Rust badge, in one repository

> An opinionated Kubernetes stack installed onto Linode's managed engine. The same files call it App Platform, Otomi Core and a RedKubes project, the container images use a fourth abbreviation, the README carries a broken badge and a badge for a Rust crate this project does not publish, and every build depends on a pinned tools image built somewhere else.

**linode/apl-core** — App Platform for Linode Kubernetes Engine

- Repository: https://github.com/linode/apl-core
- Website: https://techdocs.akamai.com/app-platform/docs/welcome
- Stars: 2,257 · Forks: 187
- Language: Go Template
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/linode-apl-core

## One repository, four names

The repository, the README and the package manifest do not agree on what this is. The repository is abbreviated, the README calls the thing App Platform, and the manifest's own description calls it Otomi Core, an opinionated stack of Kubernetes apps and configurations that is part of an Otomi container platform, authored by RedKubes. The container images in the local development stack use the repository's abbreviation for two services, one for the API and one for the console. The configuration file the stack mounts is called by the older product name in its path, and the default values repository the API clones on startup is another company's Git server. Four names, one tree, and no comment anywhere explaining the migration.

## The badge row has a broken URL and a crate from another ecosystem

The badges at the top are worth reading closely, because two of them are wrong in instructive ways. The workflow badge has an empty path segment between the host and the repository name, so the image it requests is not the one it looks like it is asking for. And there is a Rust crate badge pointing at a crate whose name is the three-letter abbreviation of this project, on a repository that publishes no Rust crate at all: the manifest is a Node package, and the recorded primary language for the tree is a template language, which makes sense given the chart and template directories at the root but tells you nothing about the code. Neither badge is load-bearing, but they are the first thing a reader sees and both are evidence of copy and paste across projects.

## The local stack talks to itself and takes a git password in the environment

The development compose file is worth reading as documentation, because it shows the assumptions the installer makes. The API service mounts a configuration file from the working directory into a path named after the older product, and it passes a cluster API server address that points at its own published port on the loopback interface, which is only coherent because nothing in the compose stack is really talking to a cluster. It also takes a git username, email and password as environment variables with no default, and defaults the values repository to a public Git server. The console runs with an enterprise mode flag set. And the API container's user is taken from two variables that the sample environment file never defines, so a first run either fails or runs as the image's default user.

## Both build stages come from a pinned tools image this repository does not build

The Dockerfile's first stage and its runtime stage are both based on the same separately published tools image, pinned to one tag. That image supplies the Node runtime and the binaries the operator shells out to, so nothing in this repository alone determines what ends up in a build. The runtime stage then stamps a version into the package manifest with a build argument that defaults to a placeholder and a flag that permits the stamp to equal the existing version, so two builds of the same commit can report the same number without complaint. It also sets the Node module search path to a relative directory, which means resolution depends on the working directory the entrypoint happens to start in.

```
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["node", "dist/src/operator/main.js"]
```

The init process in front of Node is the right choice. Everything else about the build is a trade the base image is making for you.

## Install scripts are skipped, tests run inside the image, and there is a mode with no Docker at all

Two build details combine into one behaviour. Dependencies are installed with scripts disabled, so anything a dependency would have compiled or downloaded at install time does not happen, and a comment explains that the ordering is there to take advantage of layer caching rather than for correctness. Then the test suite runs as part of building the first stage, inside a conditional that a build argument can skip, which means an image build is also a test run. The sample environment file documents the other escape hatch: a mode that bypasses Docker entirely and expects the binaries to be present on the host, flags to disable contacting the cluster found in the local context, and a commented-out switch that turns off the core path to get closer to production behaviour.

## Argo CD and Tekton sit side by side, and the secret sealing client is a fork

The integration list is the real product description. Eleven applications are core: a service mesh with transit encryption, a declarative deployer, an identity provider, a certificate manager that can issue or accept a wildcard certificate, an external DNS synchroniser, three pipeline components for declaring and triggering pipelines plus a web UI for them, a self-hosted Git service, a PostgreSQL operator, and a tool that encrypts a secret so it can live in a Git repository. Nine more are one-click optional, covering serverless serving, metrics, alerting, dashboards, log collection, an image registry with scanning, a policy engine, a security toolkit, and a telemetry operator. Note that there are two GitOps layers by design, one for deployment and one for CI, and that the sealing client in the manifest is a first-party fork of the upstream tool.

## The documentation is on a portal, the reasoning is in the repository

Every documentation link on the page points at a vendor documentation portal rather than at anything in this tree, including the install guides, the post-installation steps and the hands-on labs. That splits the project in half: the page tells you what the product is and where the manual lives, and the repository holds the reasoning. It has an architecture decision record directory, a context file, a release process document, a changelog, a security policy and a contributing guide, plus chart and values directories with a schema and a change log for values. Installation itself is documented as three routes rather than one: automatic when a new managed cluster is created, manual on that managed service, and manual on any other conformant cluster, which is the route that makes the lock-in claim on the page testable.

## Conclusion

What is actually being distributed here is a large, opinionated bundle of Kubernetes applications with an installer around it, not a platform you assemble yourself, and the integration list is the honest description of the product. Two things to weigh. The naming is a genuine liability for anyone reading logs or image references: the same artefact answers to four names across its README, its manifest, its images and its config mount path. And the build is not self-contained, since both the test stage and the runtime stage are built on a separately published tools image pinned to one tag, so a build from this repository is only as reproducible as that image. Read the integration list before the feature list, and treat the four-name situation as the thing you will have to work around in scripts.

## FAQ

### What is the App Platform for Linode Kubernetes Engine?

An opinionated stack of Kubernetes applications and configurations installed onto a managed Kubernetes cluster, either automatically when a new cluster is created or manually. It bundles a service mesh, a GitOps deployer, an identity provider, pipelines, and a Git server.

### What is Otomi Core and how does it relate to App Platform?

The package manifest describes this repository as Otomi Core, part of the Otomi Container Platform, authored by RedKubes, while the repository and the README call it App Platform and the container images use a third abbreviation. All of the names coexist in the same files.

### How do I install the App Platform?

Three documented routes: automatically when creating a new managed Kubernetes cluster, manually on that same managed service, or manually on any other conformant Kubernetes cluster. Post-installation steps follow, and the page warns that some of them involve locating your username and password.

### Which applications does the App Platform install by default?

Eleven core applications, including a service mesh, a declarative deployer, an identity provider, a certificate manager, an external DNS synchroniser, three pipeline components, a self-hosted Git service, a PostgreSQL operator, and a secret sealing tool. Nine more, from serverless serving to policy and security engines, are optional one-click additions.

### Does the App Platform require Linode's Kubernetes service?

No. The page describes manual installation on any conformant Kubernetes cluster and links a separate guide for other Kubernetes services. Preventing cloud provider lock-in is listed among the platform capabilities.

## Sources

- [License: Apache-2.0](https://github.com/linode/apl-core/blob/main/LICENSE)
- [linode/apl-core on GitHub](https://github.com/linode/apl-core)
- [Project website](https://techdocs.akamai.com/app-platform/docs/welcome)
- [README](https://github.com/linode/apl-core/blob/main/README.md)
- [Releases](https://github.com/linode/apl-core/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/linode-apl-core