Blueprint SDK Deployment Guide

Blueprint SDK deployment turns a local Rust service into a Tangle Blueprint that operators can register for and run. The production path is not “write Rust, deploy once, hope operators figure it out.” A deployable Blueprint needs a service definition, reproducible artifact, tested runner, operator settings, testnet evidence, monitoring, and rollback plan. Use testnet as a promotion gate before mainnet, especially for paid services, private data, TEE execution, or slashing exposure.

This guide is the deployment checklist. For payment-specific gates, read x402 Blueprint Production Deployment Checklist. For deployment architecture, read Remote Providers, Direct Runtimes, and Payment-Native Ingress.

What The Blueprint SDK Deploys

A Blueprint is a reusable service definition. Developers define jobs, metadata, sources, and runtime behavior. Operators run the Blueprint. Consumers create service instances and send work.

Layer	Deployment responsibility
Blueprint definition	metadata, jobs, artifact sources, manager settings
Rust service	job handlers, validation, runtime logic
artifact	reproducible binary, source, or image with integrity metadata
operator runtime	keys, RPC URLs, ports, env vars, health checks
Tangle registration	publishes the Blueprint for operator discovery
service instance	receives actual job calls and user work

The SDK source is tangle-network/blueprint. Deployment should also fit the broader Tangle verification model and Blueprint architecture. At the substrate level, keep the normal Rust deployment basics in view: Cargo’s build and test commands, reproducible dependency locking through Cargo.lock, and container or binary distribution discipline from Docker image references.

Local Loop First

Start locally. A broken local service becomes a harder broken testnet service.

cargo install cargo-tangle --git https://github.com/tangle-network/blueprint --force
cargo tangle blueprint create --name my_blueprint
cd my_blueprint
cargo build
cargo test

The local loop should prove:

Check	Pass condition
build	Rust service compiles from a clean checkout
tests	handlers and service manager logic are covered
definition	metadata, jobs, sources, and integrity fields validate
local run	runner starts with local settings
smoke job	one known job succeeds and one bad input fails cleanly

Do not treat the definition as documentation only. It is deployment input.

Definition And Artifact Discipline

A Blueprint definition should be reviewable by both humans and tools:

{
  "name": "my-blueprint",
  "jobs": ["quote", "execute"],
  "sources": ["container-or-binary-artifact"],
  "integrity": "sha256:...",
  "manager": {
    "requiredEnv": ["RPC_URL", "SERVICE_KEY"]
  }
}

The exact schema depends on the SDK version and Blueprint shape, but the deployment principle is stable: operators need to know what they are running, where it came from, which settings are required, and how to verify the artifact.

Testnet Deployment

Once the local loop is clean, deploy to Tangle testnet:

cargo tangle blueprint deploy tangle \
  --network testnet \
  --definition ./definition.json

Use testnet to prove the full system:

Testnet gate	Evidence
registration	Blueprint metadata is discoverable
operator startup	at least one operator can start with documented settings
job success	a valid sample job succeeds end to end
error path	invalid input fails with a useful error
observability	logs identify Blueprint ID, service instance, job ID, and failure reason
artifact integrity	deployed artifact matches the reviewed source or image

Testnet is where you catch packaging mistakes, missing env vars, bad source URLs, wrong ports, and operator setup drift.

Production Checklist

Before mainnet, write the operating envelope.

Area	Production requirement
artifact	immutable source, image, or binary with integrity metadata
keys	operator keys separated from developer keys
RPC	stable endpoints and fallback behavior
pricing	clear job pricing, quote path, or x402 challenge
verification	mechanism appropriate to the job type
monitoring	health checks, logs, metrics, and alert ownership
rollback	known downgrade or redeploy path
incident path	what happens when a job fails after payment or partial execution

For paid services, connect deployment with x402 payments for AI agents and Blueprint SDK x402 payments. For agent services, read How To Deploy A Paid AI Agent Service.

Promotion Rule

Mainnet should follow evidence, not ceremony. Promote only after successful testnet jobs, operator runbooks, artifact integrity checks, and rollback proof.

That is especially true for services with payments, private data, trusted execution environments, or slashing exposure. Those systems need separate gates because failure can cost money, leak data, or damage operator reputation.

What To Automate

Automate checks that prevent bad deploys:

cargo build --locked
cargo test
cargo tangle blueprint deploy tangle --network testnet --definition ./definition.json

If your SDK release exposes a separate definition validation command, run it before testnet deployment. The automation intent is stable: build, test, validate the definition, deploy to testnet, run a smoke job, and record evidence.

Record the deployed Blueprint ID, network, artifact hash, git commit, operator version, and smoke job result.

FAQ

What is Blueprint SDK deployment?

Blueprint SDK deployment is the process of publishing a Blueprint service definition, making its artifact available, registering it on Tangle, and proving operators can run it.

What does cargo-tangle do?

cargo-tangle is the CLI used to create Blueprint projects, validate definitions, and deploy Blueprint definitions to Tangle networks.

Should I deploy to testnet before mainnet?

Yes. Testnet proves registration, operator startup, job execution, logs, and failure behavior before production users or payments depend on the service.

What belongs in a Blueprint definition?

It should describe metadata, jobs, artifact sources, manager settings, and integrity information for the deployed service.

How is this different from deploying a normal API?

A normal API is usually operated by one team. A Blueprint is a service definition that independent operators can register for and run under Tangle’s protocol rules.