The Linode manager repository is the Cloud Manager UI and the packages it is built from

A vendor front end with its whole source tree published

Cloud Manager is the web interface you log into to manage Linode services: instances, storage, networking, and the account settings around them. The repository description calls it an open source single page application serving as the official UI for interacting with the Linode API, and it is served at cloud.linode.com.

Why would a hosting provider publish that? The answer visible in the repository is that it is a monorepo, and the reusable pieces inside it are published as standalone npm packages. The README lists the Cloud Manager itself and seven related TypeScript packages, each in its own directory under packages: @linode/api-v4, @linode/queries, @linode/search, @linode/shared, @linode/ui, @linode/utilities and @linode/validation.

So there are two very different things here. One is a React application that belongs to Akamai and is really the product. The other is a set of libraries, some of them published to npm for anyone to use, some of them internal to the interface.

The primary language is TypeScript, the licence is Apache 2.0, and the default branch is develop. The repository is not archived, and the last push was on 2026-04-23. Recent releases are Cloud Manager v1.161.0 on 2026-03-27, v1.160.0 on 2026-03-13 and v1.159.1 on 2026-03-02, published under the tag pattern [email protected].

For an engineer deciding whether to use this project, the useful question is which of the two things you want. Nobody should be forking the vendor's dashboard. A fair number of teams should be depending on the API client.

Seven packages, and only one of them is the application

The package list explains the architecture better than any description would.

@linode/api-v4 is the API client, named for version 4 of the Linode API. It carries its own version badge on npm and a bundlephobia badge for its bundle size, which tells you it is published and tracked as a consumable library rather than as application code. @linode/validation is published the same way, with the same pair of badges, and the name suggests what it holds: the rules for what a valid request or resource looks like.

The remaining packages are named for what they do inside the interface. @linode/queries is the query layer, @linode/search is search, @linode/shared holds code shared across packages, @linode/ui is the component library, and @linode/utilities is the grab bag of helpers. The topics on the repository list tanstack-react-query and tanstack-router alongside reactjs, which describes the data layer and the routing layer of the application itself.

The build order in the root scripts shows the dependency direction. The validation package is built first, then the SDK:

    "build:sdk": "pnpm run --filter @linode/api-v4 build",
    "build:validation": "pnpm run --filter @linode/validation build",
    "build": "pnpm build:validation && pnpm build:sdk && pnpm --filter @linode/cloud-manager build",
    "bootstrap": "pnpm install:all && pnpm build:validation && pnpm build:sdk",

The application is built last, after the two libraries it consumes. That ordering is the practical argument for the monorepo: the shared pieces are compiled before the app, so the interface always runs against the current version of the client rather than a published one.

The workspace uses pnpm, with a pnpm-lock.yaml and a pnpm-workspace.yaml at the root, and the root package.json is marked private and of type module.

Bootstrapping the workspace locally

The README does not give the local setup steps inline. It points to a getting started guide hosted at linode.github.io/manager/GETTING_STARTED.html, and to the contributing guidelines at linode.github.io/manager/CONTRIBUTING.html for the first pull request. Bug reports and feature requests go through GitHub issues on the repository, and general feedback through linode.com/feedback.

What the repository does show is the shape of the workflow. The install step is pinned to the lockfile, which is what you want in a workspace with several interdependent packages:

    "lint:all": "pnpm -r --parallel lint",
    "install:all": "pnpm install --frozen-lockfile",

The dev script runs the packages in parallel with the concurrently tool, giving each one a name and a colour, and the set of names is itself a summary of the monorepo: api-v4, validation, ui, utilities, queries, shared and manager. There is also an up:expose variant that sets the pnpm package import method to clone-or-copy before installing and building, for cases where the default linking approach does not work on the platform.

Two other files tell you how the project is policed. A .husky directory means git hooks are installed on checkout, and lint-staged with prettier and eslint in the dev dependencies suggests formatting is enforced at commit time rather than in review. The .nvmrc file pins the Node version, which is one of those small details that saves an afternoon when two people get different results from the same command.

Cypress end to end tests and the environment they need

The repository contains a docker-compose.yml whose entire purpose is running the end to end suite, and it is unusually well documented inline. The compose file defines an anchor for environment variables shared by every Cypress runner, and the comments explain why each one exists.

Some are CI plumbing, such as the build information used for the Cypress Dashboard:

  CYPRESS_BASE_URL: ${CYPRESS_BASE_URL}
  CYPRESS_PULL_REQUEST_ID: ${CHANGE_ID}
  CYPRESS_PULL_REQUEST_URL: ${CHANGE_URL}
  CYPRESS_RECORD: ${CYPRESS_RECORD}
  CYPRESS_RECORD_KEY: ${CYPRESS_RECORD_KEY}

Others are Cloud Manager specific and worth reading before you try to run the suite yourself, because they show how the test environment is shaped:

  CY_TEST_SUITE: ${CY_TEST_SUITE}
  CY_TEST_REGION: ${CY_TEST_REGION}
  CY_TEST_FEATURE_FLAGS: ${CY_TEST_FEATURE_FLAGS}
  CY_TEST_TAGS: ${CY_TEST_TAGS}
  CY_TEST_DISABLE_RETRIES: ${CY_TEST_DISABLE_RETRIES}

A configurable test suite, a target region, feature flags, tags, and a switch to disable retries are exactly the knobs you need when the suite runs against real infrastructure, which it does, since this is an interface for real accounts. The commit information variables carry a comment explaining that Cypress cannot retrieve it automatically from inside the container because of file ownership differences, which is the kind of detail that would otherwise cost an hour.

Alongside the compose file, the repository has Jenkinsfile-playwright.groovy and two other Jenkins pipelines, including one for component tests, so the end to end work is not confined to Cypress.

A design system, a docs site and a coverage badge

The README badges are a map of the supporting infrastructure. There is a code coverage badge served from a Linode objects bucket, a CI build stats badge pointing at the GitHub Actions workflow on the develop branch, a version badge that reads packages/manager/package.json, and a Storybook badge linking to design.linode.com.

That last one is worth a paragraph of its own. The @linode/ui package and the Storybook deployment together mean the interface has a published component library with living documentation, and the design site is a separate address rather than a page inside the application. For a team that contributes to this project, that is where you find out what a button is supposed to look like before you add another one.

The documentation itself lives in the repository under docs and is published as a GitHub Pages site under linode.github.io/manager, with the getting started and contributing guides as the two pages a newcomer is pointed at.

The broader point is that this is a large, professional codebase with the full apparatus of one: a CODEOWNERS file, a SECURITY.md, a sonar-project.properties file for static analysis, a vitest.config.ts for unit tests, a CHANGELOG.md, and a .github directory for the workflows. The interface is the visible product, but the repository is the engineering organisation around it.

Licence, releases and who the repository is actually for

The licence statement is short and unambiguous. All code in the repository is distributed under the terms of the APLv2 licence, with the text in the LICENSE file, and the root package.json records the same thing as Apache-2.0. The npm packages carry the same terms, so the client library you install from the registry is under the same permissive licence as the source.

That is the fact that makes the packages interesting to reuse. The interface itself is a vendor product and the licence does not make it yours to reshape; the API client is a different matter, because a permissive licence plus a published package plus a named version means you can pin it, depend on it and upgrade it deliberately.

The release pattern shows a product shipping frequently. Three releases in March 2026, on the 2nd, the 13th and the 27th, and the version in the badge is taken from the package manifest rather than typed into the badge URL by hand. The default branch is develop, and the CI badge is configured for that branch, which is the usual convention where develop is the integration branch and releases are cut from it.

The last push was on 2026-04-23, a little over a month after the v1.161.0 tag. There is no separate changelog entry per release in the README, so the CHANGELOG.md file and the release notes are where the detail lives.

Where this repository is the wrong tool

The obvious wrong case is treating Cloud Manager as a starting point for your own dashboard. It is the official interface for one specific hosting provider's API, it is bound to that provider's account model, and it is written to that company's product priorities. Forking it gives you a large React codebase to keep in step with a moving upstream, and the value you take from it is mostly the visual layer.

The second wrong case is assuming the packages are all for you. @linode/queries, @linode/search, @linode/shared, @linode/ui and @linode/utilities exist to serve the interface, and only @linode/api-v4 and @linode/validation carry version badges in the README, which points to them being the published ones. If you take a dependency on an internal package, you are depending on a package that exists to make the vendor's app work, with versioning and support that are not promised to you.

The third is a general purpose multi-cloud console. The API client speaks to one provider's API. If your requirement is to manage more than one cloud from one place, the package that talks to one provider is the wrong foundation, whatever its quality.

The honest alternative for the same goal, building a Linode integration, is to depend on @linode/api-v4 and @linode/validation and write the parts specific to your own product. You get the official client's request handling, types and validation, you pin versions yourself, and you avoid inheriting a dashboard's opinions about layout, navigation and workflow.

Editorial conclusion

Adopt @linode/api-v4 or @linode/validation if you are building against the Linode API and want the official TypeScript client with its types and validation rules, since both are published on npm independently of the interface. Do not adopt the Cloud Manager application itself as a starting point for your own product, since it is the vendor's official interface, is bound to Linode account data, and carries its own product priorities. Before you build on the client package, check its published version and the API it targets, and read the getting started guide at linode.github.io/manager/GETTING_STARTED.html for the local setup, since the repository's last push was on 2026-04-23 and the release tags trail that by about a month.

Frequently asked questions

Official sources

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