dfinity/examples is a map of the Internet Computer, not a library

A repository you clone rather than a package you install

dfinity/examples is not a library and not a service. It is a catalogue of sample applications, microservices and code samples for the Internet Computer, and the entry point in the documentation is explicit about how you use it: from this repository you can deploy, download, clone, fork or share sample projects.

The framing matters because the artefacts inside are canisters, the WebAssembly units that run on the Internet Computer, together with the frontends and native apps that talk to them. There is no import statement to add and no version to pin. You take a directory, you read its documentation, and you deploy it.

The repository says outright that the projects are not intended to be used as commercial applications and do not provide any explicit or implied support or warranty of any kind. That sentence is the single most useful line in the documentation for a new reader, because it sets the expectation that these are teaching artefacts maintained by example rather than a supported dependency.

If you are starting a new project from scratch rather than learning from an example, the documentation points you elsewhere, to a separate templates repository scaffolded with the `icp new` command.

Organised by language, then by client type

The layout has two levels, and the second level tells you what kind of thing you are building.

Canister examples are grouped by language, with a motoko directory and a rust directory. Then there are three directories for everything that is not a plain canister. hosting holds frontend examples such as React and static sites. native-apps holds Unity and other native app integrations. wasm holds canisters written directly in WebAssembly rather than through a systems language.

That split is the fastest way to navigate if you already know what you are building. Someone wiring up a browser frontend to a canister goes to hosting, someone embedding a canister call in a game goes to native-apps, someone who wants to bypass the Rust and Motoko toolchains goes to wasm.

The repository root also holds a .devcontainer directory, an AGENTS.md and a CLAUDE.md, a .claude directory and a NOTICE file, which tells you the shape of the tooling around the samples before you read a single example.

hello_world first, then who_am_i and Internet Identity

The documentation gives a reading order for newcomers, and it is worth following rather than browsing. Start with hello_world, available in both Motoko and Rust, described as a simple full-stack canister with a frontend. Then move to who_am_i, also in both languages, which adds user authentication with Internet Identity.

That progression is well chosen. hello_world teaches the shape of a project: a canister, a frontend, and the local deployment loop. who_am_i adds the thing that every real application on this platform eventually needs, an authentication flow, without adding anything else to obscure it. Internet Identity is the platform's own authentication service, and the example is linked to the platform documentation for it.

Because each example is its own directory with its own readme, you can pick up one example and ignore the rest of the catalogue. The documentation frames it that way, telling you to follow the example's own documentation to deploy, rather than giving a single set of instructions for the whole repository.

The releases show the same structure. The two most recent tagged releases are named for one Rust example, rust/basic-bitcoin, with tags dated 2025-10-10 and 2024-09-16, so individual samples are versioned independently, the way a monorepo of independent projects would be.

The toolchain split between Motoko and Rust

Local development needs different tools depending on the example, and the documentation lists them as prerequisites.

The common base is Node.js on the LTS line and icp-cli, installed globally along with the ic-wasm package using the npm install -g command on @icp-sdk/icp-cli and @icp-sdk/ic-wasm. Motoko examples additionally need mops, the Motoko package manager, installed globally with npm install -g ic-mops. Rust examples need a Rust toolchain from rustup plus the WebAssembly target added with rustup target add wasm32-unknown-unknown.

Then you clone the repository and move into the example directory.

git clone https://github.com/dfinity/examples.git
cd examples/<language>/<example>

The platform specific installation instructions live in the full installation guide for the CLI, and the documentation notes that the CLI's own guide is versioned, which matters if you are following an older tutorial that names a different tool than the one the examples now expect.

Dev Containers keep the Motoko and Rust toolchains together

The repository offers a second path for local development: a Dev Container. Opening the repo root in VS Code with the Dev Containers extension gives a pre-configured environment with the full ICP toolchain for both Motoko and Rust, and VS Code prompts to reopen in the container automatically.

git clone https://github.com/dfinity/examples.git

The one instruction that will save you an afternoon is the note attached to it: open the repo root in the container, not an individual example subfolder. The container is configured at the root because the toolchain spans the whole workspace, and starting from a subfolder is the way people end up with a partially configured environment.

After the container is up, you navigate into an example and follow its own documentation, exactly as in the command line path. The two routes converge on the same place, which is the right design: the container is a convenience for getting the same prerequisites that the documentation lists, without a mismatch between what a tutorial says and what you have installed.

Samples built to be read by coding agents

One of the more distinctive things about this repository is that it is explicitly designed to be consumed by AI coding agents. The documentation says the examples are built to work well with them, backed by what it calls ICP skills: tested, frequently updated instructions meant to keep an agent aligned with a platform that moves quickly.

The mechanism is a SessionStart hook. The repository is set up with autosync, and opening it in Claude Code runs a hook that keeps the skills current automatically, with a trust prompt the first time. The documentation is clear that this targets Claude Code today, and that other agents fetch the skills on demand instead. The skills themselves are browsable at skills.internetcomputer.org, and the AI coding agents guide on the platform documentation site explains how agents consume and install them.

The details are in AGENTS.md, which explains the setup. CLAUDE.md at the root is the agent instruction file for the Claude Code case.

This is a meaningful shift in how a samples repository is maintained. Instead of a README drifting out of date, an agent reading the repository is handed current instructions about the platform it is writing code for. For a human reader it is also a signal about how the samples are expected to age.

What the samples are not guaranteed to do

The security section at the end is short and pointed. If you build an application on one of these examples, the documentation says you should familiarise yourself with and follow the platform's security best practices, and it warns that the examples provided here may not implement all of them.

That is the real limitation of this repository, and it is a deliberate one. These samples optimise for teaching the shape of a project, showing a pattern you can copy, and demonstrating a deployment path. They do not claim to be hardened. The repository's own wording, that the samples are not intended as commercial applications and come with no warranty, is consistent with that.

So the sensible use is to treat each example as a starting point you own once you copy it: read it, understand what it does, and apply the platform's security guidance to it before it carries anything real.

The last push was on 2026-09-28 and the repository is not archived. The licence is Apache-2.0, which is permissive enough that you can copy an example into a proprietary product without worrying about copyleft, which is exactly the case the samples are meant to support.

Editorial conclusion

dfinity/examples fits a developer who wants a working reference for Internet Computer development rather than a library to depend on, since each sample ships with its own README and its own deployment instructions and the repository is explicitly framed as a set of examples to deploy, clone, fork or share. It does not fit a production service, because the project states the samples are not intended for commercial use and carry no support or warranty, and it does not fit a team that wants a single reusable component. Before basing a project on one of these samples, read the security best practices guide for the platform, since the documentation warns the examples may not implement all of them, and check the toolchain the sample expects, which for the Rust examples means the wasm32-unknown-unknown target and for the Motoko examples means mops.

Frequently asked questions

Official sources

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