Skip to main content
Every Kairo package is described by a kairo.toml file at the package root. This manifest tells Forge what the package is, what version it is at, which version of the Kairo language it targets, and — for applications — how to start it. kairo.toml uses the TOML format and must begin with manifest_version = 1. Forge reads this file as the first step of every build pipeline operation.

​
Full manifest example

The following example shows a complete kairo.toml for an application package. Annotated comments explain each field.
A library package omits the [application] and [runtime] sections entirely:

​
[package] fields

​
string
required
The package’s unique identifier in the registry. Must be written in dot-separated PascalCase — each segment starts with an uppercase letter and segments are joined with .. Examples: Astra.Customers, Astra.Platform.Logging. Single-segment names (e.g., Customers) are permitted but discouraged; use a namespace prefix to avoid collisions.
​
string
required
The package version in Major.Minor.Build.Candidate format. All four components are non-negative integers. Example: 1.2.3.0. See Version format below for the meaning of each component.
​
string
required
The Kairo language version this package is written for. Forge uses this to select the correct language rules and standard library surface. Use "0.1" for the current release.
​
string
required
Either "application" or "library". Applications declare an entrypoint and are executed by Pulse. Libraries expose a public API and may be listed as dependencies. An application package cannot appear in another package’s [dependencies] section.

​
Version format

Kairo versions follow a four-component scheme: Major.Minor.Build.Candidate.
Exact versions are required everywhere in Kairo manifests. Forge does not support version ranges or the latest keyword. Once a version is published, it is immutable — you cannot republish a different package under the same name and version.

​
Application-specific fields

When kind = "application", add [application] and [runtime] sections to complete the manifest.

​
[application]

​
string
required
The fully qualified name of the entrypoint function that Pulse will invoke when the application starts. Must include the complete module path and function name, separated by .. Example: "Sales.Orders.Program.main". See Pulse for the valid entrypoint function signatures.

​
[runtime]

​
string
required
The runtime engine that executes this application. Use "Pulse" for the standard Kairo runtime.
​
string
required
The runtime contract version the application was built and tested against. Pulse checks this value at startup and rejects artifacts that declare an incompatible contract. Use "0.1" for the current release.
If you omit the [application] or [runtime] sections from an application package, Forge will report an error during the build pipeline. Library packages must not include these sections.

​
Multi-package repositories (workspaces)

When a repository contains more than one package, create a workspace.toml file at the repository root alongside — but separate from — any individual kairo.toml files. A workspace lists its member packages explicitly:
Each member path points to a directory that contains its own kairo.toml. Forge and Studio both recognise workspace.toml as the root of a multi-package project and will operate on all members together unless you target a specific package.
Root your IDE at workspace.toml (not an individual kairo.toml) when working in a multi-package repository. Studio will show all member packages in a unified project view.

​
Next steps

Dependencies

Learn how to declare, restore, and lock your package dependencies.

Forge

Run forge build, forge check, and the rest of the Forge command suite.