akash-provider

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 defaults to uakt — the bidMinDeposit config value (and the deposit field on MsgCreateBid) is anti-spam collateral posted from the provider's balance, not a compute payment. Default is 500000 uakt (0.5 AKT); uact is accepted only via a rare burn-mint fallback.
• Both denoms coexist in your workflow: gas commands and the bid escrow deposit use uakt; bid prices, lease revenue, and pricing-script output use uact. Don't conflate the gas denom and the pricing denom.
• 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
Resource reclamation (AEP-82, v0.13.0+) — provider-initiated reclaim of active leases	@rules/operations/lease-management.md (§ Resource Reclamation) + @rules/configuration/bid-engine.md (§ Resource Reclamation Window)
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:

1. Bid on orders from the chain (responding to MsgCreateDeployment events).
2. Receive manifests from tenants and apply them to Kubernetes.
3. 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 and minimum-gas-prices (chain gas). The bidMinDeposit / deposit field on MsgCreateBid defaults to uakt (500000 = 0.5 AKT, posted from the provider's balance); uact is accepted only via a rare burn-mint fallback. The pricing-script price denom and the gas denom aren't interchangeable; the chain enforces both.
• 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. For node v2.1.0, run provider-services v0.13.0 or later (the paired build; required to offer AEP-82 resource reclamation via --reclamation-window).
• 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

# Check provider status (replace with your address)
provider-services query provider get akash1yourprovider...

# List active leases on your provider
provider-services query market lease list --provider akash1yourprovider...

# Tail provider logs (Kubernetes)
kubectl -n akash-services logs -f deployment/akash-provider

# Bid engine logs
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

• Akash Provider Documentation
• provider-services repo
• Akash Network Discord — provider operator channel