Run Your Own Label 309 Gateway

Yes — you can run your own gateway. A Label 309 gateway is the open-source service that quotes, uploads, publishes, confirms, and indexes proof-of-existence records. Run your own and your organization becomes the operator: you fund the Cardano and storage wallets, manage accounts and API keys, and publish standard records without depending on CardanoWall's hosted service. The records you anchor are identical to anyone else's, because the standard, not the operator, defines the format.

Self-hosting is not the easy path. It is the control path. This post explains when that trade is worth making, what the gateway actually runs, and what you take on by running it yourself.

When should you run your own gateway?

Run your own gateway when operating control matters more than convenience.

For most users, the hosted CardanoWall gateway is the right answer. It is simpler to start, easier to fund, and removes the infrastructure work entirely. If you publish occasionally and have no policy reason to hold the keys yourself, stop here — the hosted path is built for you.

Some teams, though, need a different model:

strict vendor and data-residency policies;
regulated or audited workflows;
high-volume publishing;
internal compliance archives and legal-evidence systems;
AI provenance infrastructure and CI/CD proof pipelines;
products built on top of Label 309 under their own brand;
direct control over keys, accounts, funding, and pricing.

For those teams, self-hosting lets the organization own the whole pipeline rather than routing it through a third party.

What does the gateway actually run?

The gateway owns the entire publish pipeline and the money, chain, and storage state behind it. It is a single Rust binary plus PostgreSQL, and it handles:

quote creation and pricing;
content or ciphertext upload to storage;
storage funding and accounting;
Cardano transaction build, submission, and confirmation tracking;
reorg handling and automatic refunds when a publish fails permanently;
the public on-chain records index;
account balances and the balance ledger;
API keys, account tokens, and the operator control plane;
webhooks and the audit trail.

This is the machinery behind a reliable publishing service. The client still owns user-facing intent and private keys; the gateway owns the chain, storage, pricing, and account infrastructure. That split is deliberate — it is the same boundary whether CardanoWall runs the gateway or you do.

What do you need to self-host?

At minimum, operational ownership of five things.

A gateway deployment. The binary, its configuration, a Postgres database, network access, logs, monitoring, and an upgrade path. The binary applies its own schema migrations on boot and runs every background loop under one supervisor, so a failing loop stops the process rather than degrading silently.

Cardano funding. The gateway needs a funded wallet to pay transaction fees. You do not manage individual transaction outputs yourself — the wallet keeps a small pool of ready outputs groomed so that every publish pays an exact fee rather than an estimate. You keep that wallet topped up; the gateway does the rest.

Storage funding. If your gateway accepts file or ciphertext uploads, it needs a storage backend and the funds to store bytes. In production that is Arweave through a Turbo bundler, paid via prepaid storage credits you top up from an Arweave wallet. You can also run a hash-only deployment with no storage at all: records then carry only the content hash (and any externally hosted URIs), and the instance stores nothing.

Operator credentials. The control plane is protected by an operator root secret, printed exactly once when you provision the instance. Day-to-day administration runs on short-lived operator tokens minted from it. These secrets must never reach a browser, a client bundle, a mobile app, or a CI log.

An account and billing policy. Even if you are the only user, the gateway still needs to decide who may publish and how balances are credited. Balances are the gateway's own authority; you credit them through the control plane from whatever billing rail you run.

Self-hosting is real infrastructure. Treat it that way and it is dependable; treat it casually and it becomes a liability.

Does self-hosting change the standard?

No. A self-hosted gateway publishes the same Label 309 records as any other operator, and the records stay standard.

A verifier needs only the Cardano transaction metadata, optionally the content bytes, and a public Cardano explorer. It does not need to know — and cannot tell — whether a record came from the hosted CardanoWall gateway, your company's gateway, or a developer's laptop. That is the entire point of separating the open standard from the hosted product: the durable artifact is Label 309, and every gateway is a downstream implementation of it.

Does self-hosting remove all the cost?

No. It removes the hosted operator's margin, but the underlying costs are still yours.

You still pay:

Cardano transaction fees and storage costs for any uploaded bytes;
infrastructure, database, and backup costs;
monitoring, logging, and security operations;
staff time, treasury management, and failure recovery;
upgrades and ongoing maintenance.

If your volume is low, the hosted gateway is often cheaper in practice once you count the human cost of running infrastructure. (For the mechanics of why publishing costs money at all, see why publishing has a price.) If your volume is high, or policy requires you to hold the keys, self-hosting starts to pay off.

Who should not self-host?

Do not self-host just to avoid thinking about price.

If you publish occasionally, lack operations capacity, do not want to manage funded wallets, and do not need custom policy control, the hosted gateway is almost certainly the better choice. Self-hosting puts you in charge of availability, security, funding, monitoring, and upgrades — which is a benefit only if you actually want that responsibility.

For most individuals and many small teams, hosted CardanoWall is the practical path.

Who is a good fit for self-hosting?

Teams that already operate serious infrastructure and have a concrete reason to hold the pipeline themselves. Good candidates include:

companies publishing high-volume proofs;
compliance teams anchoring daily or hourly evidence, ideally batched under a single record;
AI teams committing dataset and output manifests;
DevSecOps teams folding proofs into release pipelines;
legal platforms handling sensitive evidence;
products that want Label 309 under their own brand;
organizations that cannot route sensitive workflows through a third-party hosted service.

In these cases, running the gateway becomes part of the organization's existing security and infrastructure posture rather than a new thing to babysit.

How does a product build on top of a gateway?

A product can treat the gateway as its base layer. The gateway handles chain, storage, pricing, balances, records, and publish status; your product handles users, sessions, billing presentation, notifications, workflow, UI, and domain-specific meaning.

For example:

a compliance product publishes daily control snapshots;
a media product anchors Content Credentials (C2PA) manifest hashes;
a legal product seals evidence for specific recipients;
a developer tool publishes release proofs;
an AI product timestamps batches of generated output.

The product never rebuilds Cardano submission or storage accounting — it calls the gateway. This is exactly how CardanoWall is built: the web app and worker are a wrapper around the same public gateway planes a third party uses, with no private door. If you want the integration patterns in depth, see build on a Label 309 gateway.

How do clients connect to a gateway?

Through the gateway's HTTP API, split into two planes.

A web app, desktop app, CLI, SDK integration, or backend service uses account tokens or API keys to call the data plane: quote, upload, publish, read balance, read records. Operator actions — creating accounts, crediting balances, setting margins, minting credentials — go through the control plane, and only ever from a trusted backend.

The usual separation:

clients act with scoped, short-lived account credentials;
your backend holds the operator credentials and never exposes them;
private identity keys stay on user devices or under your own key policy;
the gateway never decrypts sealed content.

A practical pattern is the token-minting proxy: the client authenticates against your own session system, your backend exchanges that session for a short-lived account token scoped to exactly what the page needs, and the client only ever sees that token. A leaked token is then a one-hour problem, not an incident. The records read surface is even simpler — it serves anonymous callers, so public verify pages and explorers need no credential at all.

What should operators protect?

Several things, in roughly this order of severity.

Keys and credentials. The gateway signs with a single encrypted keyring — Cardano, storage, and webhook keys in one file under one passphrase. Create it offline, keep an offline backup of both the file and the passphrase, and guard the operator root secret like a production database password. There is no key-export or sweep path: lose the keyring and you strand whatever funds sit on its addresses.

Funds and authority. Control who can create accounts, issue API keys, adjust balances, and change margins. Every control-plane action is audit-logged, and balance adjustments are capped per call as a blast-radius limit, so a fat-fingered entry or a compromised token can move only so much at once.

Operations. Keep logs and an audit trail, a backup-and-restore plan, and monitoring for low wallet funds, storage running dry, stuck uploads, failed publishes, and a stale chain tip. The binary logs structured JSON for a log aggregator and exposes a health probe.

Least privilege. A browser must never receive operator credentials. A CI job must never receive more power than it needs. Scope account tokens narrowly and keep them short-lived.

How does verification work against a self-hosted gateway?

Exactly as it does against any gateway: verification does not trust the gateway at all.

A verifier checks the Cardano transaction, the Label 309 metadata, the hashes, the optional signatures, any Merkle proofs, and sealed payloads using the standard rules — no issuer server in the loop. The gateway helps you publish and index; it cannot make an invalid proof valid.

This matters most for internal systems. A company running its own gateway should still verify its own records independently. "Our gateway said it published" is not the proof. The on-chain record and an independent check are the proof. You can run that check with the open-source cardanowall command-line tool or verify a record by hand — neither needs your gateway running.

How does this relate to CardanoWall?

CardanoWall is the hosted, polished product and the reference operator for the standard. Self-hosting is the independence path. The two are not in tension.

A user can start on CardanoWall, move to a self-hosted gateway later, or use both for different workflows. A developer can build a product on the gateway model. A company can keep hosted CardanoWall for simple teams while running its own gateway for regulated automation. The shared layer underneath all of it is Label 309 — open, vendor-neutral, and the same on-chain whoever publishes.

The short version

Run your own gateway when you want to operate the publishing service yourself. You gain control over funding, accounts, margins, API keys, infrastructure, and policy — and you take on responsibility for availability, security, wallets, storage, monitoring, and upgrades.

Hosted CardanoWall is convenience. Self-hosting is control. The proof records stay standard either way.