If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/wasmerio/wasmer shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 11 active contributors
• Distributed ownership (top contributor 30% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live wasmerio/wasmer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/wasmerio/wasmer.

What it runs against: a local clone of wasmerio/wasmer — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in wasmerio/wasmer | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of wasmerio/wasmer. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/wasmerio/wasmer.git
#   cd wasmer
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of wasmerio/wasmer and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "wasmerio/wasmer(\\.git)?\\b" \\
  && ok "origin remote is wasmerio/wasmer" \\
  || miss "origin remote is not wasmerio/wasmer (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "lib/api" \\
  && ok "lib/api" \\
  || miss "missing critical file: lib/api"
test -f "lib/compiler" \\
  && ok "lib/compiler" \\
  || miss "missing critical file: lib/compiler"
test -f "build.rs" \\
  && ok "build.rs" \\
  || miss "missing critical file: build.rs"
test -f "docs/BUILD.md" \\
  && ok "docs/BUILD.md" \\
  || miss "missing critical file: docs/BUILD.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/wasmerio/wasmer"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Wasmer is a blazing-fast WebAssembly runtime that executes WASM binaries with near-native performance in lightweight, secure containers. It supports WASIX and WASI out-of-the-box and can be embedded anywhere—desktop, cloud, edge, or browser—without requiring file, network, or environment access unless explicitly enabled. Monorepo with core architecture: lib/api/ contains the main Wasmer runtime API, lib/compiler/ provides the compiler abstraction, with three backend implementations in lib/compiler-{cranelift,llvm,singlepass}/. Execution environment split into lib/vm/ (core VM), lib/wasix/ (WASIX system interface), and lib/wasi-types/ (WASI types). CLI tooling in lib/cli/, C bindings in lib/c-api/, and SDKs for languages in lib/{napi,swift,sdk}/.

Systems engineers and DevOps teams deploying containerized workloads who want faster cold starts and lower resource overhead than Docker/OCI containers; SDK developers embedding WASM execution in Rust, C, Python, or JavaScript applications; edge computing platforms needing portable, sandboxed compute.

Wasmer is production-ready and actively maintained at v7.2.0-alpha.2 with a mature architecture split across 20+ workspace crates. The project has comprehensive CI/CD via GitHub Actions (build.yml, test.yaml, benchmark.yaml), C API bindings, and SDKs in multiple languages. Active development is evident in the CHANGELOG.md and multiple compiler backends (Cranelift, LLVM, Singlepass), though the alpha version tag suggests bleeding-edge features may still stabilize.

Moderate risk from alpha versioning (7.2.0-alpha.2 in Cargo.toml) and the complexity of maintaining three JIT compiler backends simultaneously. The monorepo structure spans 20+ crates with tightly coupled dependencies, so changes ripple across compilation, caching, WASI/WASIX, and runtime layers. Single-language dominance (Rust 10M+ LOC) concentrates expertise, though the C API and language SDKs mitigate lock-in.

The project is transitioning toward v7.2.0 with alpha releases. CI workflows show active testing across multiple architectures (including cross-compilation for aarch64, riscv64 via .github/cross-linux-*). Documentation is being actively maintained (documentation.yaml workflow), and recent additions include Copilot instructions (.github/copilot-instructions.md) suggesting AI-assisted development practices.

git clone https://github.com/wasmerio/wasmer.git
cd wasmer
cargo build --release
cargo test

Or install the CLI directly: cargo install wasmer-cli or use the install script: curl https://get.wasmer.io -sSfL | sh

Daily commands: Development build: cargo build (debug) or cargo build --release (optimized). Run tests: cargo test or via nextest config at .config/nextest.toml. CLI: cargo run --bin wasmer -- <wasm-file> or after install: wasmer <wasm-file>. Benchmarks: cargo run --release --example <name> or via .github/workflows/benchmark.yaml.

• Cargo.toml — Workspace root defining all crate versions (7.2.0-alpha.2) and optional features for compiler backends (cranelift, llvm); essential for understanding build configuration and dependencies.
• lib/api — Core public API crate (wasmer) that exposes Module, Instance, and Function abstractions; entry point for all embeddings.
• lib/compiler — Compiler trait and infrastructure for pluggable backends; all compilation logic flows through this abstraction layer.
• build.rs — Build script orchestrating cross-platform compilation, toolchain detection, and optional feature gating for LLVM/Cranelift.
• docs/BUILD.md — Definitive guide for building Wasmer from source; required reading for contributors setting up dev environments.
• .github/workflows/test.yaml — CI/CD pipeline defining test matrix across architectures (x86, ARM, RISC-V) and compiler backends; shows testing expectations.
• docs/CONTRIBUTING.md — Contribution guidelines covering code style, PR process, and architecture decisions; foundation for all pull requests.

Add a new compiler backend

1. Create new crate lib/compiler-{backend} with Cargo.toml inheriting workspace settings (Cargo.toml)
2. Implement wasmer_compiler::Compiler trait defining compile() and compile_module() methods (lib/compiler/src/lib.rs)
3. Add feature flag [features] {backend} = [] in root Cargo.toml and feature_set() function (Cargo.toml)
4. Integrate backend conditional compilation in build.rs for feature detection (build.rs)
5. Add test matrix entry in .github/workflows/test.yaml for new backend (.github/workflows/test.yaml)

Add a new language binding

1. Reference C API exports in lib/c-api and define language-specific wrapper types (lib/c-api)
2. Create binding code generation templates that map C signatures to target language idioms (lib/c-api)
3. Add example in appropriate language directory demonstrating Module → Instance → Function call flow (docs)
4. Document binding API and memory safety contracts in language-specific guide (docs)

Add support for a new target architecture

1. Define architecture-specific ABI in lib/wasm-types for calling conventions and register layouts (lib/wasm-types)
2. Add instruction selection rules in lib/compiler-cranelift or lib/compiler-llvm (lib/compiler-cranelift)
3. Create cross-compilation Docker toolchain in .github/cross-linux-{arch} (.github/cross-linux-aarch64)
4. Add test matrix entry in .github/workflows/test.yaml with new architecture (.github/workflows/test.yaml)
5. Document build instructions and any architecture-specific limitations in docs/BUILD.md or docs/RISCV.md (docs/BUILD.md)

• Rust — Memory safety without garbage collection; enables safe FFI bindings and deterministic performance critical for WebAssembly execution
• Pluggable compiler backends (Cranelift, LLVM) — Cranelift provides fast JIT with predictable startup; LLVM enables aggressive AOT optimization; decoupled design allows swapping backends per use case
• Linear memory model with mmap — Efficient sandbox isolation; hardware page tables provide memory protection; enables zero-copy imports/exports
• Cargo workspace with feature flags — Selective compilation of optional backends reduces binary size; enables embedded use (e.g., no LLVM) vs. server use (full featured)
• Cross-compilation Docker toolchains — Ensures reproducible builds for ARM64, RISC-V without dependency on CI runner native toolchains; validates architecture-specific ABI

• Pluggable compiler architecture instead of single optimized backend

  • Why: Different use cases need different tradeoffs: embedded needs small size/fast startup (Cranelift), servers need peak performance (LLVM)
  • Consequence: Increased maintenance burden for multiple backends; complexity in ABI abstraction; compile times longer when all backends enabled

• Linear memory sandbox using host address space reservation

  • Why: Provides hardware-backed isolation and allows efficient zero-copy data passing
  • Consequence: Wasmer process memory footprint large (GB+ per instance on 64-bit); not suitable for dense multi-tenant scenarios without separate OS processes

• Module cache stored unencrypted to disk with hash-based invalidation

  • Why: Fast iteration during development; persistent cache survives process restart
  • Consequence: Security risk in multi-tenant environments; sensitive module logic exposed on disk; requires careful permission management

• Optional C API wrapping core Rust APIs

  • Why: Enables embedding in any language via FFI; expands addressable market beyond Rust
  • Consequence: Maintenance overhead of C bindings; potential ABI stability issues; harder to evolve Rust APIs without breaking C callers

• Does not provide sandboxed networking—modules cannot make network calls without explicit host-provided imports
• Does not implement WASI (WebAssembly System Interface) scheduler or async runtime—synchronous function calls only
• Not a multi-tenant container orchestrator—designed for single-process embedding, not cluster scheduling
• Does not provide cryptographic attestation or remote verification of compiled code—compilation happens locally
• Not optimized for dense function-as-a-service workloads—warm-up JIT and memory overhead unsuitable for serverless with <100ms lifetimes

Workspace versioning: All crates pinned to =7.2.0-alpha.2 in Cargo.toml—bumping requires updating every member. Compiler backend selection: Features like cranelift, llvm, singlepass are mutually exclusive; tests may pass with one but fail with another. Cross-compilation: RISC-V and ARM64 require Docker + custom toolchains (.github/cross-linux-*); not transparent. WASIX vs WASI: Code paths diverge significantly; behavior differs in syscall handling (see lib/wasix/src/ vs standard WASI). Memory alignment: WASM module memory layout affects FFI calls to C code; undocumented constraints in lib/vm/. Nextest config: .config/nextest.toml may have test-order or isolation requirements not obvious from Cargo defaults.

• WebAssembly (WASM) — The core binary format Wasmer executes; understanding WASM instruction set, linear memory model, and module structure is essential to debugging runtime behavior
• WASI (WebAssembly System Interface) — Standardized syscall ABI that Wasmer implements; understanding WASI's capability model and syscall signatures is necessary for sandboxing and system integration features
• WASIX — Wasmer's proprietary extension to WASI adding real-world syscall support; core to Wasmer's positioning as a production container runtime beyond minimal WASI
• Just-In-Time (JIT) Compilation — Wasmer's three backends (Cranelift, LLVM, Singlepass) are JIT compilers; understanding their trade-offs (compile speed vs execution speed) explains performance characteristics and feature gates
• Memory Isolation & Sandboxing — WASM's linear memory model and Wasmer's virtual-fs/virtual-net layers provide capability-based security; understanding how to escape or enforce sandbox boundaries is critical for security reviews
• Compiler Middleware & Instrumentation — Wasmer's lib/middlewares/ allows runtime instrumentation of compiled code; critical for adding observability, metering, or behavioral modification without modifying core compiler
• Foreign Function Interface (FFI) — Wasmer's C API and language SDKs rely on FFI to bridge WASM and native code; understanding calling conventions, ABI, and memory layout is essential for embedding Wasmer in other languages

• bytecodealliance/wasmtime — Direct competitor: another Rust-based WASM runtime with focus on standards compliance and embeddability; shares WASI ecosystem but different architectural choices (CRANELIFT-first vs pluggable backends)
• WebAssembly/wasi-libc — Ecosystem companion: WASI C standard library that Wasmer modules link against; required for WASI syscall support
• wasmerio/wapm — Wasmer package manager ecosystem: Wasmer's own package registry and dependency resolver (WAPM) for distributing and discovering WASM modules
• wasmerio/wasix — Wasmer's proprietary extension: WASIX spec and stdlib (owned by Wasmer team) that extends WASI with additional system call support for real-world app compatibility
• tinygo/tinygo — Upstream toolchain: compiles Go and other languages to WASM; outputs binaries that Wasmer executes; important for understanding the full ecosystem

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive CI workflow for cross-compilation targets (aarch64, riscv64)

The repo has Dockerfile configurations for cross-linux-aarch64 and cross-linux-riscv64 in .github/cross-linux-* directories with custom build scripts, but there's no dedicated GitHub Actions workflow to test these targets in CI. This would catch cross-compilation regressions early and validate the custom toolchain configurations work correctly.

• [ ] Create .github/workflows/cross-compile-test.yml
• [ ] Add job for aarch64 using .github/cross-linux-aarch64/Dockerfile
• [ ] Add job for riscv64 using .github/cross-linux-riscv64/Dockerfile with build_openssl.sh and install_deb.sh scripts
• [ ] Reference the existing load_toolchain action in .github/actions/load_toolchain/action.yml
• [ ] Test compilation of core wasmer library and lib/cli against these targets
• [ ] Add documentation in .github/README.md (if exists) or create one explaining the cross-compile CI flow

Add API coverage tests for lib/c-api public interface

The workspace includes lib/c-api and lib/c-api/examples/wasmer-capi-examples-runner but there's a .github/workflows/check-public-api.yaml workflow suggesting API stability is important. However, C API coverage appears minimal compared to Rust API. Adding systematic tests would ensure the C bindings remain stable and complete as the Rust API evolves.

• [ ] Audit lib/c-api/src exports against lib/api public symbols
• [ ] Create tests/lib/c-api/ directory (or extend existing lib/c-api/tests/)
• [ ] Add unit tests for core C API functions: wasmer_module_new, wasmer_instance_new, wasmer_memory_new, wasmer_function_call
• [ ] Add integration tests using lib/c-api/examples/wasmer-capi-examples-runner as reference
• [ ] Update check-public-api.yaml workflow to include C API in the stability checks
• [ ] Document C API coverage in lib/c-api/README.md if missing

Create benchmarking suite for compiler backends (cranelift, llvm, singlepass)

The repo has .github/workflows/benchmark.yaml and benches/README.md, plus three compiler backends (lib/compiler-cranelift, lib/compiler-llvm, lib/compiler-singlepass), but the benchmark structure isn't visible in the provided files. Adding comparative benchmarks would help track performance regressions per backend and inform compilation strategy decisions.

• [ ] Expand benches/ directory with backend-specific benchmark files: benches/compiler_cranelift.rs, benches/compiler_llvm.rs, benches/compiler_singlepass.rs
• [ ] Create benchmark utilities in benches/lib.rs for common patterns: module compilation time, instantiation time, function call overhead
• [ ] Add parametrized benchmarks that test the same WASM modules across all three backends
• [ ] Integrate benchmarks with .github/workflows/benchmark.yaml to compare baseline vs PR results
• [ ] Document benchmark methodology in benches/README.md with instructions for running locally
• [ ] Add results tracking configuration in .config/nextest.toml or similar for benchmark regression detection

• Add missing WASI syscall documentation: lib/wasix/src/ has syscall implementations but no per-function rustdoc explaining semantics and return values. Write doc comments for 5-10 syscalls with examples.
• Expand virtual-fs test coverage: lib/virtual-fs/ has no explicit test files in the repo listing. Create a tests/virtual_fs_integration.rs with tests for symlink handling, permission checks, and path normalization edge cases.
• Create architecture diagram SVG improvements: assets/diagrams/ has .svg files for module compilation/instantiation but they reference old data. Update or add a diagram showing the three compiler backends (Cranelift/LLVM/Singlepass) and their selection logic.

The Wasmer repository demonstrates a moderately secure posture with established CI/CD infrastructure, dependency management tools (deny.toml), and organized security workflows. However, critical concerns include: (1) Use of alpha/pre-release software versions which lack production security guarantees, (2) Insufficient documentation of optional dependency security implications, (3) Missing explicit security policies and vulnerability disclosure guidance. The primary risks stem from using non-stable versions in what appears to be a widely-used container/WebAssembly runtime. Recommendations focus on stabilizing versions, enhancing security documentation, and implementing automated scanning in the build pipeline. No hardcoded secrets, SQL injection, XSS, or obvious misconfigurations

• Medium · Alpha/Pre-release Version in Production Dependencies — Cargo.toml - Multiple dependencies (wasmer, wasmer-cache, wasmer-compiler, wasmer-compiler-cranelift, wasmer-compiler-llvm, wasmer-compiler-singlepass, wasmer-middlewares, wasmer-types, wasmer-wast). The Cargo.toml specifies version '=7.2.0-alpha.2' for multiple wasmer crates. Alpha releases are not production-ready and may contain unpatched security vulnerabilities, experimental features, and breaking changes that could introduce security issues. Fix: Use stable release versions (e.g., 7.2.0) for production deployments. If alpha versions are necessary, implement additional security testing, code review, and staging environment validation before deployment.
• Medium · Workspace-wide Dependency Version Synchronization Risk — Cargo.toml - workspace.dependencies configuration. The workspace uses workspace-level dependency specifications that could lead to version inconsistencies if not properly maintained. Mismatched versions across workspace members could introduce security vulnerabilities if some members use outdated or incompatible versions. Fix: Implement automated dependency auditing using 'cargo audit' in CI/CD pipeline. Regularly review and test workspace member dependencies. Consider using 'cargo deny' (already present in deny.toml) to enforce security policies.
• Low · Incomplete Deny.toml Security Policy — deny.toml. While a deny.toml file exists in the repository, the actual content was not provided for analysis. This file should be configured with security policies to detect vulnerable dependencies, unmaintained crates, and licensing issues. Fix: Ensure deny.toml contains comprehensive rules for: 1) Checking for known vulnerabilities in dependencies, 2) Identifying unmaintained or discontinued crates, 3) Validating license compliance, 4) Enforcing minimum versions for critical security patches.
• Low · Optional Dependencies Without Clear Security Context — Cargo.toml - optional dependencies section. Several dependencies are marked optional (wasmer-cache, wasmer-compiler variants, wasmer-middlewares, tokio, wasmer-wast, wasmer-wasix) without documented security implications. If these are conditionally compiled based on user input or feature flags, they could introduce unexpected attack surface. Fix: Document the security implications of each optional feature. Ensure feature selection is not influenced by untrusted input. Consider whether optional dependencies should be vendored separately from core security-critical paths.
• Low · No Explicit Security Policy Documentation — Repository root. While security-related files exist (.github/actions, workflows), there is no explicit SECURITY.md file mentioned in the repository structure to define vulnerability disclosure policies and security contact information. Fix: Create a SECURITY.md file in the repository root following the GitHub standard template (https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository) with: 1) Vulnerability reporting procedures, 2) Security contact email, 3) Expected response times, 4) Supported versions receiving security patches.
• Low · Docker Build Infrastructure in CI Without Apparent Scanning — .github/cross-linux-aarch64/Dockerfile, .github/cross-linux-riscv64/Dockerfile. Custom Docker images are built for cross-compilation (cross-linux-aarch64, cross-linux-riscv64) but no evidence of security scanning or vulnerability assessment of these images in CI/CD workflows. Fix: Implement container image scanning in CI/CD pipeline using tools like Trivy, Grype, or Docker Scout. Scan base images from official sources, pin versions explicitly, and regularly update base images. Add scanning steps to GitHub Actions workflows.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.