| name | akash-provider |
| description | Set up and operate an Akash Network provider — the supply side of the decentralized cloud. Covers Kubernetes prerequisites, provider installation, attributes and pricing configuration, bid engine tuning, monitoring, and troubleshooting. Use for "run an Akash provider", "set up Akash provider", "Akash provider Kubernetes", "Akash provider attributes", "Akash provider pricing", "Akash provider bid engine", "Akash provider not getting bids", "Akash provider audit", "provider lease monitoring".
|
| license | MIT |
| metadata | {"author":"Akash Network","version":"3.0.0","argument-hint":"<task-description>"} |
Akash Provider — Setup and Operations
This skill covers everything needed to run a provider on the Akash Network: cluster prerequisites, installing the provider services, configuring attributes and pricing, tuning the bid engine, and ongoing operations.
For deploying workloads to Akash, use the akash-network:akash skill. For running full nodes or validators, use akash-network:akash-node.
Terminology (provider perspective)
The Akash chain uses the same vocabulary across all three roles; these are the terms a provider operator most often encounters.
- Provider — an entity supplying compute. Identified on-chain by an Akash address (
akash1...). Runs a provider-services daemon backed by a Kubernetes cluster.
- Bid — an offer from your provider to host a deployment at a given price. Generated by your bid engine in response to chain order events.
- Lease — an accepted bid. Once a lease exists, the provider receives the deployment manifest from the tenant and runs the workload.
- Order / dseq / gseq / oseq —
dseq (deployment sequence) is the per-deployment id; gseq and oseq identify the group and order within it. Bids/leases are scoped to (dseq, gseq, oseq).
- Attributes — key/value tags advertised by the provider (e.g.
region=us-west, tier=community). SDLs use placement attribute filters to select providers.
- Audit — endorsements from on-chain auditors. Audited attributes are considered more trustworthy by deployers; some SDLs filter on
signedBy.
- Bid engine — the component that decides whether to bid and at what price. Configurable via attributes, pricing scripts, and CPU/GPU/memory rate tables.
- AKT (
uakt) — chain token. Used for gas (--gas-prices, minimum-gas-prices), staking, and validator rewards. The provider's wallet uses AKT to pay gas on its bid transactions.
- ACT (
uact) — deployment-payment token. Used for SDL pricing, bid prices, lease payments. The provider's bid prices (output of your pricing script) are in uact/block. Lease revenue arrives as ACT.
- Bid escrow deposit is in AKT, not ACT. The
bidMinDeposit config value (and the deposit field on MsgCreateBid) is denominated in uakt — it's anti-spam collateral, not a compute payment. Upstream default: 5000000 uakt (5 AKT).
- Both denoms coexist in your workflow: gas commands and bid escrow use
uakt; bid prices, lease revenue, and pricing-script output use uact. Don't conflate them.
- Manifest — the rendered runtime config the tenant pushes to your provider after a lease is created. The provider applies it as Kubernetes resources.
For a fuller chain-side vocabulary (deployer view), see the akash-network:akash skill's rules/terminology.md.
What this skill covers
| Area | File |
|---|
| Hardware, network, and OS requirements | @rules/requirements.md |
| Kubernetes cluster setup (single + multi-node) | @rules/setup/kubernetes-cluster.md |
Installing provider-services and CRDs | @rules/setup/provider-installation.md |
Initial provider configuration (provider.yaml) | @rules/setup/configuration.md |
| Attribute schema and how SDLs filter on them | @rules/configuration/attributes.md |
| Pricing script — how bids are priced per resource | @rules/configuration/pricing.md |
| Bid engine tuning (when to bid, min/max prices) | @rules/configuration/bid-engine.md |
| Day-to-day lease management | @rules/operations/lease-management.md |
| Monitoring (metrics, alerting, on-chain status) | @rules/operations/monitoring.md |
| Common failures and how to diagnose | @rules/operations/troubleshooting.md |
Architectural overview
Internet
│
├──► Tenant manifest push (mTLS or JWT)
│
▼
provider-services daemon
│
├──► bid engine ──► broadcasts MsgCreateBid
├──► manifest receiver ──► applies workload to Kubernetes
├──► proxy ──► forwards tenant traffic to pods (ingress)
│
▼
Kubernetes cluster
├── tenant pods (workloads)
├── ingress controller
├── persistent volumes (beta2 / beta3 / ram)
└── (optional) GPU operator
The provider does three jobs:
- Bid on orders from the chain (responding to
MsgCreateDeployment events).
- Receive manifests from tenants and apply them to Kubernetes.
- Serve traffic to running pods through its ingress.
Critical rules
- Use
uact in your bid pricing script (the script's output becomes the price field on MsgCreateBid). Use uakt for --gas-prices, minimum-gas-prices, and bidMinDeposit (chain gas + bid escrow). The two denoms aren't interchangeable; the chain enforces both — and the deposit field on MsgCreateBid is uakt, distinct from the price field.
- Provider TLS identity is your on-chain wallet. The provider's TLS certificate must have a CN/SAN matching its on-chain Akash address. Tenants validate it that way.
- Keep
provider-services up to date. Chain upgrades regularly break older provider releases. Subscribe to the Akash Discord / GitHub releases.
- Audit attributes are trust signals. If you advertise
signedBy claims (e.g. "trusted by AkashNetwork"), you must arrange the on-chain signature from the auditor. Don't claim unverified audits.
- GPU providers must match SDL filters exactly. GPU vendor and model strings in your attributes must match what SDLs ask for, or you won't bid (e.g. SDL requests
vendor.nvidia.model: a100, your provider must expose that).
Quick reference — useful commands
akash query provider get akash1yourprovider...
akash query market lease list --provider akash1yourprovider...
kubectl -n akash-services logs -f deployment/akash-provider
kubectl -n akash-services logs -f deployment/akash-provider | grep -i bid
Companion skills
akash-network:akash — Deployer-side knowledge: how tenants write SDLs, what attributes they filter on, and the bid-matching workflow (rules/bid-matching/) that deployers use to check which providers can run their SDL. Helpful to run against your own provider to see whether you're being filtered out.
Additional resources
