Mainnet Publisher Production Guide
Walrus does not provide a public unauthenticated publisher on Mainnet. There are no plans to create one because the publisher must pay SUI and WAL for every blob it stores. On Mainnet, a publisher should be privately operated for a specific application, service, or organization.
Use this guide to decide whether a Mainnet publisher is the right upload path for your use case, and if so, how to operate one safely.
An unauthenticated Mainnet publisher lets anyone spend the publisher wallet's SUI and WAL. If you run a Mainnet publisher, enable authentication and also put it behind a reverse proxy or private network boundary.
Which upload path should you use?
Use a publisher when your service needs an HTTP upload interface and you are prepared to operate the wallet, authentication, and cost controls behind it.
| Upload path | Use case | Who pays |
|---|---|---|
| Private authenticated publisher | Backend services and controlled clients that need an HTTP PUT /v1/blobs interface | Publisher operator |
| Upload Relay | Browser or mobile clients that need a relay-managed upload path | Client or relay policy |
| TypeScript SDK | Applications that can integrate Walrus directly and manage signing in code | Application wallet or signer |
| Walrus CLI | Operators, scripts, and manual uploads | CLI wallet |
If your clients run in a browser or mobile app, use Upload Relay. If your application can integrate Walrus directly and manage signing in code, use the TypeScript SDK. For scripts and manual uploads, use the Walrus CLI.
How to set up a production Mainnet publisher
For production Mainnet usage, run a private publisher with authentication enabled:
- Follow Operate a Publisher to install, configure, fund, and run the publisher.
- Follow Use the Authenticated Publisher to restrict uploads to authorized clients.
- Put the publisher behind a reverse proxy or private network boundary. See Configure nginx caching for reverse proxy setup.
- Monitor the publisher wallet's SUI and WAL balances. See Create and fund the publisher wallet and Manage SUI coins in sub-wallets.
- Rotate credentials and restrict who can issue upload tokens. See Work with JWTs.
Do not rely on community publishers for production uploads. Community endpoints can change, go offline, add restrictions, or expose different cost and reliability expectations.
How to protect the publisher wallet
A publisher performs onchain actions and pays storage costs. Treat its wallet as production infrastructure:
- Use a dedicated publisher wallet, separate from storage node wallets and personal wallets.
- Fund the wallet only with the SUI and WAL required for expected usage.
- Monitor SUI and WAL balances and alert before they run low. See Create and fund the publisher wallet.
- Restrict access to the host, configuration files, and sub-wallet directory.
- Review sub-wallet behavior and sub-wallet refills.
How to control access and cost exposure
A private publisher should reject uploads from unauthorized clients before it spends tokens.
Use the authenticated publisher when clients need to upload through your publisher. The authenticated publisher validates upload tokens before accepting writes.
For additional controls, consider:
- Network allowlists for backend-only publishers.
- Short-lived upload tokens.
- Per-client size and epoch limits.
- Separate publishers or wallets for staging and production.
- Logs and daemon metrics for accepted, rejected, and failed uploads.
When should you enable CORS?
Only enable cross-origin resource sharing (CORS) for browser clients that must call the publisher directly. If uploads come through your backend, keep the publisher private and avoid exposing it to browsers.
When browser access is required, restrict allowed origins to your application domains and test preflight requests before production launch.
How to plan for failover
If your application depends on a publisher, plan how uploads behave when it is unavailable:
- Run health checks for the publisher endpoint.
- Keep enough SUI and WAL in the publisher wallet for expected traffic.
- Monitor failed writes and insufficient-balance errors.
- Decide whether clients can fall back to another private publisher, an upload relay, or a direct SDK path.
- Document the expected retry behavior for your application.