Reusing services

Reuse a service in the form your product needs:

• Call a running deployment to use its provider access and state. See calling tools for CLI and HTTP calls, or other services for calls from your service.
• Deploy a published template to get a private copy with your own credentials, settings and state. See deploying a template.
• Link its Rust API when the work should execute inside your service and use your service’s secrets and database.

Browse Connect for provider integrations, Agents for shared agent memory, Web for website tools and analytics, and Ops for uptime and webhooks. Each service documents its credentials and state ownership. Catalog membership does not make a deployment public.

Link a Rust API

Deployable services in the repository also expose libraries. Disable their default tools feature so their standalone tools are not exported from your image:

[dependencies]
github = { package = "crab-github", git = "https://github.com/crabtalk/crab", tag = "v0.1.4", default-features = false }

Keep linked packages on the same Crab revision as berm-lang. Call the dependency’s Rust API from your own tools:

use alloc::string::String;
use berm_lang::{Result, tool};
use github::{api, types::Release};

/// Read the latest published release of a repository.
#[tool]
pub fn latest_release(owner: String, repo: String) -> Result<Release> {
    api::latest_release(&owner, &repo)
}

Declare your exported tool’s access in your own crab.toml. No separate GitHub deployment is needed for this example.

Services linking standard-library dependencies enable berm-lang's std feature and omit #![no_std]. The default guest SDK remains no_std; host operations still use the berm ABI.

What linking inherits

crab build finds linked packages with a crab.toml, including transitive dependencies. Their secrets, credentials, HTTP permissions, service-call requirements and migrations contribute to your image.

Deployment settings stay with each package’s own deployment: its name, logo, visibility, tools and prices, crons, variables, buffer and database sizing are not inherited. Declare the settings and schedules your service needs. Linked code executes inside your service and uses its secrets and database.

The build refuses two versions of one linked package, duplicate credential IDs, or a secret assigned to two credentials. Linked dependencies must not export tools in the consuming image.

Persistent data

A linked package with migrations declares a stable id in its crab.toml, 32 lowercase hex digits chosen once. A deployable service can declare an id alongside its deployment name so it can also be reused as a dependency.

id = "0123456789abcdef0123456789abcdef"

[database]
migrations = "migrations"

The dependency’s tables live in your service’s database, even when your service declares no migrations of its own. Dependency migrations run before your service’s migrations, in name order within each package, and are tracked under the dependency’s id. Different packages can use the same migration filename.

formerly lists package names used to track that dependency’s migrations before it adopted an id; it requires an id. A database that records the same dependency under two migration keys is refused. Removing a dependency leaves its tables and applied migrations in place.

Library-only packages

Packages under services/kits expose only a Rust library. They have no standalone tools or template to deploy. The existing crabkit crate collects these libraries behind features such as auth and stripe; those are Rust dependency names, not a separate deployment model. Read each library’s README for its API and the settings your service must provide.