One place for the whole application
cApp takes application source through an inspected, immutable compiler release into a Windows or Android package. Optional Sidecars add capabilities such as help, navigation, local inference, testing and parts of a Solana operation. Your application keeps its own interface and business logic; you integrate the capabilities it actually needs.
You do not need a wallet, a model or an SDK to try a plain HTML application. Your first application starts with one complete file and an observable interaction, then follows the same project, compile and package path used by a larger product.
Choose your starting point
| Your goal | Start with | Your first result |
|---|---|---|
| Try cApp with a small, known application | Your first application | A working counter, a selected compiler release and a target package to test. |
| Bring an existing web application | Projects and source and Compile, package and release | The correct component and source roots, with an honest readiness result. |
| Add a capability to your application | Sidecar directory and Build with Sidecars | A selected, configured component and a checked application interface. |
| Integrate app data or a backend | SDK installation and Routes, data and sync | Matched client/server contracts and an explicit request path. |
| Build a Solana workflow | Build with Solana Sidecars | A reviewed devnet composition with named wallet, policy, send and observation responsibilities. |
| Investigate a failure or an update | Help and Changelog | The relevant runtime boundary, component version and next check. |
For a demonstration rather than an integration, use Explore Solana Lab. Its scenarios point back to these reusable references; a successful demonstration is not certification of every device or provider.
From source to a result you can identify
Projects → Build: Compile → Library: optional Sidecars → Build: platform package → install and test.
A project groups your work. An application component is one independently compiled app inside that project. A compiler release freezes the source and compiler-owned context. A native package combines that release with target settings and capabilities. An installed test is a separate observation of that package. Editing today's source does not change yesterday's release.
Build and release explains what each step produces, when a new compile is needed, and how to retain the reference and output evidence. Runtime environments explains why a browser preview and an installed application can expose different capabilities.
What this documentation covers
The Guides explain product workflows. Sidecars covers selection, composition, authoring and component APIs. SDK & API covers application/client, data, server and portable interfaces. Solana connects the individual components into reviewed operations and recovery. Help covers failures, privacy and authority.
The directory distinguishes alpha, core and planned components. A planned entry is not an available API. A declared target is not a guarantee that a component is selected, ready, or qualified on your device. Check the version and limitations on its reference page before making it a required product path.
Browse here; build in your workspace
These public pages are read-only guidance, with copyable examples and reviewed downloads. They do not create a project, install cApp, start a model, open a wallet or connect to your private workspace. The Showroom is public discovery, not the installed authoring application; inspect a listing's actual artifacts and publisher information rather than assuming a web preview is a native download.
Use your installed cApp authoring environment, or an explicitly configured local workspace, for project and build operations. That environment needs its local build services and the chosen platform's prerequisites. A plain browser can run the first guide's HTML example independently, but it cannot supply the native packaging toolchain.
Read versions and updates separately
The September 2026 edition describes the documented alpha interfaces. The documentation version, a Sidecar version, your application version and its compiler release reference identify different things. A website update does not update installed applications or their SDK dependencies.
Component changelogs distinguish documentation baselines from actual additions, changes and fixes. Keep an installed test tied to the package you tested, and review credentials, privacy and authority before introducing real users, provider access or irreversible effects.