Docs menu
Package managers
How Cargo works on Primcloud: Cargo.lock and locked builds, workspaces, private registries, and the JavaScript package managers used for a frontend build.
On this page
Rust has one package manager: Cargo. Dependencies are declared in Cargo.toml, their resolved versions are recorded in Cargo.lock, and Cargo downloads and compiles them as part of the build. This page covers how Primcloud runs Cargo, how to reach a private registry, and which JavaScript package managers build a frontend that lives in the same repo.
Supported package manager#
Cargo. It's installed with the Rust toolchain your repo asks for; there's nothing separate to select or version. See Runtime versions.
Install behavior#
There's no separate install step. cargo build --release --workspace --bins downloads whatever it needs and compiles it in one pass.
Two paths, depending on what's in the repo:
With Cargo.lock. The build passes --locked. Cargo uses exactly the versions in the lockfile and fails if Cargo.lock is out of date with Cargo.toml rather than updating it.
Without Cargo.lock. Cargo resolves the newest versions your Cargo.toml requirements allow, at build time. Two builds of the same commit can pick different dependency versions.
Commit Cargo.lock for anything you deploy.
Workspaces. A workspace is built from its root: every member's binaries are compiled, and members share one Cargo.lock at the workspace root. Path dependencies inside the repo are compiled along with the crates that use them.
Downloaded crates and compiled dependencies are cached between builds; see Rust on Primcloud → Cache behavior.
Private packages and registries#
Cargo's own configuration is how you point the build at a private registry. Primcloud doesn't add a mechanism of its own.
Declare the registry in a .cargo/config.toml committed to the repo:
[registries.my-registry]
index = "https://cargo.example.com/index"
Provide the token through an environment variable. Cargo reads a registry's token from CARGO_REGISTRIES_<NAME>_TOKEN, with the registry name in capitals:
CARGO_REGISTRIES_MY_REGISTRY_TOKEN: set this in the Secrets panel.
Secrets you set are visible during the build. They're stored encrypted and never printed in build logs.
Warning
Never commit tokens. Keep .cargo/config.toml to the registry's location and leave the credential in the Secrets panel.
Lockfiles#
Cargo.lock is Cargo's lockfile. It pins the exact version and checksum of every crate in the dependency graph.
With Cargo.lock committed |
Without | |
|---|---|---|
| Build command | cargo build --release --workspace --bins --locked |
cargo build --release --workspace --bins |
| Dependency versions | Exactly what you committed | Resolved at build time |
Lockfile out of date with Cargo.toml |
Build fails | Not applicable |
Lockfile drift. If you change a dependency in Cargo.toml without updating the lockfile, the locked build fails. Run cargo build locally, commit the updated Cargo.lock, and redeploy. cargo build --locked reproduces the same check on your machine.
JavaScript package managers for frontend builds#
A Rust app with a package.json at the root gets its frontend dependencies installed and its build scripts run before Cargo compiles. The lockfile in the repo picks the package manager:
| Lockfile | Package manager |
|---|---|
package-lock.json |
npm |
yarn.lock |
Yarn |
pnpm-lock.yaml |
pnpm |
bun.lock or bun.lockb |
Bun |
npm, Yarn, and pnpm follow the selection and install rules on the Node.js package managers page. Bun follows the rules on the Bun package managers page. Either way, without a Procfile the Rust binary is the web process; see Rust on Primcloud → Frontend assets.
Commit one JavaScript lockfile, for the manager you actually use.