# Teaclave: an Apache project that became a landing page for TEE SDKs > Apache Teaclave started as a general purpose secure computing framework and now functions as the central landing page for a set of Rust based SDKs for Intel SGX, Arm TrustZone, a Java TEE SDK and a collection of TEE tailored Rust dependencies. The old FaaS framework survives on a legacy branch and is no longer maintained. **apache/teaclave** — Apache Teaclave™ is an open source universal secure computing platform, making computation on privacy-sensitive data safe and simple. - Repository: https://github.com/apache/teaclave - Website: https://teaclave.apache.org - Stars: 809 · Forks: 155 - Language: Unknown - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/apache-teaclave ## The main branch is a landing page now, not a framework Apache Teaclave is described as an open source universal secure computing platform, making computation on privacy-sensitive data safe and simple. The title of the README is more specific: empowering building memory safe trusted applications in confidential computing. The repository, though, is no longer the place where that code lives. The Repository Status section states plainly that this repository previously hosted the Teaclave FaaS framework, a general purpose confidential computing platform, and that as the community's focus has shifted, the FaaS framework is no longer actively maintained. The legacy code is still reachable. To preserve the project's history and recognise early contributions, the legacy codebase remains available in the deprecated master branch, which has been renamed to legacy. Going forward, this repository serves as the central landing page for the Teaclave ecosystem. What that landing page offers is listed explicitly: a project overview and roadmap, guidance on SDKs for different TEE platforms, showcases demonstrating real-world applications built with Teaclave SDKs, and a unified contribution guide. That is a smaller repository than the name suggests. The root carries .asf.yaml for the Apache infrastructure, .licenserc.yaml for licence header checks, .rustfmt.toml, AGENTS.md, SECURITY.md, NOTICE and LICENSE, plus crates/, docs/, sgx/ and trustzone/ directories and a website-toc.md. The code that is still current is largely in the crates directory, while the sgx and trustzone directories reflect the platform specific pieces of the older framework. ## Four SDKs, and only two of them are the same shape The Teaclave SDK ecosystem is listed as four separate repositories, and they are not variations on one design. The Teaclave SGX SDK is a Rust based SDK for Intel SGX, and the Teaclave TrustZone SDK is a Rust based SDK for Arm TrustZone. Those two carry the load: they are the production-shaped pieces, one per hardware enclave model, and the reason the project describes itself as supporting diverse confidential computing platforms rather than one. The Teaclave Java TEE SDK is described as an experimental Java SDK for TEEs, and the word experimental is doing real work there. A Java developer working in an enclave has to accept that the path is less travelled than the Rust one. The fourth repository, Teaclave Dependency Crates, is a collection of ported and TEE tailored Rust dependencies. This is the piece that is easy to overlook and arguably the most useful. Building inside an enclave constrains what a program can do, and a normal crate that assumes a full operating system will not build there. Rather than making every application author solve that, the project ships a set of dependencies already adjusted for the environment. The README says these SDKs form the foundation for building secure and reliable TEE based applications, and getting started means heading to the SDK repositories, each of which includes installation instructions, documentation and sample code. The official website at teaclave.apache.org carries the wider information, and the repository page adds the roadmap, the guidance per platform and the showcases. ## The old framework is still readable, and explicitly not for new work Keeping the FaaS framework on a legacy branch is the right call, and it is worth understanding what that means for anyone arriving with a specific plan. The framework was general purpose. It was a confidential computing platform in its own right, with a server side model rather than a set of libraries you link into your own program. The SDK model is the opposite: you write the trusted application, and Teaclave gives you the building blocks and the platform specific interfaces to write it in. The reason for the shift, as the README puts it, is how the community naturally adopted and extended the project. People took the parts they needed and used them as the foundation for their own trusted applications, and the ecosystem followed that behaviour rather than the original plan. The result is that the FaaS framework is no longer actively maintained while the SDKs are the live part of the project. The practical consequence for a reader is that the framework is documentation and history rather than a foundation. If your plan is to deploy a confidential function serving platform on top of the FaaS framework, you are building on code the project has stepped away from. If your plan is to write a trusted application that runs inside an Intel SGX or Arm TrustZone enclave, the SDKs are the supported path, and this repository tells you which one to use. One detail worth noting: the branch rename means the old master is now called legacy. Code, articles and internal references that point at master for the FaaS framework are pointing at something that no longer receives work, and the default branch of this repository is main. ## Memory safety is the thread running through every platform The phrase that appears in the README's title and in the opening paragraph is memory-safe trusted applications, and the choice of language follows from it. The two primary SDKs are written in Rust, and the dependency repository is a set of Rust crates. That is a considered position for confidential computing rather than a fashion statement. A trusted application runs in an enclave with a much smaller surface than a normal process, but the code inside it is still code that parses input that an attacker controls. Memory safety removes a class of bugs that an attacker can reach directly, and the Rust SDKs let an application author get that property without rewriting everything in a memory safe language by hand. The platform coverage follows the same logic. Intel SGX and Arm TrustZone are the two models Teaclave supports with production-shaped SDKs, and the SGX and trustzone directories at the root of the repository are the visible trace of the older framework's platform support. A secure computation project that only ran on one hardware model would be a research prototype; one that covers two is a platform. The dependency crates are the quiet part of this story. A TEE tailored dependency is a library adjusted to work inside an enclave, and a collection of them is what turns an SDK into a workable development environment, since an application author should not have to rediscover which crates assume a full operating system. ## Versions, incubation and the licence The release history is short and recent releases are dated 2023. The tags are v0.5.0 on 2023-04-04, v0.5.1 on 2023-05-31 and v0.6.0 on 2023-06-26, and each of those is labelled as an Apache Teaclave incubating release, which is the Apache Software Foundation's designation for a project still on its way towards graduation. The last push to this repository was on 2026-06-10, and the repository is not archived. Since the main branch is now a landing page rather than the framework, that is not surprising: the code that changes often lives in the SDK repositories, which have their own release cycles. The licence is Apache 2.0, with the LICENSE file at the root, the NOTICE file beside it and a .licenserc.yaml for licence header checks. Read those files for the terms that apply, and this is not legal advice. The other governance files are the standard Apache set: .asf.yaml describes the project to the foundation's infrastructure, CONTRIBUTING.md is the contribution guide the README points to, SECURITY.md covers reporting, and CODE_OF_CONDUCT is not in the root listing but the README asks contributors to follow The Apache Way. Community channels are a mailing list on lists.apache.org, a Twitter account and a community page on the project website. The repository also has AGENTS.md, which is the kind of file that has become common in projects where contributors increasingly work with coding assistants, and a .dockerignore that suggests container builds are still part of some workflows. ## Where Teaclave is the wrong choice The first wrong fit is a plan to run the FaaS framework. That framework is on the legacy branch and is no longer actively maintained, and the README says so directly. Building a general purpose confidential function serving platform on it means owning a codebase that the project has moved away from. The second is a Java enclave project that needs production support. The Java TEE SDK is labelled experimental in the README, and an experimental SDK is a research dependency, not a platform decision. The Rust SDKs for SGX and TrustZone are the shapes to plan around. The third is a team that wants a single repository to clone. There is no longer one. The code is spread across four repositories, each with its own releases, and this one holds the roadmap, the guidance and the showcase pages. That is a better arrangement for a multi platform ecosystem, and a worse one for someone who wants a vendor to hand them a tree. The fourth is an evaluation that expects current release numbers to tell you how active the work is. The tags here stop in June 2023, because the versioned artefact was the FaaS framework, and the project has since moved to a model where each SDK is versioned on its own. The last push date and the activity in the SDK repositories are the signals that matter, and this repository is a directory rather than a changelog. Finally, a note about the word universal in the project description. Confidential computing on real hardware still means choosing an enclave model and its vendor, and Teaclave covers two of them well rather than every platform. A project targeting a TEE that is not SGX or TrustZone is outside what this ecosystem covers today. ## Conclusion Teaclave fits a team that wants to build a trusted application on Intel SGX or Arm TrustZone in Rust and needs a starting point that is memory safe by construction, plus a curated set of TEE aware dependencies. It does not fit a team that wants the general purpose FaaS framework that the project used to be, because that code is on a legacy branch and no longer maintained. Before you start, pick the SDK repository for your platform and work from its own installation instructions and samples rather than from this repository. ## FAQ ### What is Apache Teaclave? It is an open source project under the Apache Software Foundation for building memory-safe trusted applications in confidential computing, across platforms including Intel SGX and Arm TrustZone. The main repository is now the central landing page for the ecosystem rather than the code itself. ### Which SDKs does Teaclave provide? The Teaclave SGX SDK for Intel SGX, the Teaclave TrustZone SDK for Arm TrustZone, both written in Rust, an experimental Java TEE SDK, and a collection of Teaclave Dependency Crates holding ported and TEE tailored Rust dependencies. ### What happened to the Teaclave FaaS framework? The repository previously hosted that general purpose confidential computing platform, and as the community's focus shifted the framework is no longer actively maintained. Its code remains available in the deprecated master branch, which has been renamed to legacy. ### How do I start building a trusted application with Teaclave? You head to the SDK repository for your platform, where the installation instructions, documentation and sample code live. The main repository points to those SDKs, and the project website at teaclave.apache.org carries the overview, roadmap and showcases. ### What licence does Teaclave use? The project is licensed under the Apache 2.0 licence, with the LICENSE and NOTICE files at the root of the repository and a .licenserc.yaml for licence header checks. ## Sources - [apache/teaclave on GitHub](https://github.com/apache/teaclave) - [License: Apache-2.0](https://github.com/apache/teaclave/blob/main/LICENSE) - [Project website](https://teaclave.apache.org) - [README](https://github.com/apache/teaclave/blob/main/README.md) - [Releases](https://github.com/apache/teaclave/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-teaclave