FAQ

What languages does Peppy support?

Peppy supports Rust and Python. The daemon and tooling are built in Rust; nodes in either language use the same peppy.json5 interfaces through the generated peppygen code and the peppylib runtime.

What tech are you using under the hood?

Peppy is written in Rust. Nodes communicate over Zenoh, messages are encoded with Cap’n Proto, and container nodes run on Apptainer (with Lima providing the Linux VM on macOS).

Can Peppy instances on different machines communicate with each other?

Yes. Core nodes connect into a unified network through federation: each core node manages its own machine, and a single launch can place nodes across machines, with the coordinator resolving every deployment once and the other machines running exactly what it resolved. Machines join the same network by logging into a shared workspace with peppy platform login.

Will Peppy maintain backward compatibility?

Not until version 1.0. Since Peppy is still in alpha/beta, maintaining backward compatibility would introduce additional complexity and divert effort away from core development.

Any plans to make Peppy compatible with Windows?

No. Official support is limited to Linux (x86_64 and ARM64) and macOS (Apple Silicon).

Is Peppy free to use?

Peppy is source-available under the Business Source License 1.1. You can use it in production for free, provided your use does not include offering a product or service to third parties whose value derives primarily from Peppy itself; that kind of use requires a commercial license. Each release converts to the Apache License 2.0 on its Change Date (2031-01-01 for current releases). Alongside the open code, the Peppy platform provides workspace login and centralized monitoring of your machines’ core nodes through peppy platform.

My launch failed with an error that looks unrelated to what I changed. Where do I start?

Check peppy repo list on the machine you submitted the launch to, before reading the error too literally.

Peppy’s default repositories track a moving branch, so a change merged upstream reaches your machine on the next peppy repo refresh without a Peppy release. Only the submitting machine’s repositories decide what a launch runs: it resolves every deployment once and every other machine in the launch runs those exact bytes, so a stale or differently-configured cache on another machine is never the cause. A repository cannot declare the same name:tag twice: peppy repo index refuses to generate an index for it and names both manifests, so the duplicate is caught when the repository is published rather than at your launch. See When a repository fails.

Why is peppy repo refresh reporting repositories it could not update, and can I still work?

Yes, you can almost certainly still work. A refresh failure is scoped to the repository that caused it: every other repository is indexed as usual, and the failing one keeps the entries it last published, so everything that launched before still launches. The run itself succeeds, names every repository that failed in one message so you know which parts of the state are not current, and asks you to run peppy repo refresh again.

Read the failure kind. unreachable means the repository could not be read at all: network, a bad ref, an unmounted path, or a root with no committed peppy_repository.json5 (the fix for that last one is authoring, not waiting: run peppy repo index in the repository and commit the result). conflict means the repository was read fine but its committed index contradicts itself or the tree, and the message names what to fix.

peppy repo list marks a failing repository’s entries [retained, last read <date>]. Watch that date: retention is deliberate so that identities do not vanish out from under your launchers, but a repository failing for weeks is still serving weeks-old entries.

The one case with no local workaround is a machine that has never read that repository successfully: it has nothing to fall back to. Excluding the repository is the only lever, and it removes every identity that repository provides, not just the broken one.

Is there an LLM-friendly version of the documentation?

Yes! LLM-optimized versions of the documentation are available at /llms.txt (index with links) and /llms-full.txt (full content). Those are always in sync with the latest version of the documentation.