Buyer's guideSustainability Studio (Guardian)

Self-hosted Guardian, a managed service or custom MRV: how to choose

Once you have decided to digitise environmental assets, the next choice is where the platform runs. You can operate open-source Guardian yourself, use a managed Guardian offering or build a bespoke MRV system. Each route puts the work of infrastructure, keys, storage and upgrades in a different place, and each leaves you with different ways out. This guide compares them and lists the questions to put to any provider.

Reviewed 10 October 2026 6 min read

On this page

The three routes at a glance
What running Guardian yourself involves
What a managed offering covers, and what must stay yours
When a bespoke MRV platform is the better fit
Self-hosted, managed and bespoke compared
Questions to put to any Guardian provider
Hybrid paths worth considering
Hypothetical: a regional registry chooses its route
Questions and answers
Sources

The three routes at a glance

Self-hosted Guardian means running the open-source code, licensed under Apache 2.0, on infrastructure you control¹. A managed offering means a provider runs Guardian for you as a service; the best-known is the Managed Guardian Service, run by Climission, a company founded by the co-founders of Envision Blockchain, Guardian's long-standing core maintainer². A bespoke MRV platform means building your own workflow, evidence store and issuance logic, possibly still on Hedera services underneath.

ColdAI deploys and operates Guardian for issuers, registries and buyers, so self-hosting need not mean hiring an operations team. It does mean someone must be accountable for everything in the next section.

What running Guardian yourself involves

Guardian is a set of services rather than one application. The repository provides Docker Compose configurations for quickstart, demo and production use, alongside supporting components such as MongoDB, NATS and Valkey¹. Documents go to IPFS through a pinning service such as Filebase or a local node such as Kubo, and secrets can be held in HashiCorp Vault¹.

On the Hedera side you need accounts with ED25519 keys, and mainnet operations incur HBAR fees¹. Someone must fund those accounts, protect their keys and decide who may sign for the Standard Registry. Add monitoring, backups of the database and IPFS pins, security patching and a way to take new Guardian releases without disturbing published policies. The infrastructure is modest; the attention it needs is continuous.

What a managed offering covers, and what must stay yours

A managed service typically runs the Guardian services, storage and upgrades, and may pay Hedera fees on your behalf. Climission lists the Managed Guardian Service alongside policy development tools, help-desk support and a service that manages Hedera fees for clients². That removes most infrastructure work and lets policy work begin sooner.

What must remain yours is everything that defines the programme: the policies you publish, the schemas and documents, the DIDs your participants act through and the keys behind your Standard Registry. Ask how each can be exported and used elsewhere, because a provider that holds your registry's identity effectively holds your programme.

When a bespoke MRV platform is the better fit

Guardian's model, role-based workflow over verifiable credentials with issuance at the end, suits most methodology-driven programmes. It suits less well when the core product is something else, such as high-frequency telemetry analytics, a trading venue or a corporate reporting tool where issuance is incidental, or when approval logic cannot be expressed with the available blocks without heavy custom work.

Going bespoke buys freedom at the price of re-creating identity, credential handling, audit trail and issuance. You can still anchor evidence on Hedera Consensus Service and issue on Hedera Token Service, but proving your workflow's integrity to verifiers and buyers is then entirely your job.

Self-hosted, managed and bespoke compared

Criterion	Self-hosted Guardian	Managed Guardian offering	Bespoke MRV platform
Control	Code, configuration, data location and release timing	Policies and data; the provider controls infrastructure and upgrade timing	Everything, including the workflow model itself
Path to first issuance	Infrastructure and keys first, then policy work	Usually the shortest, since policy work starts early	Longest: workflow, identity and issuance must be built
Operating burden	Yours or an operator's: services, IPFS, accounts, keys, upgrades	Mostly the provider's; participant management usually stays with you	Entirely yours, including security review of custom code
Data residency	Wherever you host, subject to IPFS pinning choices	Set by the provider's hosting regions and subprocessors	Wherever you host
Customisation	Policies, plus code changes if you maintain a fork	Policies and configuration within what the service supports	Unlimited, at your cost
Lock-in and exit	Low if you track upstream releases instead of a private fork	Depends on export of policies, documents, DIDs and keys	High dependence on whoever built and maintains it
Cost structure	Infrastructure, HBAR fees and staff or operator fees	Service fees plus HBAR fees, unless the provider bundles them	Build cost, then ongoing engineering and hosting
Skills needed	DevOps, key management and policy engineering	Policy engineering and programme administration	Product engineering, security and MRV domain expertise

A qualitative comparison. Confirm current features and terms with any provider; this page makes no claims about third-party pricing or performance.

Questions to put to any Guardian provider

Ask these before signing, and test the answers to the first two during the trial period.

0 of 9 checked

Can we export every policy, schema and document?Ask for a test export early and load it into a separate instance.
Are our policies portable?Confirm they rely on standard Guardian features, not provider-only extensions.
Who generates and holds the Standard Registry's keys and DID?Ask whether they can be transferred to you on request.
Whose name are the Hedera accounts and topics under?Accounts created under the provider's control are hard to move later.
What are the service levels and incident terms?Availability targets, support hours and how quickly you are told about incidents.
Where do data, backups and IPFS pins sit?Hosting regions, subprocessors and who else can access the data.
Can our auditors and verifiers inspect directly?Access to logs and configuration without going through the provider each time.
How are new Guardian releases rolled out?Testing, notice periods and whether you can defer an upgrade.
What help comes with exit?Assistance, notice period and data hand-back if either side ends the contract.

Hybrid paths worth considering

If
You need a working pilot soon but expect to run the programme for many years.
Then
Start on a managed offering with export rights in the contract, and plan a move to self-hosting once volumes and team are known.
You learn what the policy needs before committing to infrastructure, without making the provider permanent.
If
Buyers need a tailored portal, reporting or marketplace features.
Then
Run Guardian for issuance and evidence, and build a custom buyer portal that reads from it.
The trust chain stays in a standard tool while the customer experience is yours to shape.
If
Residency rules rule out the provider's hosting regions.
Then
Self-host in a compliant region, with an operator if you lack the team.
Residency is usually a hard constraint, whereas operating effort can be contracted.
If
Your methodology is new and still changing.
Then
Prototype in dry-run conditions on whichever route is quickest, and delay the hosting commitment until the policy settles.
The right hosting choice is clearer once you know what the policy demands.

Hypothetical: a regional registry chooses its route

Questions and answers

Can Guardian policies move between deployments?

Generally, yes: policies can be exported from one Guardian instance and imported into another running a compatible version. The harder part is history. Documents, identities and the records of past issuances live in the original instance and on Hedera, so plan how the new instance will reference them, and rehearse a full move before you depend on it.

Who owns the DIDs and keys in a managed Guardian deployment?

That depends on the contract and setup, which is why it should be settled first. Ideally the Standard Registry's DID and Hedera keys are generated under your control, or can be transferred to you, and the provider works with delegated access. If only the provider holds them, your programme's identity cannot leave without its cooperation.

What happens to our programme if a Guardian provider exits the market?

Issued tokens and messages already recorded on Hedera remain on the network, because the ledger does not depend on the provider. What you could lose is the running workflow, off-ledger documents and access to keys. Contractual export rights, regular test exports, your own copies of IPFS content and keys you control turn a provider exit into a migration rather than a rebuild.

Sources

Guardian repository and README — Hashgraph on GitHub · checked 10 October 2026
Hedera Guardian 2026: The Next Chapter — Hashgraph · checked 10 October 2026

Compare Guardian hosting routes against your own constraints

Share your methodology, the scale of issuance you expect, any residency rules and your team's skills. We will set out which route fits and what each would require from you.

Discuss Guardian hosting