oracle/apex: where Oracle keeps the starter apps for every APEX release

A sample library, not the platform

The repository description is explicit about what lives here: the official Oracle APEX repository for sample code, starter apps, plug-ins and more. The README repeats the distinction, saying that Oracle APEX is a low-code development platform that lets you build scalable, secure enterprise applications with deploy-anywhere characteristics, and that this GitHub project contains starter apps, sample apps, sample code and plug-ins to use with APEX. That boundary matters, because the name of the repository invites the opposite assumption. Nothing in this repository installs APEX, provisions a database, or contains the runtime. It is a library of things you can look at, copy, and adapt, hosted on GitHub and pointing at apex.oracle.com for the product itself. The audience is APEX developers, in-house teams learning the platform, and consultants who need a working reference application rather than a screenshot in a slide deck.

One branch per APEX version, from 21.1 to 26.2

The branch layout is the most useful thing in the repository, and the README explains the rule in one sentence: these branches contain starter apps, sample apps and so on for a specific version of Oracle APEX. The list runs from the current generation backwards, covering Oracle APEX 26.2, 26.1, 24.2, 24.1, 23.2, 23.1, 22.2, 22.1, 21.2 and 21.1. So the repository carries ten version lines side by side, and a consumer's first decision is which branch to read. That structure is a direct consequence of how Oracle ships APEX: an application exported from a 21.1 environment and an application exported from a 26.2 environment are not interchangeable, and a sample that uses a component introduced in a later release will not run on an earlier one. For a team supporting several APEX versions in parallel, which is common in enterprise environments where upgrades are scheduled over years, the value of the repository is that you can find an example that matches the release you are actually running rather than the newest one.

A separate branch for REST Source Catalogs

One branch does not follow the version scheme at all, and it is worth separating out because it serves a different purpose. The rest-source-catalogs branch contains Fusion Apps REST Source Catalogs, and the README points at it directly rather than listing it among the numbered APEX branches. The reason for the split is structural rather than accidental. A versioned APEX application and a REST Source Catalog are different kinds of artifact, and the catalog branch tracks a separate product line, so a single branch would mix application code for many APEX releases with integration metadata for a different product. The catalog files themselves are the kind of thing that a low-code platform user would otherwise have to author from scratch by hand, describing external REST services and their authentication so that APEX can treat them as first class data sources. A separate branch keeps that content from being tangled into the versioned sample applications, and it also means the two kinds of contribution follow different review paths.

Getting started means asking for a workspace, not cloning a build

There is no command line install in this repository, and the README says so by pointing you elsewhere. The getting started section tells you to get started with APEX and the code samples found in this project by requesting your own workspace on apex.oracle.com, which links to the learning and getting started page. The workflow is therefore a cloud one: you claim a workspace, and from there you work with the APEX environment directly while using the samples in this repository as references to import, extend, and learn from. The project also links to the Oracle APEX online documentation on docs.oracle.com, and the documentation link is the authoritative description of the platform behaviour, since the repository only carries the applications. For the technical side of things, the repository has a docs/ directory at its root, alongside the README, the contribution guide, the security guide, the licence file and a THIRD_PARTY_LICENSES.txt file, which is the signal that some of the samples bundle components under licences other than Oracle's own.

Contributing, reporting issues and the disclosure process

The README sets out three separate channels, and keeping them apart matters if you use this repository. For contributing, the project welcomes community contributions and asks that you review the contribution guide before opening a pull request. For issues, the README asks that you consider reporting them in the Oracle Forums rather than on the issue tracker, which is a reasonable choice for a product support question but means a genuine bug in a sample does not land in the same place as a product defect. For security, the project points to a dedicated security guide for its responsible vulnerability disclosure process, so a vulnerability in a sample app or a plug-in should go through that route rather than a public issue. The existence of SECURITY.md and CONTRIBUTING.md at the repository root, and the Oracle APEX on GitHub page linked in the title, indicate a project that expects external contributions to be run through a review process rather than merged at random.

The Universal Permissive Licence, and what it does to your build

The licensing is the Universal Permissive License v1.0, with the copyright stated as 2021, 2025 Oracle and/or its affiliates, and the licence text referenced on the Oracle open source site. UPL is a permissive licence, so the practical effect is that you can use the sample code and the plug-ins in commercial products without a copyleft obligation, and without paying Oracle for the use. The one thing to watch is the THIRD_PARTY_LICENSES.txt file in the repository root. When samples bundle libraries or assets that were not written by Oracle, those components carry their own terms, and the file is the place where the exceptions are recorded. A team copying a sample into a shipped application should read that file, because the permissive licence covering the Oracle-authored code does not automatically extend to everything a sample pulls in. The repository itself publishes no GitHub releases, so there is no versioned artefact to download; you take content from a branch, and the branch you take it from is the version statement.

Where this repository is the wrong place to look

The limits follow from the scope. If you want to evaluate whether APEX fits your problem, this repository cannot answer that, because it contains applications rather than the platform, so the decision has to be made against the product documentation and your own trial workspace. If you need a specific integration and find nothing in the samples, the answer is not to write a plug-in against this repository's structure, because a plug-in is deployed into an APEX environment and lives in a different repository from the sample apps, with its own extension points. And if you are on an APEX release older than 21.1, the oldest branch here is 21.1, so the version coverage stops there. The reasonable alternative for a team that wants reference code is the sample applications that ship inside a proprietary APEX installation, which are closer to the version you run, whereas the advantage of this repository is the history: because older versions stay on their own branches, you can see how a pattern was solved two or three APEX generations ago and how the current version expects it to be solved now.

Editorial conclusion

Adopt the oracle/apex repository as a source of reference applications and plug-ins when you build on Oracle APEX and want to start from a working example on the same release you deploy. Do not treat it as the platform, since nothing here installs APEX, and do not mix branches, because the apps on the 21.1 branch and the 26.2 branch target different product versions. Verify first which APEX version you run, and read the security guide before opening a pull request, since the project has a formal vulnerability disclosure process.

Frequently asked questions

Official sources

1. Issues
2. License: UPL-1.0
3. oracle/apex on GitHub
4. Project website
5. README