Gitpod Classic: what the self-hosted repository still gives you after the rename to Ona

What Gitpod Classic does and who is still supposed to run it

Gitpod Classic is a developer platform that provides on-demand, pre-configured development environments in the cloud. The unit of work is a workspace: an ephemeral, Docker-based Linux environment that behaves like a local Linux machine but is reproducible across a team. Configuration lives in a single .gitpod.yml file in the repository, which is what removes manual environment setup from the onboarding path. The README lists integrations with GitHub, GitLab, Bitbucket and Azure DevOps, plus prebuilt environments, collaborative code reviews, and VS Code extensions.

The audience that remains is narrow, and the README says so plainly. Gitpod has been renamed to Ona, and the README states that the project no longer recommends this version of Gitpod, directing readers to Ona's free tier or enterprise sales instead. It also notes that Gitpod Classic pay-as-you-go sunset on October 15, 2025. So the realistic reader of this repository is someone evaluating the AGPL-3.0 source for self-hosting, or an existing Classic user working out what the code under this name still contains.

How a workspace is built: .gitpod.yml, Docker and prebuilds

The mechanism starts at the repository. A .gitpod.yml file declares how the environment should be constructed, and the platform turns that declaration into a running workspace. Because workspaces are based on Docker, the environment is not a hand-configured VM snapshot; it is a container built from a definition, which is why the same configuration produces the same result for every developer on the project.

The repository layout reflects a fairly large system rather than a single service. Components live under components/, with TypeScript workspaces declared in the root package.json across components/*, components/*/typescript, components/*/typescript-* and components/supervisor/frontend. A components/supervisor directory is visible in that workspace list, which is consistent with the presence of a supervisor process in the architecture. Builds are orchestrated by leeway rather than plain npm scripts: the root build script runs leeway exec --filter-type yarn, and the watch script filters to components:all with transitive dependencies. Operations and install material sit in operations/ and install/, and there is a docs/ directory alongside the external documentation site.

Prebuilds are the part that matters for perceived speed. A prebuilt environment is prepared ahead of the moment a developer opens a workspace, so the cost of installing dependencies is paid before the human is waiting. The README lists prebuilt environments as a feature; it does not document the prebuild scheduling internals, so treat the trigger configuration as something to read in the docs site rather than in this README.

Installing Gitpod Classic from this repository

The README does not contain install steps. It points to www.gitpod.io/docs for all documentation and lists install/ as a top-level directory in the repository, which is where the self-hosting material lives. If you want to run the platform, start there rather than at the README.

For the developer-facing side, the configuration is a file you commit. The README describes workspaces as configured by a .gitpod.yml file, and the repository itself carries one at its root, so you can read a real example rather than invent one. The root package.json shows how the tree is built. The build script delegates to leeway:

yarn build

That runs leeway exec --filter-type yarn --cache-key yarn_build -- yarn build across the workspace packages. The presence of a cache key in the command indicates that build outputs are cached between runs, which matters when you are iterating on a repository this size. The watch script is the other entry point worth knowing:

yarn watch

That runs leeway exec --package components:all --transitive-dependencies --filter-type yarn --components --parallel -- tsc -w --preserveWatchOutput, which recompiles the TypeScript components in parallel as you edit. The README does not document rollback for a bad configuration or a failed build, so test changes on a branch before merging them into a repository that many people open workspaces from.

The rename to Ona and the sunset are the real limitations

The most important limitation is not technical. The README opens by stating that Gitpod has been renamed to Ona and that the project no longer recommends this version, pointing users to Ona's free tier or to enterprise sales. A repository whose own front page tells you to use something else is a maintenance signal you should weigh before you build a workflow on it.

The second limitation is commercial. Gitpod Classic pay-as-you-go sunset on October 15, 2025, per the README's note and the linked sunset post. Anyone who adopted Classic as a hosted service without an enterprise agreement has already been pushed off that path. Self-hosting the AGPL-3.0 code is a different proposition, but it is not the same product experience the hosted service offered, and the README does not describe a migration path from Classic to Ona beyond the two links it gives.

A third constraint is scope. The platform integrates with GitHub, GitLab, Bitbucket and Azure DevOps, and it is built around Docker-based workspaces. If your team does not use one of those forges, or if your build cannot be expressed as a container image and a .gitpod.yml, the product's central abstraction does not apply to you. The README does not describe support for other forges.

Gitpod Classic compared with Dev Container based tooling

The obvious alternative is the Dev Container specification, and the README itself makes the comparison for you: it says that with Ona you gain more powerful development environments than Gitpod Classic with industry-standard specifications based on Dev Container. That sentence is the project's own positioning of its successor against this codebase.

The difference in approach is where the environment definition lives and who executes it. Gitpod Classic defines a workspace through .gitpod.yml and runs it on the Gitpod platform, with prebuilds prepared ahead of time on that platform's infrastructure. Dev Container based tooling defines the environment through a devcontainer.json and is executed by whichever editor or runner supports the specification, which is why the repository carries a .devcontainer/ directory of its own. The trade-off is control versus portability: the Gitpod model gives you a managed prebuild pipeline tied to one platform, while the Dev Container model gives you a definition that other tools can consume. If portability across editors and CI runners is what you need, the specification route fits better. If you want the prebuild behaviour that Gitpod Classic documents, you are choosing the platform-specific path.

Licence, upgrade cost and repository signals

The repository is AGPL-3.0, with LICENSE.md and License.AGPL.txt at the top level. The root package.json is a separate matter: it declares "license": "UNLICENSED" and "private": true, because it is the build parent for the workspace packages rather than a published artifact. If you plan to redistribute anything built from this tree, read the per-package licence files, including License.third-party.go.txt and License.third-party.npm.txt, rather than assuming the root declaration covers everything. This is a description of what the files say, not legal advice.

Upgrade cost is visible in the release history. The most recent releases listed are 2022.11.3, release-2022.11.2 and 2022.11.1, dated 2023-06-05, 2023-03-01 and 2022-12-15. The version scheme is calendar-based, and there has been no release in that series since June 2023. The repository's last push was on 2026-09-21, so commits continue even though tagged releases in this series do not. Anyone pinning to a release tag should expect to be far behind the default branch, and anyone tracking main should expect to build from source with leeway rather than consume a published release.

The dependency picture is also worth reading before you upgrade. The root package.json carries a resolutions block pinning sha.js, @babel/traverse, browserify-sign, cipher-base, elliptic, loader-utils, exec-sh, pbkdf2, tough-cookie, handlebars and websocket-driver. Those pins are there to force transitive dependency versions, and they tell you that keeping this tree current is an ongoing task rather than a one-time install.

Editorial conclusion

Adopt Gitpod Classic only if you are prepared to run the AGPL-3.0 codebase yourself and accept that the README no longer recommends this version for new users. It is the wrong choice if you want a hosted, pay-as-you-go service, since Classic pay-as-you-go sunset on October 15, 2025. Before committing, verify the install path under install/ against your Kubernetes target, confirm how the AGPL-3.0 and UNLICENSED package.json split affects your distribution, and check whether the workspace image you depend on is still published in gitpod-io/workspace-images.

Frequently asked questions

Official sources

1. gitpod-io/gitpod on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases